今年艦長發了個瘋，在第二個小孩剛出生沒多久、即將舉辦 DevOpsDays Taipei 2019 （我擔任其中一位組織者）的狀態之下，參加了「第 11 屆 iT 邦幫忙鐵人賽(2019)」。
這次參賽的主題為「和艦長一起 30 天玩轉 GitLab」，本來想要用一個虛擬的團隊作為案例，分享關於 GitLab 的使用經驗，但實際上場之後才發現當初規劃的太美好，事前準備的不夠充分。雖然順利完賽，但案例規劃的並不完整、內容深度也不如計畫，最終撰寫的成果仍是較基礎的 GitLab 操作文章。
（This article has been translated into English.）
目前文章依然留存於「iT 邦幫忙」網站上，暫時先不一篇篇的搬到我私人的部落格，先用超連結的方式處理：
iT邦幫忙網站提供的30天文章列表 下面直接附上 30 篇文章連結，並做一個簡單的分類整理： （鐵人賽文章撰寫時，使用的 GitLab 版本主要是 12，後續出版為書籍《和艦長一起 30 天玩轉 GitLab》時，版本為 13.x。） 基本認識 前言 安裝 GitLab GitLab 管理與權限 Admin Area—維運 GitLab Server 的管理者後台 GitLab 的 User 與權限控管 GitLab Workflow GitLab: 從建立 Group 和 Project 開始 初探 GitLab Workflow & GitLab Flow GitLab 和 Mattermost GitLab: Issue、Issue Board 和 Kanban GitLab: To-Do List 與 Milestones GitLab: Commit & Merge Request GitLab: Issue Templates & Merge Request Templates GitLab: Project Wiki & GitLab Pages GitLab Cycle Analytics & Charts GitLab CI 架設 GitLab CI Runner GitLab: 建立第一條 CI/CD Pipeline CI/CD Pipeline 之 stage: build CI/CD Pipeline 之 stage: deploy CI/CD Pipeline 之 stage: test CI/CD Pipeline 之 stage: prod-deploy CI/CD Pipeline 之 Container CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦？ GitLab CI 之 CI trigger、API 與 ChatOps GitLab CI 之 Scheduling Pipelines GitLab Auto DevOps GitLab: Auto DevOps 之牛刀小試 GitLab: Auto DevOps 之牛刀小試 2 - K8S GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production) GitLab: Auto DevOps 之牛刀小試 4 - Auto Browser Performance Testing GitLab: Auto DevOps 之牛刀小試 5 - Auto Monitoring GitLab: Auto DevOps 之牛刀小試 6 - Customizing 回顧與總結 回顧與總結 以上就是 30 天鐵人賽的所有文章。...
（DevOpsDays Taipei 2019 的 T-Shirt 圖案，你有看懂這個梗嗎？）
（本文同步發表於 Medium）
今年沒有閉幕式，所以就讓我將感恩的話留在部落格吧！
感謝四大主辦單位的 Organizer，大家從去年底開始就逐步籌備規劃，多方聯繫、牽線、資源整合，感謝 Organizer 所付出的努力，使得今年 DevOpsDays Taipei 2019 的規模能更勝往年！
感謝各家贊助商的鼎力相助，今年的贊助商數量也突破去年，而且贊助商一間比一間積極，在贊助企劃書都還沒定稿之前，就已經有廠商一再詢問何時可以贊助，這實在是令籌備小組感到十分窩心，多虧了贊助商的幫忙，讓我們在活動預算上能更佳寬裕，也才有辦法邀請更多的國外講師。
感謝眾多講師帶來精彩的演講與工作坊，今年的投稿數量與入選講師數量也邁入新高，並且更加的國際化！特別要感謝日本 DevOpsDays Tokyo，以及中國各大 DevOps 社群的 Organizer，在我們提出邀請之後，立即就積極的為我們推薦了多位講師。
當然也要感謝 iThome 現場所有的工作人員，所有繁雜的行政事務、庶務都是交由他們協助處理，若是缺少了他們，大會恐怕將無法運作得如此順利。
最後，感謝參與這三天活動的每一位與會者，因為有了各位的參與，這個場域才真正形成了一個經驗匯集交流的空間，而社群不就是在這樣的空間中成型並成長茁壯的嗎？
如果你去年也有參加 DevOpsDays Taipei，也許你還記得在去年的閉幕，我借用了我前同事的一句話做為閉幕梗。
讓我們再看一次這句話——「每個人都有機會成為別人的英雄！」
今年我想要延伸這句話繼續往下說——「在這個空間中的我們，每一個人都是英雄！」
也許我們心中會認為經常在社群出沒的高手與志工、台上的講師或網路上總是分享優質好文章的人才是英雄、先驅。因為我們可能會因為他們舉辦的活動、分享的內容，獲得受益、得到幫助，因此覺得他們就像是個英雄。
但經歷這幾年經營社群之後，現在我認為只要是願意來到這個空間參與活動，甚至是願意在 Facebook 上，為分享文章按讚的每一個人，都是一位英雄！
你不經意的提問，也許正好幫助講師有機會補足他演講中欠缺的一環。 你在場外的隨口閒聊，也許有機會成為下一場活動、另一個合作案的契機。 你在 Facebook 上按下的一個讚，也許正好就安慰了螢幕背後那個鐵人賽快撐不下去的某人。 任何的回饋，都有可能帶來巨大的影響！ 期盼這三天的 DevOpsDays Taipei 2019，除了能為所有的參與者帶來知識、技術、觀念上的收穫，這個空間也能成為一個新的契機，讓更多正向的回饋能夠在與會者、團隊、企業與整個業界產生更多的化學反應！
再一次的我要感謝大會所有相關人員的付出，以及現場的每一位參與者！
讓我們 2020 時，再次相會！謝謝大家！
（今年一樣在 DevOpsDays Taipei 的開放空間會議中，輔助活動的進行。）
（今年擺了豬公撲滿讓大家 donate 支持社群活動，撲滿內的所有經費將會用於後續社群 Meetup 活動的場地費與講師車馬費。）
（感謝 DevOps Taiwan Community 志工群的幫忙，今年的錄影工作完全是由志工群一手扛下重任！）
（為了接待來自日本的講者，今年特別徵招一批特別的大會志工—Local guide 親善大使！）
如果要說前一陣子還有在忙些什麼事情，那其中一項就是幫忙出版社擔任《DevOps三十六計》繁中版的審校者。因為擔任這個審校者，讓我簡繁詞語轉換能力提升了不少，某種層面來說算是另一項意外收穫。
（本文同步發表於 Medium）
首先還是要感謝編輯的寬容，一而再的容許我的拖稿，如果哪天我要自己寫書，恐怕會被編輯徹底的討厭，大概會成為更誇張的拖稿大王。《DevOps三十六計》繁中版，即將於二月底出版上市，既然出版社已經將新書資訊傳遞給各個書籍通路了，我也終於可以公開的分享一下我對這本書的一些看法。
如果用嚴謹的角度來評斷，那這本書其實有著一些些小缺點。首先因為這是一本多作者合著的書籍，正確來說這本來就是一本公開徵稿、收錄多位作者的文章集結而成的書籍，因此像是各章節之間顯得過於獨立，彼此的連貫性、關聯性不足；同時有時作者們為了配合書名「三十六計」，有部分出現內容因此受限，導致作者在內容撰寫時過於抽象或隱晦，進而可能會影響讀者難以理解作者想要傳達的重點，或是難以理解某些「計策」背後欲傳遞的重點觀念。
但如我們放下前述的嚴厲眼光，回到前面提到的「這本來就是公開徵稿、收錄多作者文章集結而成的書籍」，那其實這本書可謂是「社群精神」的另一種實際體現，因為這就好比多位專家一起線上共筆、一起貢獻開源專案，而這次是大家一起貢獻了一本豐富的 DevOps 案例集與經驗談。
而事實也是如此，《DevOps三十六計》原本只是中國的 DevOps 社群，在中國舉辦的 DevOpsDays 活動中發起的一項計畫，廣邀講者、專家一起來撰文分享經驗，最初它只是在中國舉辦的 DevOpsDays 活動中免費贈送的一本小冊子。然而隨著內容越來越豐富，最終由出版社協助正式出版上市。
所以在閱讀本書時，就請用觀看實務案例集、踩雷血淚史和經驗分享之文章的方式閱讀它。如此你會發現，其實別人跟你一樣，在導入 DevOps 時、在撰寫自動化測試、在維運實務工作現場⋯⋯在許多地方都踩過不少雷，大家也都是這樣一路成長過來的。
另外，看見這樣的書籍出版，對於亦有在經營 DevOps 社群的我而言是非常高興與雀躍的。一方面高興市面上又多了更多的 DevOps 案例。另一方面則是高興能看見這樣一個集合社群力量合力出書的案例；如果有類似的機會，是否在台灣的社群當中亦能產生這樣的動能？
最後，再附上一小段內容與前文有些重複的「審校感言」，這是原本預備用來假如編輯有向我要一篇「審校序」時使用的，但最終編輯沒說，不過既然都寫了，就丟出來傷傷大家的眼睛了。
時光飛逝，從第一次聽見 DevOps 到如今積極投入台灣的 DevOps 社群，轉眼也已經快要五年的時間了。然實際上自 2009 年 DevOps 一詞誕生以來，至今也已經過十年時光了。DevOps 發跡於社群、乘載著社群的力量，最終被推廣至世界各地。DevOps 在業界的能見度越來越高，而投身於社群的人們亦針對 DevOps 持續分享著各式各樣的經驗談。
在 2017 年時，我聽聞中國的 DevOps 社群正在進行一項名為「DevOps三十六計」的大計畫，那是一項發自社群，期望能凝聚社群、集結社群力量的一個非常有意義的專案。而隔年 2018 再次打聽消息時，令人驚訝的是這專案不但成功執行完畢，並且已正式出版成為在各通路流通的出版品。
就我這幾年協助組織社群的經驗，我看見《DevOps三十六計》這樣的出版品能夠面世，是感到非常高興與雀躍的。我覺得《DevOps三十六計》可謂是「社群精神」的另一種實際體現。社群由人與人所組成，社群除了能夠令人們彼此建立連結、交流經驗之外，社群亦能發揮更大的影響力並為後人留下許多寶貴的寶藏。而這本由多位專家參與、分別貢獻各自專業經驗集結而成的《DevOps三十六計》，正是此種社群寶藏的一項絕佳例證。
《DevOps三十六計》，書名雖為「三十六計」，但在一篇篇經驗談中，實則蘊含了多位業界前輩的深厚功力與血淚經驗。「三十六計」不過是個引子、是個起點，更重要的是除了收錄於書中的三十六計之外，在社群這個「武林」之中，還有著更多的「師傅」，更多的「計策」等著我們持續地去探索與挖掘。來吧，各位朋友！一起踏入這個名為「DevOps 社群」的武林天下！分享你的「計策」、彼此求教學習，讓三十六計不僅能昇華為七十二計，甚至變成無以計數的寶貴計策，成為值得後人收藏的珍貴寶藏。
最後，再次感謝碁峰出版社的抬愛，讓我有這個機會能擔任《DevOps三十六計》繁中版的審校者，能以不同的形式為 DevOps 社群貢獻一份心力。同時我也要再次藉這個機會向世界各地的 DevOps 實踐家們致謝，感謝各位前輩的付出與分享，成為無數後進們的寶貴借鏡，謝謝各位！
希望這條邁向 DevOps 的成功之路，你我皆能持續地相互扶持，持續地向前邁進！
陳正瑋 2019 年初 備註：如果你購買了《DevOps三十六計》繁中版，發現其中有任何的錯字、錯誤的名詞、錯誤的簡繁名詞轉換，又或者對書中的內容有所提問或建議，還請務必提供讓我知道，謝謝。
因為一些緣故，要再次嘗試透過 Ansible 建立 Azure 的一些資源，於是重新踏入這個坑進行了一番研究。Azure 和其他雲端供應商一樣，提供的服務越來越多樣，同時也支援越來越多服務都能以 Infrastructure as Code 的方式創建與管理，不過既然是重新入坑，還是先從簡單的動作開始著手，首先嘗試以 Ansible 來建立一個 Azure Virtual machines。 （本文同步發表於 Medium、Laravel 道場）
為 Ansible 取得必要的權限 不管是使用哪一種 Infrastructure as Code 或 Configuration Management 工具，如要透過工具直接管理或操作雲端服務，首先都要為工具取得必要的授權及權限。而目前在 Azure 和 Ansible 的官網上，皆已經有文件在教學如何透過 Ansible 來管理 Azure，但在查閱了數篇之後發現，Azure 能夠提供授權給 Ansible 使用的方式主要有兩種：
Active Directory Username/Password Service Principal Credentials 而本文將會採用第二種「Service Principal Credentials」。 如果你打算按著文件，逐一步驟建立「Service Principal Credentials」，我可以預告你很有可能會遇見一個坑，那就是明明是按著文件圖文一步步地操作，但最終就是無法輕易找到下面這四個所需參數。
subscription_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
secret=xxxxxxxxxxxxxxxxx
tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
在嘗試幾種操作之後，個人發現目前最簡單的做法應該是這份文件提到的指令。
使用 Azure CLI 來建立 Azure 服務主體（英文版） 只要按著文件中說明的 Azure CLI 指令 az ad sp create-for-rbac，即可順利透過它取得上述四個參數中的後三項。而最簡單執行 Azure CLI 的方式，則是透過 Azure portal 的 Cloud Shell。 只要登入 Azure portal，在點擊上方工具列 Cloud Shell 的 Icon 即可操作它。...
忙忙忙，終於完成了這場兩天半的 DevOpsDays Taipei 2018，感謝一路上來自社群、親友、公司的支持與幫助，有很多感謝的話想說，但就讓我用這篇原訂要慢步調分享的閉幕詞來代替吧！
原汁原味分享給大家，希望我們都能夠成為別人的英雄！ （本文同步發表於 Medium）
DevOpsDays Taiepi 2018 - Farewell 閉幕 DevOpsDays Taipei 2018 閉幕詞：
大家好，很不好意思，又是同樣的面孔，和去年一樣由我負責這次大會的閉幕。
明明 DevOpsDays Taipei 的 Organizer 加上籌備小組的人數不少，但其他人只丟了一句「你看起來比較會說一些感性與感謝的話」，就直接把閉幕的工作推給我處理，然後只要到了閉幕時段，其他人立馬都不見蹤影。
不過，正如他們所言，在閉幕的時間，我確實想要說一些感謝與感性的話語！
首先感謝 DevOpsDays Taipei 籌備小組的努力，負責規劃、執行從活動籌備至閉幕的各項事務。
感謝所有講者在兩天的議程中為我們帶來的精采分享，我看大會共筆、FB 上有滿多人都在熱絡討論自己獲得的寶貴收穫。
感謝所有贊助商提供的贊助，如果少了這些贊助商的幫助，我們恐怕沒有辦法提供此種規模等級的場地與設備，當然也無法持續供應這些吃不完的熱量補充品！
感謝現場負責所有大小事務辛苦的工作人員、技術人員，幫助我們維持現場的正常運作！
最後，最重要的要感謝這兩天半現場所有的參與者們！謝謝你們來到這裡，一起度過了這精采、豐富的時光！
同時也非常感謝大家在第一時間就將大會 500 多張票搶購一空，老實說今年的售票速度打破我們籌備小組的想像，本來原訂大會將有幾個階段的售票行銷計畫，像是社群推廣票、雙人票、粉專連動發文推廣、拍攝講者事前訪談之活動宣傳影片⋯⋯等。但全部都用不上了。
因為，根本就沒有票可以用來行銷贈送或折價，像我今年 8 月在台中和敏捷台中社群合辦了一場 Meetup，我到場的第一件事就是跟台中的社群朋友們鞠躬「對不起我沒票了」，真的是感謝各位的熱情響應！
說完感謝的話，請讓我利用閉幕的時間，說一些感性的話。我想再一次跟大家分享這一段我經常在社群活動中分享的話。
大家覺得什麼是社群？
我覺得社群是一個讓人們彼此互助、互信、互利的空間。參與社群，即是我用我的真心，來交換你的真心；我用我真實的經歷、經驗、踩過的雷，交換你的經歷與經驗。透過社群這個空間，我們能夠彼此砥礪、互助、一起成長、一起變強！
我很喜歡我朋友范聖佑說過的一句話，如果你有參與 PHP 的社群，你也許已經聽過了，就讓我在這裡借用他所說的這句話：「每個人都有機會成為別人的英雄！」
你也許會認為自己的經驗很小、很不起眼，應該沒什麼價值，沒人想知道。但我要說這樣的想法是錯的！每個真實的經驗，都是一項寶貴的經驗，你所經歷的故事，都有可能成為另一個人的幫助！
社群所能產生的正面影響與幫助，不只限於你個人自身，還有可能擴散至團隊，甚至是組織與企業。這種在人與人、人與團隊、團隊與團隊、團隊與組織、組織與組織之間所建立的連結、親和力，正是 DevOps 最初的原點。
什麼是 DevOps，你去追溯歷史，你會發現 #devops 最初不過就是 Twitter 上的一組 hashtag 罷了！但這個 hashtag 產生了什麼果效？它連結了所有關注 DevOps、對 DevOps 有興趣、所有想要知道如何讓 Dev + Ops 協作的人，它甚至連結了一群期望業界能有所改變的人們！它在世界各地引爆了許許多多在地的社群活動，以及這麼多場的 DevOpsDays！...
 （本文授權 DevOpsDays Taipei 2018 及天瓏網路書店全文轉載） （本文同步發表於 Medium）
自 2009 年 DevOps 一詞面世以來，如今談到 DevOps 時，經常會發生的一種狀況是「人們彼此談論的 DevOps 並不是相同的一回事」。這是因為隨著時間的推進，各方人馬紛紛為 DevOps 添加了不同的詮釋與定義，這現象令人一則以喜一則以憂，喜的是我們能夠看見 DevOps 從最初微小的「社群」開始發跡，最終延燒成為全世界共同響應的一場「運動」，DevOps 的重要性已不容小覷；憂的是，當 DevOps 成為每個人皆能琅琅上口談上兩句的 buzzword 時，是否已漸漸遠離它最初的根本精神。
無論如何，如今在與他人談論 DevOps 之前，恐怕我們要先與對方確認接下來談論的內容是落在哪些範圍之內，是要討論 DevOps 的定義、歷史、運動、職務、認證、工具、實踐、方法、原則或價值觀，如此才能避免彼此陷入雞同鴨講的狀況。

在這樣的窘境之下，究竟我們該如何全面性的認識 DevOps？有沒有什麼懶人包或便捷的資源可以幫助我們快速的一窺 DevOps 到底是什麼、又與哪些觀念、原則、工具或關鍵字相關？也許各位不妨可以參考看看由「机械工业出版社」出版的《DevOps:原理、方法与实践》。
一本點到為止的 DevOps 教科書 《DevOps:原理、方法与实践》是由中國「机械工业出版社」所出版的 DevOps 入門書籍，如果要用一句話來形容它，我們可以說它是一本點到為止的 DevOps 教科書。 本書的架構如下：
第 1 章 DevOps 概述 第 2 章 雲時代的維運 (Ops) 第 3 章 軟體架構演進 第 4 章 軟體開發過程和方法 第 5 章 精益 (Lean) 思想和看板方法 第 6 章 微服務軟體架構 第 7 章 容器 (Container) 技術基礎 第 8 章 基於容器技術的 DevOps 實踐 第 9 章 DevOps 工具集 全書共九章，可以明顯看出作者們嘗試要在書中涵蓋 DevOps 的各個層面。書中除了基本的 DevOps 概述，簡介了 DevOps 從工具、實踐、方法、原則至價值觀的各面向之外，也個別透過一整個章節篇幅說明維運、軟體架構、軟體開發方法因應這時代所產生的演變，並且介紹藏在 DevOps 背後非常重要的 Lean 精神；另外在工具與實務層面則介紹了 Container 與 Microservices 這兩項在現今的 DevOps 實踐中，有著密切關係的重要技術及架構。...
談到 DevOps，我們很容易會陷入一種刻板印象—「DevOps 是非常專注於技術」，因此談論的內容常會偏向於「使用哪種 CI Server？」、「CI / CD Pipeline 如何規劃？」或「是否有採用 Docker 或 K8S？」⋯⋯等。
但在《Effective DevOps》這本書中談到的 DevOps 則並非如此，作者一再強調我們不妨回歸到 DevOps 一詞及 DevOps 運動最初的目標—「讓不同團隊（Dev 與 Ops）的人們能夠互相協作」，以此來看待 DevOps。
因此在書中作者提出了 devops compact 及 Effective DevOps 的四大主軸（支柱，pillar）這兩種概念貫穿全書，希望用文化、組織發展的角度來看待 DevOps。而四大主軸的其中一項即是—協作 (Collaboration)。
（本文同步發表於 Medium）

協作 (Collaboration) 「協作所指的是在擁有共同目標的前提下。個體之間所進行的各種有意識的活動及過程。」—《Effective DevOps 中文版》P.74 身為組織及團隊的一份子，無法避免一定有必須與他人協作的時候，你可能和座位隔壁的同事、相同團隊或部門的成員擁有較好的協作默契，但與其他部門或單位的協作默契則較差一些。在書中介紹了許多會對「協作」造成影響的因素，若將其一一條列，會發現其中大半都與「人」習習相關：
專業背景 包含個體的專業能力、過往累積的經驗、經歷⋯⋯ 個人背景 個體的各種多元特性，性別、語言、種族、國籍、教育水平⋯⋯ 目標 個人、團隊與組織的目標是否一致、擁有共識。 認知方式 人們如何認知事物，對事情、環境及他人的看法與想法。 企業內部的教育與投資 組織內部是否擁有教育訓練，是否提供良好的學習流程與制度。 思維模式 成長型思維或固定型思維。 學習型組織 是否擁抱持續學習、自我改善、對事不對人的文化。 回饋機制 是否擁有良好的回饋機制，幫助團隊自我改善、成長 溝通與解決衝突 是否具備有效的溝通管道與方式，團隊如何面對衝突、化解衝突。 同理心和信任 組織成員是否具備同理心與信任。 人力配置與資源分配 是否擁有人性化的人力配置，人力與工作量的分配狀況又是如何，是否擁有合宜的補償措施。 小結 「如果沒有妥善的處理人們因為專業和個人背景的差異所引起的摩擦，原本高效率的協作就會出現問題。去幫助人們辨別、塑造、並積極努力朝向各自不同的動機和目標，是領導力很重要的一部份，無論你是擁有正式職位的管理者，或只是在同儕之間擔任領導者角色的一般員工。」— 《Effective DevOps 中文版》P....