這篇文章說明我們團隊(KKTOWN iOS team) 已經有 Jenkins CI 仍然導入了 Gitlab CI 的原因。
Jenkins 算是 CI 界裡的資深前輩，它不容易出錯又有許多外掛可以使用，可以做很多細部調整，無論是整合進 Slack 或是在專案管理軟體(JIRA, Track 等等) 上依據票號更新資料都難不倒它。
在我們理想的開發流程還是有 Jenkins 不足的地方。怎麼說呢？
Jenkins 是以分枝的異動作為 Job 的驅動，簡而言之是某個分支資料改變時，Job 才會開始執行。 因此我們必須手動的為每一個分枝建立其相對應的 Job 。
在對產品有品質要求的前提下，即便只是修正一個小問題也應該建立一個 Job 來確保程式碼沒被改壞。
凡事要手動的東西就有可能忘記。
我們在開發期間確保程式碼品質的最低標準就是在把程式碼推上 repo 之前跑過一次單元測試。BUT! 無論你或你的團隊成員，總是有可能不小心沒跑測試就推 code，如果審核程式碼的人又剛好忘記檢查這次的修改是否跑過最基本的 Build 跟測試，就很可能導致壞的程式碼被合併到主要的分枝中(dev 或是 master)。
於是我思考有沒有可能強制每一個分支都自動測試？
Gitlab CI 採取的是不一樣的架構，每一個分支的任何異動都會自動執行 Job，等於腳本一寫好會強制套用到所有分支上，並且只有 Job 執行完之後，且程式碼沒有任何錯誤，才能在 gitlab 頁面上合併分枝。
這麼一來強制且自動規範了必須通過測試才能合併的規範，也不讓我們有任何可以偷懶可以忘記的機會，進一步增加程式碼穩定度，提昇對程式碼的信心。
並且讓審核程式碼的人(Code reviwer) 可以專心做一件事情，而不用在 SCM 頁面與 CI 頁面中來回切換，直接在 PR 頁面上可以獲取所需要的全部資訊。
總結
最後我們 Jenkins CI 與 Gitlab CI 兩套並行，讓兩個不同的 CI 工具各自發揮所長。
- 自動化保護每一個分支，不讓我們有機會偷懶
- 程式碼審核(Code review) 整合到一個頁面中，減輕審核的負擔。
最重要的是，確保每一個分支合併前都可以成功編譯建置與測試作為提升程式碼品質的一環。
No Comments