持續集成，持續交付，持續部署之間的區別

常常會聽到持續集成，持續交付，持續部署，三者到底是什麼，有何聯繫和區別呢？

假如把開發工做流程分爲如下幾個階段：

編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署

正如你在上圖中看到，「持續集成（Continuous Integration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」有着不一樣的軟件自動化交付週期。

 

持續集成

持續集成是指軟件我的研發的部分向軟件總體部分交付，頻繁進行集成以便更快地發現其中的錯誤。「持續集成」源自於極限編程（XP），是 XP 最初的 12 種實踐之一。

 

CI 須要具有這些：

• 全面的自動化測試。這是實踐持續集成&持續部署的基礎，同時，選擇合適的自動化測試工具也極其重要；
• 靈活的基礎設施。容器，虛擬機的存在讓開發人員和 QA 人員沒必要再大費周折；
• 版本控制工具。如 Git，CVS，SVN 等；
• 自動化的構建和軟件發佈流程的工具，如 Jenkins，flow.ci；
• 反饋機制。如構建/測試的失敗，能夠快速地反饋到相關負責人，以儘快解決達到一個更穩定的版本。

 

持續集成的優勢

• 「快速失敗」，在對產品沒有風險的狀況下進行測試，並快速響應；
• 最大限度地減小風險，下降修復錯誤代碼的成本；
• 將重複性的手工流程自動化，讓工程師更加專一於代碼；
• 保持頻繁部署，快速生成可部署的軟件；
• 提升項目的能見度，方便團隊成員瞭解項目的進度和成熟度；
• 加強開發人員對軟件產品的信心，幫助創建更好的工程師文化。

 

持續集成，該從何入手

最重要的一環是選擇合適的持續集成系統。是搭建私有部署仍是選擇託管型持續集成系統，關鍵在於團隊運行的基礎設施，團隊對持續集成系統的資源投入力度。

對比一下私有部署和託管型持續集成系統，或許能幫助你更好地作出選擇。

• Self Hosted CI 指的是將軟件部署在公司的機房或內網中，須要提供多臺服務器來完成 CI 系統的運轉，同時須要對不一樣機器之間進行環境配置。好比Maven 或 Gradle 或 Jenkins ，他們的特色是自由開源，且文檔支持普遍。優勢在於對構建環境有徹底的控制權，可以實現徹底定製。但須要搭建環境和配置、維護成本高，須要買專門的機器，花費較多人力物力且更新遷移風險高；

• Hosted CI 指的是由 SaaS 型的 CI 服務，全程在線進行構建配置，不須要考慮裝機器，裝軟件，環境搭建等成本。常見的有 CircleCI，Codeship 和 TravisCI 等，還有國內最新的持續集成服務——flow.ci。SaaS 型的 CI 的特色在於無需額外機器，幾分鐘就能夠用起來。能夠根據你的須要動態調度資源。省時，省心，省力。

總體而言，Jenkins 過去一直是大部分公司的選擇，但這個現象正在發生改變，隨着公有云服務、Docker，SaaS 的普及，愈來愈多的企業開始選擇 Hosted CI，也就是託管型持續集成系統。

另外，在選擇合適的持續集成服務時，還須要考量系統的靈活度以適應公司不一樣階段的開發測試需求。

選擇持續集成系統只是持續集成應用的其中一步，還須要創建合適的持續集成文化好比代碼質量管控、測試文化等。作好持續集成，可爲持續交付與持續部署打好堅實基礎。

 

持續交付

持續交付在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」（production-like environments）中。持續交付優先於整個產品生命週期的軟件部署，創建在高水平自動化持續集成之上。

試想一想，若是說等到全部東西都完成了才向下個環節交付，致使全部的問題只能再最後才爆發出來，解決成本巨大甚至沒法解決。好比，咱們完成單元測試後，能夠把代碼部署到鏈接數據庫的 Staging 環境中進行更多的自動化測試。若是代碼沒有問題，能夠繼續手動部署到生產環境中。固然，持續交付並非指軟件每個改動都要儘快部署到產品環境中，它指的是任何的代碼修改均可以在任什麼時候候實施部署。

 

持續交付的好處

持續交付和持續集成的優勢很是類似：

• 快速發佈。可以應對業務需求，並更快地實現軟件價值。
• 編碼->測試->上線->交付的頻繁迭代週期縮短，同時得到迅速反饋；
• 高質量的軟件發佈標準。整個交付過程標準化、可重複、可靠，
• 整個交付過程進度可視化，方便團隊人員瞭解項目成熟度；
• 更先進的團隊協做方式。從需求分析、產品的用戶體驗到交互 設計、開發、測試、運維等角色密切協做，相比於傳統的瀑布式軟件團隊，更少浪費。

 

持續部署

持續部署是指當交付的代碼經過評審以後，自動部署到生產環境中。持續部署是持續交付的最高階段。這意味着，全部經過了一系列的自動化測試的改動都將自動部署到生產環境。它也能夠被稱爲「Continuous Release」。

爲何說持續部署是理想的工做流程？

「開發人員提交代碼，持續集成服務器獲取代碼，執行單元測試，根據測試結果決定是否部署到預演環境，若是成功部署到預演環境，進行總體驗收測試，若是測試經過，自動部署到產品環境，全程自動化高效運轉。」

實際上，產品在從需求到部署的過程當中，會經歷若干種不一樣的環境，例如 QA 環境、各類自動化測試運行環境、生產環境等。這些環境的搭建、配置、管理，產品在不一樣環 境中的具體部署，情況是比較很是複雜的，從頭至尾地全自動持續部署的確困難。那麼，若是能作到持續交付，保證代碼在模擬環境沒問題，也許團隊成員作到真正的心理有數。

 

持續部署的優勢

持續部署主要好處是，能夠相對獨立地部署新的功能，並能快速地收集真實用戶的反饋。

「You build it, you run it」，這是 Amazon 一年能夠完成 5000 萬次部署，平均每一個工程師天天部署超過 50 次的核心祕籍。

 

最後

「持續集成（Continuous Integration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」提供了一個優秀的 DevOps 環境，對於整個團隊來講，好處與挑戰並行。不管如何，頻繁部署、快速交付以及開發測試流程自動化都將成爲將來軟件工程的重要組成部分。