《Effective DevOps》是一本技術人撰寫的非技術書籍，它探討的並非要用什麼工具來實踐 DevOps，而是帶領讀者關注 DevOps 最本質讓人面對的「human problem」。 （本文同步發表於 Medium） 《Effective DevOps》英文版於 2016 年出版，如果你在 Twitter 上耐心搜尋 #EffectiveDevOps，仍然可以找到在《Effective DevOps》剛出版時，人們所拍下的許許多多「開箱照」。
如同我在譯者序中提到的，《Effective DevOps》並非是一本 IT 技術人習以為常的「技術書籍」，而是一本由技術人寫出來的非技術書籍。全書雖然從四個主軸切入來探討如何讓 DevOps Effectively，但若仔細閱讀，你會發現這四大主軸依然全都圍繞著相同的重點——人與文化。即便其中一個主軸的名稱為「工具」，但內文描述的卻不是你應該使用哪一個工具、運用哪些工具鍊才符合 DevOps，反而內容是一再地提醒你要思考人們為何要使用工具？如何使用？工具與人的關係及關聯性為何。
書籍架構 按目錄，這本書的架構被分為六篇：
第一篇：什麼是 DevOps？ 第二篇：協作 第三篇：親和力 第四篇：工具 第五篇：擴展 第六篇：建立 DevOps 文化的連結 但其實可以分成三個部分來看：
第一篇即是 DevOps 的簡介與這本書想要傳達的核心理念 第二至五篇從四種不同的面向切入，說明「人與文化」有關的各種因素及影響性 第六篇為結論與呼籲 在第一篇，作者幫助大家先建立對於 DevOps 的基本認識，幫助讀者將自身對於 DevOps 的觀點，從 技術、工具轉移至作者認為大家真正應該專注的「human problem」。 在第二至五篇則是詳細介紹作者提出的「Effective Devops 四大主軸」為何，以及其重要性與影響性。各篇單獨說明如下：
第二篇：協作，內容談的即是何為協作，其重要性、影響性，以及有哪些因素會影響協作。 第三篇：親和力，談的是「連結」與「關係」，及其能夠帶來交互作用，內容涉及了「人與人」、「人與群體」、「群體與群體」、「組織與組織」，甚至是「企業與企業」的關係。 第四篇：工具，不同於技術書看待工具的方式，本書是從「工具對於人及文化的影響層面」來切入，強調「工具之於人的價值」。 第五篇：擴展，談的不是系統、基礎架構的 scaling，更不是 Cloud 的 Auto Scaling，而是組織的演化與生命週期，提醒我們當組織在 scaling 時（可能是擴大、縮編、轉型⋯⋯），別忘了關注「人與文化」的議題。 最後第六篇，則是整本書的收尾，再次提醒「DevOps is a human problem」，呼籲大家除了要關注「技術債」之外，更要關注組織與團隊內的「文化債」。同時第六篇也是一份邀請，作者在邀請讀者們一起擁抱她們所認為 #devops 這個 hashtag 最初的精神——打破穀倉與隔閡，讓人們彼此串連、連結，邀請大家加入世界各地的 DevOps 社群，彼此分享經驗，創造更多的連結與正向循環。...
延續上一篇文章，針對公開放上 Ansible Galaxy 的 Roles，我們能夠完全比照 geerlingguy 大神的測試方式，直接使用 Travis Ci。但如果是一些不打算公開的 Roles，那就只好使用自己的 CI Server 來測試，在這篇文章中就讓我們用 GitLab CI 來進行測試。
（本文同步發表於 Medium 道場）
在文章開始之前要先打預防針，其實轉換並不難，特別是如果你早已看懂 geerlingguy 的測試方法，那還請忽略本文，因為對於高手而言這篇文章很可能只是在說廢話啦 XD。
GitLab CI 的詳細使用方式就不多說了，請參閱官方文件。GitLab 依然有提供免費註冊，並且也有提供有限免費的 CI Runner 可以使用，因此想要試用又不想自行架設者，可以先註冊免費帳號來試用。
使用 GitLab CI 的方式與 Travis CI 類似，同樣都是在專案內新增一個 yaml 檔案，並在其中定義 CI Pipeline 與 CI Job，而 GitLab CI 預設使用的檔名為 .gitlab-ci.yml。因此其實我們只要仿造在前一篇文章中說明過的 geerlingguy 大神之測試方法，在 .gitlab-ci.yml 中，將其轉換成 GitLab CI 可以接受的方式即可。
預備多種測試環境 與 Travis CI 相同，GitLab CI 也支援使用 docker 來建立不同的測試環境，因此在 .gitlab-ci.yml 中，需要特別註明要使用支援 Docker 的 Runner，並且替每個 CI Job 指定所使用的 Docker Image。...
 （本文同步發表於 Medium）
我個人的 devops 旅程大約起始於 2013 的年中，當時我正陷於傳統產業之 IT 與 MIS 的救火工作之中，就在那時我收到了來自好友聖佑捎來的一段訊息，「你有聽說過 DevOps 嗎？」正是這一句有如直銷的話語，引領我正式進入 devops 的世界中。而在接下來的日子裡，大量的知識與資訊向我席捲而來，到底什麼是 devops？是特定的技術？團隊協作方式？組織轉型？文化？面對大量令人眼花撩亂的資訊，實在是令人難以招架，現在回想起來，我與本書其中一則推薦序有著相同的想法，若是當時的我也能夠擁有這本書那該有多好。
這並不是一本寫給技術宅的技術手冊，它更像是一本心理學字典、參考書、故事集或者是《哈佛商業評論》雜誌。本書就像是一份指南，能夠指引向來只重視技術知識的 IT 人，繼續探索更多不同領域的知識與資源。一間企業能夠順利的運作絕不是只靠「dev」或「ops」即可，企業若期望提升其生存能力，組織內的每個部門皆有其重要性，希望本書的中譯本可以幫助更多人以更廣義的角度來看待 devops，讓優良的企業文化能深植在全體組織之中。
在未來 devops 一詞會不會消失？我個人不敢斷言，但可以肯定的是隨著這波 devops 風潮，只會有越來越多的人們知道，原來世界上擁有更優良的工作方法、團隊協作方式以及各種可以提升組織效能的工具。而「開放」和「持續改善」恐怕也將會是未來組織、團隊及個人都必須擁抱的一種優良文化。
在我個人的 devops 旅程中，一再接受到來自社群的諸多幫助，「取之於社群，回饋於社群」，主動請纓擔任本書譯者是我個人在心中為「回饋社群」所立下的一項里程碑，期盼本書能為社群提供更多的參考資料，讓更多人能夠因此受益。讀者若對於 devops 相關主題有興趣，可以加入世界各地的 devops 社群，也歡迎加入 DevOps Taiwan 社群，同時也鼓勵你嘗試籌組屬於自己城市的在地社群，讓社群能夠遍地開花，建立更多的人際連結、互動與交流。另外我個人比照原書作者為英文版設立 https://effectivedevops.net/ 的做法，也設立了 https://effectivedevops.tw，期盼也能為社群提供更多有助於互動交流的空間。
這本由技術人寫出來的非技術書籍，實在是令人感佩兩位作者的學識豐富，但對於擔任譯者的我而言，則是一段艱難的歷程，能夠順利完成本書的翻譯，著實要感謝許多人的幫助，感謝出版社編輯的耐心、感謝多位社群前輩的建議及鼓勵、感謝幾位心理學領域的朋友所提供的諮詢。
最後感謝我那可愛又逗趣的妻子，雖然妳一再表示妳是氣質美女，但在我的心目中，妳就是為人生旅途增添風趣的最佳伴侶，還有我的寶貝女兒，妳的可愛笑容是這段艱難日子中最棒的心靈療癒，謝謝妳們，妳們是我持續向前邁進的重要助力。
——陳正瑋
寫在翻譯書籍順利出版之後 感謝來自社群針對《Effective DevOps 中文版》的支持與鼓勵，但還請容我再次向大家致歉，對於這本書延誤到如今才順利出版，實在是感到非常不好意思，謝謝大家的包容與忍耐。
同時也再次說明，譯者並非作者，因此無論各位是買一本或買十本，基本上都不會影響我個人的收入，不過還是鼓勵大家多多買書、看書，因為出版業真的需要更多人的支持，不然出版品的品質恐怕只會逐年下滑。我一直很認同過去求學時期聽見的一句話「一個國家的國力與翻譯力息息相關」，雖然現在是網路 + 人人都會英文的時代，想要取得第一手的資訊與知識已經不像過去的時代那麼困難，但我還是依然認為知識能否更快速的普及與傳遞，和該知識是否能被快速、正確地被翻譯為當地語言是有關聯性的。因此，還是要再次呼籲，希望大家能多多支持出版業，不論是買書、看書、推廣好書、擔任譯者或作者，這些都是值得鼓勵的方式。
另外，https://effectivedevops.tw 網站也已經順利上線，將會貢獻給 DevOps Taiwan 社群使用，將會用來匯整各種值得收藏的 DevOps 相關好文或參考資料。雖然網站目前還只是一個陽春的 MVP 版本，但相信未來的日子我們會將其改善得越來越好，如果您也有收藏任何與 DevOps 有關的優質文章，也歡迎讓我們知道，謝謝。
提供 DevOps 經典好文與參考資料 最後，要再提一次，縱然在書籍出版過程中，譯稿已經過多雙眼睛的校對與覆閱，但相信本書依然可能會有錯譯及翻譯不佳之處，如果有任何的建議，還請各位務必回報讓我們知道，我們會盡快將大家回報的錯誤，整理為「書籍勘誤對照表」並於網路公佈，在此就先感謝大家的指教了。 回報《Effective DevOps 中文版》勘誤 相關連結 《Effective DevOps 中文版》 DevOps Taiwan 社群 https://effectivedevops....
如同程式需要測試，Ansible Playbook 或 Roles 其實也是某種 Code，因此最好也能為其撰寫適當的測試。本文就讓我們向 Ansible 圈內的大神 geerlingguy 求教，學習 geerlingguy 大神測試 Roles 的方式。
（本文同步發表於 Medium）
本文的內容也正是我在 DevOps Taiwan Meetup #13 - Ansible User 小聚所分享的閃電秀，當時的簡報在此：
「跟著 geerlingguy 大神一起測試 Ansible Roles」 建立你的 Roles 並透過 Travis CI 測試 要學習 geerlingguy 大神的測試方式之前，當然請先準備好你的 Roles，將其推上 GitHub。關於 Roles、Ansible Galaxy 及 GitHub 三者的關係，這邊就不再重複說明了，請直接參閱凍仁翔的文章「怎麼在 Ansible Galaxy 分享 Roles？」（上、下）。
推上 GitHub 之後，接著要將 Repository 與 Travis CI 建立串連，這部分也同樣可以參閱凍仁翔的文章「怎麼用 Travis CI 測試 Roles？」。
接下來就讓我們一窺 geerlingguy 大神是如何測試的。
geerlingguy 大神的測試妙招 Ansible 的使用者們應該或多或少都曾使用或參考過 geerlingguy 大神所撰寫的 Roles，如此大量高品質的 Roles，全部都有通過 Travis CI 測試，到底是如何做到的？關鍵在於 geerlingguy 充分利用了 Travis CI 的特性，並且撰寫一支專門協助測試的 shell script。...
（本文內容已過期，請參閱最新的 ansible-container 官方文件。）
自從上次（2016年）試用 ansible-container 遭遇慘痛的踩雷經驗之後，如今 ansible-container 的版本號已進入 0.9.2，據說文件及穩定度皆已有所改善，因此決定趁著放假撥一點空檔再次試用它，希望這次的試用過程不會像上次一樣地慘痛。
（本文同步發表於 Medium）

以乾淨的 Ubuntu 16.04 環境試用 根據官方文件，ansible-container 的 Prerequisites 為
Python 2.7 or Python 3.5 pip setuptools 20.0.0+ 因此決定直接以乾淨的 ubuntu 16.04 環境挑戰，避免遇到 python 版本或相依套件的問題。首先透過 Vagrant 建立乾淨的 ubuntu 16.04，並在 VM 內安裝 Docker。接著以下面指令安裝 pip。 apt-get update
apt-get install python-pip
pip install --upgrade pip 接著按官方文件安裝 ansible-container。
pip install ansible-container[docker] （[] 內除了可以填 docker 之外，也可填寫另外兩種 engines，分別是 k8s 及 openshift。） 順利安裝後即可執行 ansible-container -h，查看 help。
試用 ansible-container 開始簡易地試用 ansible-container...
延續小技巧（1），本文繼續分享兩個與 Ansible playbook 有關的小技巧，希望大家都能安安心心地執行自己所的撰寫 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在 playbook 內適當的設立檢查點與中斷點 在小技巧（1）中，主要提及的都是執行指令 ansible-playbook 時可以添加的 options，而在本文則分享兩個常用的 modules。
善用 debug 檢查 相信有在使用 Ansible 的使用者們都知道，在撰寫 playbook 過程中，經常有一些 Modules 是我們會重複使用的，其中一個即是 debug。
在 playbook 當中，有時為了讓各個 tasks 能夠順利串連，我們會將部分 tasks 的結果透過 register 註冊為新的 variables，提供後續的 tasks 能以此進行邏輯判斷。
而為了確認這些 variables 取得的值或結果是否合乎自己的預期，一般在撰寫 playbook 的過程中，便會直接透過 debug 將其印出，方便自己能夠直接進行除錯與檢查。
# 舉例：
command: whoami
register: check_user
debug: msg="{{ check_user }}" debug 非常單純，即是幫你將 msg 中的資訊印出，因此非常適合適時地安插在 playbook 當中作為檢查點，讓你可以在執行 playbook 之後快速檢查執行成果是否都如你預期。...
在剛開始接觸組態管理工具（Configure Management Tool，或常見譯為配置管理工具）的時候，應該都會經歷過一段日子，就是擔心自己寫的自動化腳本會不會有問題，特別是當腳本要使用在 Production 環境時，總是會再三的確認，深怕自己一個不小心，不但沒省事，反而把 Production 環境搞壞了。
本文簡單地談談在 Ansible 中有哪些小技巧可以幫助你降低這些憂慮，放膽執行您的 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在實際執行 playbook 之前的三個基本 Options 先從 ansible-playbook 指令內建的 Options 開始說起，有三個 Options 是最基本的檢查，分別是：
--syntax-check --list-tasks --list-hosts –syntax-check 首先是 --syntax-check，它可以用來幫你檢查 playbook 有沒有格式或語法錯誤，不過其實我們不用手動執行它，因為當你執行 ansible-playbook 時，就已預設會先進行語法檢查了。 所以在 --help 中也是這麼說明的。
--syntax-check perform a syntax check on the playbook, but do not execute it （謎之音：那你還浪費篇幅介紹它。）
對於現代的開發者而言，「語法檢查」通常會跟工程師使用的編輯器、IDE 綁在一起，讓語法檢查能夠自動完成，以 ATOM 為例就有 pacakage - linter-ansible-syntax 可以幫助我們在撰寫 playbook 時即能完成語法檢查。
–list-tasks 第二個 Option 是 --list-tasks，它可以幫你列出在即將要執行的 playbook 中有哪一些 tasks 會被執行。建議在執行重要的 playbook 之前可以先跑一次 --list-tasks，複閱是否會執行的皆是你所預期的 tasks。...