持續整合是一種軟體開發實踐， 即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就是意味著每天可能發生多次整合，每次整合都通過自動化的構建（包括編譯、發布、自動化測試）來驗證，從而盡早地發現整合錯誤。
1， 快速發現錯誤。每完成一點更新，就整合到主幹、可以快速發現錯誤，定位錯誤也比較容易。
2， 防止大幅偏離主幹。如果不是經常整合，主幹又在不斷更新，會導致以後整合難度變大，甚至難以整合。
martin fowler說過「持續整合並不能消除bug，而是讓他們非常容易發現和改正。」
持續交付值得是頻繁地將軟體的新版本交付給質量團隊或者使用者，以供評審。如果評審過了，**就是進入生產階段。
持續交付可以看做是持續整合的下一步，它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。
持續部署是持續交付的下一步，指的是通過評審以後，自動部署到生產環境。
持續部署的目標是，**在任何時刻都是可以部署的，可以進入生產階段。
持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別就是在最後一步，乙個是「手動」部署到生產環境，乙個是自動部署到生產環境。
第一步，提交
開發者向**庫提交diam，或者是**合併到主幹分支（取決團隊規定的開發流程，有的是本地執行單元測試過了就可以合併到主分支， 有的團隊是先提交自己的分支，然後構建personal build，通過測試後再合併到主幹分支）
第二步，測試
**庫對commit設定鉤子hook，提交**或者合併到主幹，自動觸發測試。
測試分為好幾種：
單元測試：這對函式或者模組的測試
整合測試：針對整體產品的某個功能測試，又稱功能測試。
端對端測試：從使用者介面到資料庫的全鏈路測試。
第三步，構建
通過測試後，**可以合併到主幹，就可以開始構建了，所謂構建就是講源**轉換為可裕興的實際**，比如安裝依賴，配置各種資源（css js ，初始資料）等等
第四部，測試（端對端測試）
構建完成後，需要進行全面的測試，需要自動化測試，
第五步，部署
通過第四步的測試後，**就是乙個可以部署的構件（artifact）了。可以將這個版本打包存檔。 也可以呼叫ansible chef等
進行部署。
第六步，回滾（如果需要的話）
一旦當前版本發生問題，就要回滾到上乙個構建的版本，
個人總結：
持續交付所有團隊都適用，但是持續部署不一定。 持續交付打包了完整的可執行的產品，但是有些產品不適合自動部署（比如有的產品部署頻率不高，或者環境複雜，或者產品的架構導致很難自動部署，例如有很多agent，如果agent不能自動公升級，就需要在所有agent機器上安裝對應ansible等工具實現部署，考慮到作業系統差異，資料庫差異，有些工作可能價效比不是很高）
參考：1，
持續整合 持續交付 持續部署
持續整合 持續整合強調開發人員提交了新 之後，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如，我們完成單...
持續整合 持續交付 持續部署
參考 1 continuous integration 持續整合 持續整合強調對於開發人員的每個提交，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。2 continuous delivery 持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執...
談談持續整合 持續交付 持續部署
經常會聽到持續整合，持續交付，持續部署，三者究竟是什麼，有何聯絡和區別呢？什麼是 持續 所謂的持續，就是說每完成乙個完整的部分，就向下個環節交付，發現問題可以馬上調整。是的問題不會放大到其他部分和後面的環節。這種做法的核心思想在於 既然事實上難以做到事先完全了解完整的 正確的需求，那麼就乾脆一小塊一...