精讀《持續集成 vs 持續交付 vs 持續部署》

一、摘要

相信大家以前應該接觸過持續集成（Continuous integration）持續交付（continuous delivery）持續發布（continuous deployment）的概念，下面我們來說說三者的差異以及團隊如何入手 CI/CD。

二、差異2.1 CI 持續集成

開發者儘量時時刻刻合併開發分支至主幹分支。避免直到發布日才開始合併，掉入集成地獄。無論何時新分支集成至項目，持續集成可以自動化測試持續驗證應用是否正常。

2.2 CD 持續交付

持續交付是持續集成的擴展，可以保證穩定的發布產品新特性。這意味著基於自動化測試，你可以也可以一鍵自動化發布。理論上，持續交付可以決定是按天，按周，按雙周發布產品。如果確實希望能夠享受持續交付的好處，那麼應該儘快發布到新產品中。一旦出現問題時能儘早排除。

2.3 CD 持續部署

持續部署是持續交付的下一步。通過這一步，每個新特性都自動的部署到產品中。但是如果出現未通過的測試用例將會終止自動部署。持續部署可以加速用戶反饋新特性，避免發布日帶來的壓力。開發可以著力於開發系統，開發結束後幾分鐘就可以觸達到用戶。

三、協作

CI/CD 具體是個什麼樣的流程呢，如下圖所示，差異僅在於是否自動部署。

現在開發都講究投入產出比，那麼CI/CD 具體需要做些什麼呢？

Continuous Intergretion 持續集成

投入：

產出：

更少的bug，因為自動化測試可以回歸測試產品

編譯部署產品更簡化，因為集成的問題都儘早的解決了

開發者可以儘量減少上下文切換，因為構建的時候就暴露問題，儘早解決了

測試成本降低，因為CI伺服器可以一秒運行幾百個測試用例

測試團隊花更少的時間測試，可以重點關注測試上的改進。

Continuous delivery 持續交付

投入：

需要有持續集成的基礎，測試用例需要覆蓋足夠的代碼

部署需要自動化，用戶只需要手動觸發，剩餘的部署應該自動化

團隊需要增加新特性標誌，避免未完成的新特性進入待發布的產品
產出：

部署軟體變得非常簡單。團隊不需要花費n天準備發布。

可以提高發布頻率，加速新特性觸達用戶進程。

小的更改，對決策的壓力要小得多，可以更快地迭代。

Continuous deployment 持續部署

投入：

測試必須要做到足夠。測試的質量將決定發布的質量。

文檔建設需要和產品部署保持同步。

新特性的發布需要協調其他部門，包括售後支持&市場&推廣等。
產出：

快速的發布節奏，因為每個新特性一旦完成都會自動的發布給用戶。

發布風險降低，修復問題更容易，因為每次變更都是小步迭代發布。

用戶可以看到持續性的優化和質量提升，而不是非要等到按月，按季度，甚至按年

如果開發的是一個新項目，暫時還沒有任何用戶，那麼每次提交代碼後發布將會特別簡單，可以隨時隨地發布。一旦產品開始開發後，就需要提高測試文化，並確保在構建應用程式時增加代碼覆蓋率。

當您準備好面向用戶發布時，您將有一個非常好的連續部署過程，在該過程中，所有新的更改都將在自動發布到生產環境之前進行測試。

如果正在開發的是一個老系統，就需要放慢節奏，開始打造持續集成&持續交付。首先可以完成一些簡單可自動化執行的單元測試，不需要考慮複雜的端到端的測試。另外，應該儘快嘗試自動化部署，搭建可以自動化部署的臨時環境。因為自動化部署，可以讓開發者去優化測試用例，而不是停下來聯調發布。

一旦開始按日發布產品，我們可以考慮持續部署，但一定要保證團隊已經準備好這種方式，文檔 & 售後支持 & 市場。這些步驟都需要加入到新產品發布節奏中，因為和用戶直接打交道的是他們。

四、如何開始持續集成4.1 了解測試類型

為了獲得 CI 的所有好處，每次代碼變更後，我們需要自動運行測試用例。我們需要在每個分支運行測試用例，而不是僅僅在主幹分支。這樣可以最快速的找到問題，最小化問題影響面。

在初始階段並不需要實現所有的測試類型。一開始可以以單元測試入手，隨著時間擴展覆蓋面。

單元測試：範圍非常小，驗證每個獨立方法級別的操作。

集成測試：保證模塊間運行正常，包括多個模塊、多個服務。

驗收測試：與集成測試類似，但是僅關注業務case，而不是模塊內部本身。

UI測試：從用戶的角度保證呈現正確運行。

並不是所有的測試都是對等的，實際運行中可以做些取捨。

單元測試實現起來既快成本又低，因為它們主要是對小代碼塊進行檢查。另一方面，UI測試實施起來很複雜，運行起來很慢，因為它們通常需要啟動一個完整的環境以及多個服務來模擬瀏覽器或移動行為。

因此，實際情況可能希望限制複雜的UI測試的數量，並依賴基礎上良好的單元測試來快速構建，並儘快獲得開發人員的反饋。

4.2 自動運行測試

要採用持續集成，您需要對推回到主分支的每個變更運行測試。要做到這一點，您需要有一個服務來監視您的存儲庫，並聽取對代碼庫的新推送。您可以從企業預置型解決方案和雲端解決方案中進行選擇。您需要考慮以下因素來選擇伺服器：

代碼託管在哪裡？CI服務可以訪問您的代碼庫嗎？您對代碼的生存位置有特殊的限制嗎？

應用程式需要哪些作業系統和資源？應用程式環境是否受支持？能安裝正確的依賴項來構建和測試軟體嗎？

測試需要多少資源？一些雲應用程式可能對您可以使用的資源有限制。如果軟體消耗大量資源，可能希望將CI伺服器宿主在防火牆後面。

團隊中有多少開發人員？當團隊實踐CI時，每天都會將許多更改推回到主存儲庫中。對於開發人員來說，要獲得快速的反饋，您需要減少構建的隊列時間，並且您需要使用能夠提供正確並發性的服務或伺服器。
在過去，通常需要安裝一個獨立的CI伺服器，如Bamboo或Jenkins，但現在您可以在雲端找到更簡單的解決方案。例如，如果您的代碼託管在BitBucket雲上，那麼您可以使用存儲庫中的Pipelines功能在每次推送時運行測試，而無需配置單獨的伺服器或構建代理，也無需限制並發性。

使用代碼覆蓋率查找未測試的代碼。一旦您採用了自動化測試，最好將它與一個測試覆蓋工具結合起來，幫助了解測試套件覆蓋了多少代碼庫。代碼覆蓋率定在80%以上是很好的，但要注意不要將高覆蓋率與良好的測試套件混淆。代碼覆蓋工具將幫助您找到未經測試的代碼，但在一天結束的時候，測試的質量會產生影響。如果剛開始，不要急於獲得代碼庫的100%覆蓋率，而是使用測試覆蓋率工具來找出應用程式的關鍵部分，這些部分還沒有測試並從那裡開始。

重構是一個添加測試的機會。如果您將要對應用程式進行重大更改，那麼應該首先圍繞可能受到影響的特性編寫驗收測試。這將為您提供一個安全網，以確保在重構代碼或添加新功能後，原始行為不會受到影響。

五、接受 CI 文化

自動化測試是CI的關鍵，但同時也需要團隊成員接受CI文化，並不是心血來潮曬兩天魚，並且需要保證編譯暢通無阻。QA可以幫助團隊建設測試文化。

他們不再需要手動測試應用程式的瑣碎功能，現在他們可以投入更多的時間來提供支持開發人員的工具，並幫助他們採用正確的測試策略。一旦開始採用持續集成，QA工程師將能夠專注於使用更好的工具和數據集促進測試，並幫助開發人員提高編寫更好代碼的能力。

儘早集成。如果很長時間不合併代碼，代碼衝突的風險就越高，代碼衝突的範圍就越廣。如果發現某些分支會影響已經存在的分支，需要增加發布關閉標籤，避免發布時兩個分支衝突。

保證編譯時時刻刻暢通。一旦發現任何編譯問題，立刻修復，否則可能會帶來更多的錯誤。測試套件需要儘快反饋測試結果，或者優先返回短時間測試（單元測試）的結果，否則開發者可能就切換回開發了。一旦編譯出錯，需要通知給開發者，或者更進一步給出一個dashboard，每個人都可以在這裡查看編譯結果。

把測試用例納入流程的一部分。確保每個分支都有自動化測試用例。似乎編寫測試用例拖慢了項目節奏，但是它可以減少回歸時間，減少每次迭代帶來的bug。而且每次測試通過後，將會非常有信息合併到主幹分支，因為新增的內容不影響以前的功能。

修 bug的時候編寫測試用例。把bug的每個場景都編寫成測試用例，避免再次出現。

六、集成測試 5 個步驟

從最嚴格的代碼部分入手測試

搭建一個自動構建的服務自動運行測試用例，在每次提交代碼後。

確保團隊成員每天合併變更

代碼出現問題及時修復

為每個新實現的操作編寫測試用例。

可能看著很簡單，但是要求團隊能夠真正落地。一開始你需要放慢發布的腳步，需要和pd、用戶溝通確保不上線沒有測試用例的新功能。我們的建議是從小處入手，通過簡單的測試來適應新的例程，然後再著手實現更複雜更難管理的測試套件。

七、說說筆者的團隊

以上文章主要是說明團隊實現CI/CD的取捨和可行性步驟。下面來說說希望CI/CD給筆者團隊帶來什麼樣的變化。

目前筆者團隊已經實現前端項目發布編譯工程化，採用的是基於webpack的自建工具雲構建模式。

但現在面臨的問題是

交互的系統比較多，交互系統提供的接入源變更後，需要人工通知其他系統手動觸發編譯，而且每次手動編譯都需要在本地切換到指定分支，然後手動觸發雲構建。

多人協作，分支拆分較細，需要手動合併分支，觸發編譯。整個流程冗長，而且中間存在人力溝通成本，容易產生溝通誤差。所以首先希望解決的是 CI 自動化，當依賴變更後或者分支合併後，自動集成，自動編譯。

當然生產環境暫時還不敢瞎搞，但大部分重複編譯的工作量主要集中在預發環境，所以手動部署生產環境的成本還是可以接受的。

CI 自動化之前，需要提供系統之間交互的單元測試用例，每次CI後自動運行單元測試用例，最好能打通QA的測試用例，進行回歸測試。流程對比如下：

可以看出引入CI後，我們的成本是需要搭建CI伺服器，新增單元測試、打通回歸測試案例，但前者可以加快系統編譯效率，後者可以進一步的提升代碼質量，減少回歸測試時間，這些成本都是可以接受的。

市面上已有很多開源持續集成工具，例如我們熟悉的Jenkins，還有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。

目前還在繼續調研中，這片文章應該會有第二篇，說說後續的實踐和CD。

本文授權轉載自：前端精讀周刊