摘要：持續交付持續交付是持續集成的擴展，可以保證穩定的發布產品新特性。持續部署持續部署是持續交付的下一步。持續部署可以加速用戶反饋新特性，避免發布日帶來的壓力。單元測試范圍非常小，驗證每個獨立方法級別的操作。

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

作者：貓神。

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

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

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

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

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

投入：

需要為每個新特性編寫測試用例

需要搭建持續集成服務器，監控主干倉庫，并自動運行測試用例

開發需要盡量頻繁的合并分支，至少一天一次

產出：

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

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

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

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

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

投入：

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

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

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

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

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

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

投入：

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

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

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

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

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

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

如果開發的是一個新項目，暫時還沒有任何用戶，那么每次提交代碼后發布將會特別簡單，可以隨時隨地發布。一旦產品開始開發后，就需要提高測試文化，并確保在構建應用程序時增加代碼覆蓋率。當您準備好面向用戶發布時，您將有一個非常好的連續部署過程，在該過程中，所有新的更改都將在自動發布到生產環境之前進行測試。

如果正在開發的是一個老系統，就需要放慢節奏，開始打造持續集成&持續交付。首先可以完成一些簡單可自動化執行的單元測試，不需要考慮復雜的端到端的測試。另外，應該盡快嘗試自動化部署，搭建可以自動化部署的臨時環境。因為自動化部署，可以讓開發者去優化測試用例，而不是停下來聯調發布。
一旦開始按日發布產品，我們可以考慮持續部署，但一定要保證團隊已經準備好這種方式，文檔 & 售后支持 & 市場。這些步驟都需要加入到新產品發布節奏中，因為和用戶直接打交道的是他們。

為了獲得 CI 的所有好處，每次代碼變更后，我們需要自動運行測試用例。我們需要在每個分支運行測試用例，而不是僅僅在主干分支。這樣可以最快速的找到問題，最小化問題影響面。
在初始階段并不需要實現所有的測試類型。一開始可以以單元測試入手，隨著時間擴展覆蓋面。

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

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

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

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

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

單元測試實現起來既快成本又低，因為它們主要是對小代碼塊進行檢查。另一方面，UI 測試實施起來很復雜，運行起來很慢，因為它們通常需要啟動一個完整的環境以及多個服務來模擬瀏覽器或移動行為。因此，實際情況可能希望限制復雜的 UI 測試的數量，并依賴基礎上良好的單元測試來快速構建，并盡快獲得開發人員的反饋。

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

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

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

測試需要多少資源？一些云應用程序可能對您可以使用的資源有限制。如果軟件消耗大量資源，可能希望將 CI 服務器宿主在防火墻后面。

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

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

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

自動化測試是 CI 的關鍵，但同時也需要團隊成員接受 CI 文化，并不是心血來潮曬兩天魚，并且需要保證編譯暢通無阻。QA 可以幫助團隊建設測試文化。他們不再需要手動測試應用程序的瑣碎功能，現在他們可以投入更多的時間來提供支持開發人員的工具，并幫助他們采用正確的測試策略。一旦開始采用持續集成，QA 工程師將能夠專注于使用更好的工具和數據集促進測試，并幫助開發人員提高編寫更好代碼的能力。

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

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

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

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

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

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

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

代碼出現問題及時修復

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

以上文章主要是說明團隊實現 CI/CD 的取舍和可行性步驟。下面來說說希望 CI/CD 給筆者團隊帶來什么樣的變化。目前筆者團隊已經實現前端項目發布編譯工程化，采用的是基于 webpack 的自建工具云構建模式。但現在面臨的問題是 1. 交互的系統比較多，交互系統提供的接入源變更后，需要人工通知其他系統手動觸發編譯，而且每次手動編譯都需要在本地切換到指定分支，然后手動觸發云構建，2. 多人協作，分支拆分較細，需要手動合并分支，觸發編譯。整個流程冗長，而且中間存在人力溝通成本，容易產生溝通誤差。所以首先希望解決的是 CI 自動化，當依賴變更后或者分支合并后，自動集成，自動編譯。當然生產環境暫時還不敢瞎搞，但大部分重復編譯的工作量主要集中在預發環境，所以手動部署生產環境的成本還是可以接受的。CI 自動化之前，需要提供系統之間交互的單元測試用例，每次 CI 后自動運行單元測試用例，最好能打通 QA 的測試用例，進行回歸測試。流程對比如下：

可以看出引入CI后，我們的成本是需要搭建CI服務器，新增單元測試、打通回歸測試案例，但前者可以加快系統編譯效率，后者可以進一步的提升代碼質量，減少回歸測試時間，這些成本都是可以接受的。市面上已有很多開源持續集成工具，例如我們熟悉的Jenkins，還有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。目前還在繼續調研中，這片文章應該會有第二篇，說說后續的實踐和CD。

討論地址是：精讀《持續集成 vs 持續交付 vs 持續部署》 · Issue #147 · dt-fe/weekly

如果你想參與討論，請 點擊這里，每周都有新的主題，周末或周一發布。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公眾號