和艦長一起 30 天玩轉 GitLab（iT邦幫忙鐵人賽系列書）

開始使用Git做為程式碼版本控制工具已經超過七年，當初依樣畫葫蘆學著同事安裝了GitLab做為內部Git Server。隨著業務重心轉向大數據平台，在日常維運中也不特別關注GitLab服務，沒想到事隔數年，至少有數十個專案在其中蓬勃發展，也足見GitLab的穩定與易用性。眼看GitLab進展一日千里，無論從資安或維運角度來看，升級勢在必行。便著手研讀「和艦長一起 30 天玩轉 GitLab」，全面地瞭解該平台，並以此為起點規劃更便利、完善的程式碼開發、管理流程。

除了最基本的平台安裝步驟外，書中有兩個值得深入學習的重點，一是「GitLab Flow」的分支流程觀念，二是「GitLab CI」這個工具技術，兩者相輔相成。Git是開放、低侷限的多人協作版控工具，也因此在分支的使用上並沒有強制做法。依循「GitLab Flow」的提議，以「Feature」和「Issue」為分支起點，並在開發完成後再合併到「Master」分支。明確地規範分支與合併的時間點，讓開發團隊有所遵循，不用浪費時間拘泥在分支規則的設計上，實在是相當明智的作法。

「GitLab CI」則是GitLab平台實踐「CI/CD」的工具，其功能與成熟度可與「Jenkins」比肩。對於要實作自動化測試/佈署的團隊而言，兩種工具擇一即可，並沒有孰優孰劣的問題。不過在使用上，兩者的思維與pipeline構思會略有不同。Jenkins是偏向Java語言的CI/CD工具，因此對於Maven和Gradle這兩個編譯工具大開方便之門。相對的，GitLab CI是源生於GitLab這套版控工具，因此無需使用者額外執行git指令就可以自由取得程式碼。

對於有能力撰寫pipeline腳本的開發者來說，面對這些微妙的差異，肯定能迎刃而解。話說回來，不論是要用GitLab CI還是Jenkins，最精巧的作法，還是免不了要和Ansible做整合，幸好之前已經看過了「尖端神手Ansible 究極自動化組態管理工具（第二版）」，這部份算是準備周全。