CI/CD 中的 CI 流程中該包含什麼?
2024年3月26日
前篇文章我們提到 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 最核心的作用，是透過自動化的方式，讓工程師可以在把程式碼推到遠端分支後，不用自己手動，就能完成這些重要的檢測，並完成程式碼的整合。
