為何導入 GitLab CI/CD？

文章封面圖片來源：https://medium.com/@brilvio/how-i-implemented-a-ci-build-of-delphi-binaries-using-gitlab-ci-d1123826698f

契機

傳統大多數系統以單體架構居多，若要將其拆分為微服務架構，管理層面一定會難上不少，故建議導入 CI/CD 來減少人為介入。

即便是單體架構，也能夠導入 CI/CD 來減少人為介入。

淺談 CI/CD

CI（Continuous integration）

• 降低人為疏失
• 減少人工的反覆步驟
• 進行版控管制
• 增加系統一致性與透明化
• 減少團隊負擔

CD（Continuous Deployment）

• 持續發佈並部署程式
• 確保服務存活

圖片來源：https://ithelp.ithome.com.tw/articles/10219083

工具取捨

下文將以 Jenkins Pipeline 及 GitLab CI/CD 做比較：

Jenkins Pipeline

• Jenkins 容易使用及學習，但它有成為插件（Plugin）地獄的風險
• Jenkins 有圖形化使用者介面（GUI），對於非工程人員可能較有幫助
• 易於整合 GitLab（靠插件）
• Jenkins 可以跟你的 Repo 解耦（表示 Repo 沒有一定要在 GitLab 上）

腳本格式 - Jenkinsfile

GitLab CI/CD

• 有較完善的文件可以參考，隨時可以開始
• 學習門檻較低
• 易於維護（無插件機制）
• 易於擴展 Runner
• 可以說 CI 是 Repo 的一部分

腳本格式 - YAML

取捨

最後我們是選擇使用 GitLab CI/CD，有幾個決定性因素：

• YAML 撰寫好上手也較直覺且容易遷移（未來要換到其它 CI/CD 工具也較單純）
• 易於搭配團隊版控策略來進行特定操作
• 可以自主控制的部分相較於 Jenkins 要多

預期既有分支策略導入 CI/CD 造成的影響

我們假設服務和元件的關係可能如下：

服務則可以走以下流程（可視情況而定）：

Merge Request 機制（GitLab）等同於 Pull Request 機制（GitHub）

• 提交（Commit）後執行建置（Build）及測試（Test）
• 開（更新）合併要求（Merge Request）後執行建置、測試及 SonarQube 掃描（其它外部服務…等等）
• 押特定標籤（Tag）後發佈（Publish）並部署（Deploy）
• …（其它你期望的事情）

服務實務經驗

腳本基礎運用

若不想在腳本寫死路徑，可以定義變數來運用！

ReportGenerator：https://github.com/danielpalme/ReportGenerator

GitLab Release CLI tool：https://docs.gitlab.com/ee/user/project/releases/release_cli.html

離線檔：https://learn.microsoft.com/zh-tw/aspnet/core/host-and-deploy/app-offline

腳本視覺化（GitLab 提供）

情境示意圖

容器化示意圖

搭配容器化機制後的情境示意圖

元件則可以走以下流程（可視情況而定）：

• 提交後執行建置及測試
• 開（更新）合併要求後執行建置、測試及 SonarQube 掃描（其它外部服務…等等）
• 合併回主分支（main）後發佈元件至遠端元件伺服器
• …（其它你期望的事情）

元件實務經驗

腳本基礎運用

腳本視覺化（GitLab 提供）

情境示意圖

後續影響

• 易於統整團隊內部分支規則
• 易於實踐 Code Review 機制（可以參考 GitLab Merge Request 提供的 UI 功能）
• 易於提倡自動化帶來的好處

下一步

• CI 環節可以多觸發一些外部服務，增加我們對程式碼的敏感度
• 持續改善現有流程（減少跑一次 pipeline 所需要的時間...等等）
• 通知機制（通知服務已更版...等等）

參考

• Modern development: creating a REST API, via CI/CD and back
• GitLab CI vs. Jenkins