Jenkins 2.x實踐指南

 

在開源軟體的解決方案中講到「持續整合/持續佈署(CI/CD)」，十之八九會提到Jenkins這項工具。即便我已經利用Ansible把程式佈署的流程自動化，但是相較於Jenkins，Ansible還是缺少網頁管理介面、帳號與權限管理、操作記綠檔等功能。因此進一步導入Jenkins來整合Ansible的自動化腳本，就是完善我自動化佈署的終極方案。

Jenkins早在2011年就問世，網路上的參考資料多不勝數。熟練地運用適當的關鍵字，谷哥大神確實能告訴你一些答案。不過我個人以為，想要有系統、依循脈絡地學習一項新知，一本好書絕對是性價比最高的投資。而「Jenkins 2.x實踐指南」是值得我掛保證，它能讓讀者從零開始學會Jenkins 2，進而運用自如。尤其全書中著眼在介紹2.x版本的「pipeline as code」，Jenkins中的流程用程式碼的形式來撰寫和分享，受惠於此理念，流程將可以被版本庫儲存與管理！完全克服了1.x版本時最為人詬病的流程設定「黑箱化」問題。

就Java語言而言，軟體開發過程是一連串的「手工」操作。寫好程式碼後，先將原始碼編譯成位元組檔，再打包為可執行檔，然後上傳到主機的特定目錄，以終端機指令啟動該程式。著重軟體品質的專案，則會在編譯後加上測試作業。如果是網頁專案，還得多一項重啟網頁伺服器的作業。當然Java技術棧早就發明Ant、Maven和Gradle等自動化建置(Build)工具，來處理這些惱人的例行工作。說穿了Jenkins工具，只是把你手上既有的版本庫(如Gitlab)、測試腳本(如JUnit)、建置工具(如Maven)或佈署腳本(如sh)用pipeline程式碼整合起來。所以對尚未使用軟體版控、尚未對建置/佈署步驟自動化的開發團隊來說，Jenkins絕對不是仙女的魔法棒，可以讓你輕鬆略過應有的基本功。

對於「一條龍」(從頭到尾都一人負責)的開發團隊來說，並沒有急迫得導入CI/CD工具的誘因。非多人同步開發的專案，只要程式有單元/功能測試，根本用不上持續整合(CI)。程式編譯到佈署的「手工藝」，只要夠細心謹慎，用不用持續佈署(CD)差異也不會太大。不過從中長期來看，所有軟體專案都應該完成CI/CD的設定。達成CI，可以讓小型專案在擴展成大型專案的過程中，維持軟體品質和降低溝通成本。而做到CD，則得利於佈署作業標準化，可輕易地讓專案系統平行擴充。