持續集成（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