只要是軟體開發，不管 Web Services、還是 Mobile 或 Desktop Application，都會需要建置 (Build) 與交付 (Delivery) 兩個核心過程。Web Services 的交付稱為部署 (Deployment)，應用程式稱為發佈 (Publish)。而這些過程，也伴隨著一些衍生的任務 (Task)，組成一連串的行為，隨著時間的推進，架構的改變，這些任務的組合，往往是工程師們的夢靨的開始。

走過的路

在 git 還沒開始流行之前，我早期在 IBM 工作時使用的 CMVC 這套 IBM 自行開發的整合性 SCM ^註，它整合了 Issue Tracking System (ITS)、Build Procedure、Unit Test、Integration Test、Source Control 等 … 完美整合，分支策略以 Trunk Based 為主，每個 Commit 都一定根據 Issue Number。通常 Commit 一定要基於 Feature Ticket 或者 Defect / Bug Number。

註： SCM: Source Code Mangement, 早期稱 VSC, Version Control System

除了 CMVC，後來常用的 SCM 則是 CVS、SVN、Perforce (p4)，但這些 SCM 如果要處理開發流程，以 SVN 來說，是透過 pre-commit 以及 post-commit hook 去管理。透過這些機制，配合像是 Redmine 這種 ITS 就可以做到 commit 語意化，以達到流程管理的目的。

以下是我在新創事業的工作經歷時，當時配合 Redmine 設計的 commit 規則：

1
2
3
4

ref #1235 part 1 for this functional set.
fix #9527 This is a defect fix, the root cause is invalid assignment.
done #6741 complete functional implementation.
build #9420 trigger build

每次 commit 都必須符合這樣的規則：

1

[command] [issue-number] [comments]

透過這樣的機制，自己做出完整的 CI / CD 流程。

必要的機制

CI / CD 加上 Pipeline 最核心的有三件事情： Build 、 Delivery 、以及把這兩件事連接起來的 Pipeline (Workflow) 。衍伸的任務，其他 CI 還有的像是串接 Unit Test、Integration Test、Code Scan、Code Review，CD 則有環境建置 (Provisioning)、配置管理、部署策略 (發布策略) … 等，是讓整件事情更完善的下一步。

除了上述任務，另外影響整個 Pipeline 的則是分支策略這種流程 (Workflow) 帶來的複雜度，不管是 Git Flow、GitHub Flow、還是 Trunk Based，都會讓團隊有更一致的開發流程體驗，當然隨之而來的就是 Pipeline 的複雜度，進而衍伸的架構議題。

從技術本質來看，要滿足上述任務需要包含這些條件： (1) 任務 (Task) 、 (2) 流程控制 (Flow Control) 、與 (3) 事件驅動 (Event Driven) 。任務指的是像 Build、Deploy、Unit Test、Code Scan … 這些事情，這些事情通常是透過 Script、寫程式、第三方工具串接做整合；流程控制則是把 Task 接起來的控制，包含先後次序，甚至是條件控制；事件驅動則是怎樣發動一個流程或者任務，透過人為觸發 (Approve / Bug Report)、還是 commit 觸發、還是 tag / branch 觸發、還是 Slack 觸發 … 等。

當系統架構變大、變複雜，為了加速 Pipeline 執行的效率，通常會考慮增加運算資源，隨之而來的是第四個條件：分散式運算 (Distributed Computing) ，但也因此會帶來 分散式架構 議題 ^{1, 2}。

撇除工具提供的功能，寫一個好的 Task、做好基本的 Flow Control，需要基本軟體工程能力，還有寫程式的紀律。如果純手工，沒有工具支援，要做好這兩件事情還可以，這也是普遍人在談的自動化程式範圍。但如果要做到事件驅動、分散式運算的需求，那麼就不是普通工程師能做好的了。而 Gitlab 本身的架構透過分散式運行機制：Gitlab Runner 與 Tag，完美的解決這個問題。

推薦

一本書如果要說那些最重要的，我會用上述的觀點來作為衡量指標，觀念要正確，實踐方法與思路要清晰、可用、有效率。這本 Gitlab 實戰，作者除了把 GitLab 整體概念有完整的介紹，CI / CD / Pipeline 該怎麼設計與實踐，有著更實務的介紹，特別在第五章，把我心裡的想法，變成如何透過 Gitlab 實踐出來。

Pipeline 的複雜度是跟著架構，通常系統架構越複雜、依賴性越多，整個 Pipeline 就會越長且複雜。這時候問題通常不是工具的問題，而是結構問題，計算機科學處理複雜度最常用的方法： 分而治之 (Divide and Conquer)

例如有五個系統要部署，彼此有先後依賴關係，Pipeline 的長度有數十個 Stages，這時候可以利用 GitLab Pipeline 提供的變數 (Variables)、流程控制 (Workflow)、樣板 (Templates) 等類似於 DSL (Domain-Specific Language) 的功能，搭配分而治之的概念，降低複雜度、提高 Pipeline 重用性，在軟體工程裡就是重構 (Refactoring)。這些在書本都有詳細說明概念與應用。

如果再加上 Cloud Native 的流行，從傳統的地端機房，變成各種雲提供者 (AWS、GCP、Azure)，乃至於 Kubernates (K8s)，這麼複雜的條件，如何搭配 GitLab 的 Auto DevOps，也是本書會給予讀者方向與概念的。這麼複雜的條件，其實核心概念依舊脫離不了前面提到的本質： 任務、流程控制、事件驅動、以及分散式運算 ，也就是各種雲或者 K8s。

如果你有個朋友，他是初出茅廬的工程師，如果你想毀了他，那就叫他去寫自動化吧；但是如果你又想讓他覺得，你是世界上對他最好的人，那麼就介紹他 Gitlab 吧！同樣的條件之下，如果他是你的好朋友，為了拯救他於水深火熱，沒日沒夜的加班，那還是介紹他 Gitlab 吧！他上車了，但卻沒有人教他怎麼讓順利做好 Pipeline，那就介紹他這本書，讓艦長帶他一步一步走向更好生活的路上！

技術部落格《Complete Think》 作者 Rick Hwang, 2022/10 台北

☛ 天瓏書局：和艦長一起 30 天玩轉 GitLab【第二版】（iT邦幫忙鐵人賽系列書）

上市後

updated 2022/12/16

感謝艦長贈書留念～

延伸閱讀

1. 軟體交付的四大支柱 (Four Pillars of Software Delivery)
2. 需要專職的 Release Engineer？
3. 怎樣的 CI/CD 才夠 Quality?
4. 聊聊軟體交付的濫觴 談產出物管理
5. Study Notes - Step Functions
6. 系統整合：Integrate GIT in Redmine