 |
VOOZH | about |
|
VOOZH | about |
經常會聽到持續集成，持續交付，持續部署，三者究竟是什麼，有何聯繫和區別呢？
假如把開發工作流程分為以下幾個階段：
編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署
正如你在上圖中看到，「持續集成（Continuous Integration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」有著不同的軟體自動化交付周期。
持續集成持續集成是指軟體個人研發的部分向軟體整體部分交付，頻繁進行集成以便更快地發現其中的錯誤。「持續集成」源自於極限編程（XP），是 XP 最初的 12 種實踐之一。
最重要的一環是選擇合適的持續集成系統。是搭建私有部署還是選擇託管型持續集成系統，關鍵在於團隊運行的基礎設施，團隊對持續集成系統的資源投入力度。
對比一下私有部署和託管型持續集成系統，或許能幫助你更好地做出選擇。
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 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成為未來軟體工程的重要組成部分。
歡迎分享你的觀點。
