CI/CD 中的 CI 流程中該包含什麼?

2024年3月26日

💎 加入 E+ 成長計畫 與超過 300+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

前篇文章我們提到 CI 是持續整合,意思是讓多個開發者,能夠共同在同個程式碼庫中開發不同的新功能,然後能夠持續整合到某個分支上面。之所要持續做這件事,是因為開發不同功能時,程式碼可能會有衝突,而持續地整合就能及早化解衝突。

CI 流程會在程式碼推到遠端分支後開始

一般來說,CI 流程會在程式碼推到遠端分支後開始。現代的 CI 工具,會在程式碼推到遠端分支後,由 CI 的伺服器完整跑過整個 CI 流程。而現代軟體開發團隊的 CI 流程,做的不僅僅是確保程式碼合併沒有衝突。大家可以稍微回想一下,在自己的程式碼被部署之前,還會做什麼?

多數人應該第一直覺會說是 Code Review。而在 Code Review 之前有許多能夠自動化被檢查的東西,也會被放在 CI 的流程中。舉例來說,常見的包含程式碼格式化檢查、程式碼靜態檢查。

程式碼格式化檢查

程式碼格式化檢查在做的事情,是統一程式碼的格式規範,例如 JavaScript 的 Prettier。很多工程師會喜歡用兩格縮排,另外有些人喜歡四格,與其在 Code Review 花時間爭論要兩格還是四格,團隊可以直接有規範,然後在 CI 的時候用格式化檢查的工具,來掃過程式碼,確保每個有符合團隊設定的格式風格。

靜態檢查

同樣地靜態檢查工具,會對程式碼做靜態分析,然後掃過程式碼,確保有符合團隊所設立的相關規則,或者有符合程式語言的規則。舉例來說,TypeScript 的 TSLint 會幫忙檢查程式碼是否符合 TypeScript 的規則。很多工程師自己沒注意到的,很可能在靜態檢查被找出來,這能避免有問題的程式碼被合併。

自動化測試

除了上面提到的兩項檢查,多數團隊也會在 CI 流程中,加入自動化測試的環節。包含單元測試、整合測試、E2E 測試,如果新推到遠端分支的程式碼,沒有通過任一項測試,CI 工具就會報錯,並且推送通知給相關人員。透過這方式,我們能確保程式碼在合併前,有經過完整的測試,這樣能確保程式碼的正確性與品質有被兼顧到。

順利被建構

當然除了上面提到的這些各類檢測,CI 中的最重要環節之一,是確保程式碼能夠被編譯以及建構。為了確保不會浪費運算資源,通常會是在上面這些檢測都通過後,才會建構。而要能順利被建構,程式碼才能被部署。

在業界,許多軟體開發團隊會在 CI 當中加入其他更精細的檢測,例如針對安全 (security) 做檢測,避免寫出有潛在漏洞的程式碼;或者對效能 (performance) 做檢測,來確保程式碼的效能有達到一定的門檻。你可以針對團隊的需求,在 CI 中加入各類自動化做的檢測,確保團隊的工程品質能維持。

而回到 CI 最核心的作用,是透過自動化的方式,讓工程師可以在把程式碼推到遠端分支後,不用自己手動,就能完成這些重要的檢測,並完成程式碼的整合。


相關文章

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們