假如把開發工作流程分爲以下幾個階段：
編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署
正如你在上圖中看到，「持續集成(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 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成爲未來軟件工程的重要組成部分。
歡迎分享你的觀點。
本文轉載自：http://www.linuxprobe.com/continuous-integration.html
免費提供最新Linux技術教程書籍，爲開源技術愛好者努力做得更多更好，開源站點：http://www.linuxprobe.com/
假如把開發工作流程分爲以下幾個階段：
編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署
正如你在上圖中看到，「持續集成(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 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成爲未來軟件工程的重要組成部分。
歡迎分享你的觀點。
