和艦長一起 30 天玩轉 GitLab【第二版】- 推薦序完整版


只要是軟體開發,不管 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 最核心的有三件事情: BuildDelivery 、以及把這兩件事連接起來的 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


Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲