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

1、摘要

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

做者：貓神。

2、差別

2.1 CI 持續集成

開發者儘可能時時刻刻合併開發分支至主幹分支。避免直到發佈日纔開始合併，掉入集成地獄。不管什麼時候新分支集成至項目，持續集成能夠自動化測試持續驗證應用是否正常。

2.2 CD 持續交付

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

2.3 CD 持續部署

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

3、協做

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

如今開發都講究投入產出比，那麼 CI/CD 具體須要作些什麼呢？

Continuous Intergretion 持續集成

投入：

• 須要爲每一個新特性編寫測試用例

• 須要搭建持續集成服務器，監控主幹倉庫，並自動運行測試用例

• 開發須要儘可能頻繁的合併分支，至少一天一次

產出：

• 更少的 bug，由於自動化測試能夠迴歸測試產品
• 編譯部署產品更簡化，由於集成的問題都儘早的解決了
• 開發者能夠儘可能減小上下文切換，由於構建的時候就暴露問題，儘早解決了
• 測試成本下降，由於 CI 服務器能夠一秒運行幾百個測試用例
• 測試團隊花更少的時間測試，能夠重點關注測試上的改進。

Continuous delivery 持續交付

投入：

• 須要有持續集成的基礎，測試用例須要覆蓋足夠的代碼
• 部署須要自動化，用戶只須要手動觸發，剩餘的部署應該自動化
• 團隊須要增長新特性標誌，避免未完成的新特性進入待發布的產品 產出：
• 部署軟件變得很是簡單。團隊不須要花費 n 天準備發佈。
• 能夠提升發佈頻率，加速新特性觸達用戶進程。
• 小的更改，對決策的壓力要小得多，能夠更快地迭代。

Continuous deployment 持續部署

投入：

• 測試必需要作到足夠。測試的質量將決定發佈的質量。
• 文檔建設須要和產品部署保持同步。
• 新特性的發佈須要協調其餘部門，包括售後支持&市場&推廣等。 產出：
• 快速的發佈節奏，由於每一個新特性一旦完成都會自動的發佈給用戶。
• 發佈風險下降，修復問題更容易，由於每次變動都是小步迭代發佈。
• 用戶能夠看到持續性的優化和質量提高，而不是非要等到按月，按季度，甚至按年

若是開發的是一個新項目，暫時尚未任何用戶，那麼每次提交代碼後發佈將會特別簡單，能夠隨時隨地發佈。一旦產品開始開發後，就須要提升測試文化，並確保在構建應用程序時增長代碼覆蓋率。當您準備好面向用戶發佈時，您將有一個很是好的連續部署過程，在該過程當中，全部新的更改都將在自動發佈到生產環境以前進行測試。

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

4、如何開始持續集成

4.1 瞭解測試類型

爲了得到 CI 的全部好處，每次代碼變動後，咱們須要自動運行測試用例。咱們須要在每一個分支運行測試用例，而不是僅僅在主幹分支。這樣能夠最快速的找到問題，最小化問題影響面。 在初始階段並不須要實現全部的測試類型。一開始能夠以單元測試入手，隨着時間擴展覆蓋面。

• 單元測試：範圍很是小，驗證每一個獨立方法級別的操做。
• 集成測試：保證模塊間運行正常，包括多個模塊、多個服務。
• 驗收測試：與集成測試相似，可是僅關注業務 case，而不是模塊內部自己。
• UI 測試：從用戶的角度保證呈現正確運行。

並非全部的測試都是對等的，實際運行中能夠作些取捨。

單元測試實現起來既快成本又低，由於它們主要是對小代碼塊進行檢查。另外一方面，UI 測試實施起來很複雜，運行起來很慢，由於它們一般須要啓動一個完整的環境以及多個服務來模擬瀏覽器或移動行爲。所以，實際狀況可能但願限制複雜的 UI 測試的數量，並依賴基礎上良好的單元測試來快速構建，並儘快得到開發人員的反饋。

4.2 自動運行測試

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

• 代碼託管在哪裏？CI 服務能夠訪問您的代碼庫嗎？您對代碼的生存位置有特殊的限制嗎？
• 應用程序須要哪些操做系統和資源？應用程序環境是否受支持？能安裝正確的依賴項來構建和測試軟件嗎？
• 測試須要多少資源？一些雲應用程序可能對您可使用的資源有限制。若是軟件消耗大量資源，可能但願將 CI 服務器宿主在防火牆後面。
• 團隊中有多少開發人員？當團隊實踐 CI 時，天天都會將許多更改推回到主存儲庫中。對於開發人員來講，要得到快速的反饋，您須要減小構建的隊列時間，而且您須要使用可以提供正確併發性的服務或服務器。 在過去，一般須要安裝一個獨立的 CI 服務器，如 Bamboo 或 Jenkins，但如今您能夠在雲端找到更簡單的解決方案。例如，若是您的代碼託管在 BitBucket 雲上，那麼您可使用存儲庫中的 Pipelines 功能在每次推送時運行測試，而無需配置單獨的服務器或構建代理，也無需限制併發性。
• 使用代碼覆蓋率查找未測試的代碼。一旦您採用了自動化測試，最好將它與一個測試覆蓋工具結合起來，幫助瞭解測試套件覆蓋了多少代碼庫。代碼覆蓋率定在 80%以上是很好的，但要注意不要將高覆蓋率與良好的測試套件混淆。代碼覆蓋工具將幫助您找到未經測試的代碼，但在一天結束的時候，測試的質量會產生影響。若是剛開始，不要急於得到代碼庫的 100%覆蓋率，而是使用測試覆蓋率工具來找出應用程序的關鍵部分，這些部分尚未測試並從那裏開始。
• 重構是一個添加測試的機會。若是您將要對應用程序進行重大更改，那麼應該首先圍繞可能受到影響的特性編寫驗收測試。這將爲您提供一個安全網，以確保在重構代碼或添加新功能後，原始行爲不會受到影響。

5、接受 CI 文化

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

• 儘早集成。若是很長時間不合並代碼，代碼衝突的風險就越高，代碼衝突的範圍就越廣。若是發現某些分支會影響已經存在的分支，須要增長髮布關閉標籤，避免發佈時兩個分支衝突。
• 保證編譯時時刻刻暢通。一旦發現任何編譯問題，馬上修復，不然可能會帶來更多的錯誤。測試套件須要儘快反饋測試結果，或者優先返回短期測試（單元測試）的結果，不然開發者可能就切換回開發了。一旦編譯出錯，須要通知給開發者，或者更進一步給出一個 dashboard，每一個人均可以在這裏查看編譯結果。
• 把測試用例歸入流程的一部分。確保每一個分支都有自動化測試用例。彷佛編寫測試用例拖慢了項目節奏，可是它能夠減小回歸時間，減小每次迭代帶來的 bug。並且每次測試經過後，將會很是有信息合併到主幹分支，由於新增的內容不影響之前的功能。
• 修 bug 的時候編寫測試用例。把 bug 的每一個場景都編寫成測試用例，避免再次出現。

6、集成測試 5 個步驟

1. 從最嚴格的代碼部分入手測試
2. 搭建一個自動構建的服務自動運行測試用例，在每次提交代碼後。
3. 確保團隊成員天天合併變動
4. 代碼出現問題及時修復
5. 爲每一個新實現的操做編寫測試用例。 可能看着很簡單，可是要求團隊可以真正落地。一開始你須要放慢發佈的腳步，須要和 pd、用戶溝通確保不上線沒有測試用例的新功能。咱們的建議是從小處入手，經過簡單的測試來適應新的例程，而後再着手實現更復雜更難管理的測試套件。

7、說說筆者的團隊

以上文章主要是說明團隊實現 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

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

special Sponsors

• DevOps 全流程平臺

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）