持續內建（Continuous integration， 簡稱CI），
持續內建是一種軟體開發實踐， 即團隊開發成員經常內建他們的工作，通常每個成員每天至少內建一次，也就是意味着每天可能發生多次內建，每次內建都通過自動化的建構（包括編譯、釋出、自動化測試）來驗證，進而盡早地發現內建錯誤。
好處
1， 快速發現錯誤。每完成一點更新，就內建到主幹、可以快速發現錯誤，定位錯誤也比較容易。
2， 防止大幅偏離主幹。如果不是經常內建，主幹又在不斷更新，會導緻以後內建難度變大，甚至難以內建。
Martin Fowler說過“持續內建并不能消除Bug，而是讓他們非常容易發現和改正。”
持續傳遞 （Continuous delivery）
持續傳遞值得是頻繁地将軟體的新版本傳遞給品質團隊或者使用者，以供評審。如果評審過了，代碼就是進入生産階段。
持續傳遞可以看做是持續內建的下一步，它強調的是，不管怎麼更新，軟體是随時随地可以傳遞的。
持續部署（Contiuous deployment）
持續部署是持續傳遞的下一步，指的是通過評審以後，自動部署到生産環境。
持續部署的目标是，代碼在任何時刻都是可以部署的，可以進入生産階段。
持續部署的前提是能自動化完成測試、建構、部署等步驟。它與持續傳遞的差別就是在最後一步，一個是“手動”部署到生産環境，一個是自動部署到生産環境。
持續傳遞vs持續部署
持續內建 vs 持續傳遞vs持續部署
基本流程
第一步，送出
開發者向代碼庫送出diam，或者是代碼合并到主幹分支（取決團隊規定的開發流程，有的是本地運作單元測試過了就可以合并到主分支， 有的團隊是先送出自己的分支，然後建構personal build，通過測試後再合并到主幹分支）
第二步，測試
代碼庫對commit設定鈎子hook，送出代碼或者合并到主幹，自動觸發測試。
測試分為好幾種：
單元測試：這對函數或者子產品的測試
內建測試：針對整體産品的某個功能測試，又稱功能測試。
端對端測試：從使用者界面到資料庫的全鍊路測試。
第三步，建構
通過測試後，代碼可以合并到主幹，就可以開始建構了，所謂建構就是講源代碼轉換為可裕興的實際代碼，比如安裝依賴，配置各種資源（css js 圖檔，初始資料）等等
第四部，測試（端對端測試）
建構完成後，需要進行全面的測試，需要自動化測試，
第五步，部署
通過第四步的測試後，代碼就是一個可以部署的構件（artifact）了。可以将這個版本打包存檔。 也可以調用Ansible Chef等
進行部署。
第六步，復原（如果需要的話）
一旦目前版本發生問題，就要復原到上一個建構的版本，
個人總結：
持續傳遞所有團隊都适用，但是持續部署不一定。 持續傳遞打包了完整的可運作的産品，但是有些産品不适合自動部署（比如有的産品部署頻率不高，或者環境複雜，或者産品的架構導緻很難自動部署，例如有很多agent，如果agent不能自動更新，就需要在所有agent機器上安裝對應Ansible等工具實作部署，考慮到作業系統差異，資料庫差異，有些工作可能成本效益不是很高）
參考：
1， https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff