經常會聽到持續整合，持續交付，持續部署，三者究竟是什麼，有何聯絡和區別呢？什麼是“持續”？

所謂的持續，就是說每完成一個完整的部分，就向下個環節交付，發現問題可以馬上調整。是的問題不會放大到其他部分和後面的環節。

這種做法的核心思想在於：既然事實上難以做到事先完全瞭解完整的、正確的需求，那麼就乾脆一小塊一小塊的做，並且加快交付的速度和頻率，使得交付物儘早在下個環節得到驗證。早發現問題早返工。

假如把開發工作流程分為以下幾個階段：編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署

The Product Managers' Guide to Continuous Delivery and DevOps

持續整合

持續整合指的是，頻繁地（一天多次）將程式碼整合到主幹。強調開發人員提交了新程式碼之後，立刻進行構建、（單元）測試。根據測試結果，我們可以確定新程式碼和原有程式碼能否正確地整合在一起。

好處在於： 快速發現錯誤。每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。

持續整合的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，程式碼整合到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能整合。

Martin Fowler說過，"持續整合並不能消除Bug，而是讓它們非常容易發現和改正。"

持續交付

持續交付（Continuous delivery）指的是，頻繁地將軟體的新版本，交付給質量團隊或者使用者，以供評審。如果評審通過，程式碼就進入生產階段。

持續交付可以看作持續整合的下一步。它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。

持續交付在持續整合的基礎上，將整合後的程式碼部署到更貼近真實執行環境的「類生產環境」（production-like environments）中。比如，我們完成單元測試後，可以把程式碼部署到連線資料庫的 Staging 環境中更多的測試。如果程式碼沒有問題，可以繼續手動部署到生產環境中。

持續交付在持續整合的基礎上，將整合後的程式碼部署到更貼近真實執行環境的「類生產環境」（production-like environments）中。持續交付優先於整個產品生命週期的軟體部署，建立在高水平自動化持續整合之上。

試想想，如果說等到所有東西都完成了才向下個環節交付，導致所有的問題在最後爆發出來，解決成本巨大甚至無法解決。比如，我們完成單元測試後，可以把程式碼部署到連線資料庫的 Staging 環境中進行更多的自動化測試。如果程式碼沒有問題，可以繼續手動部署到生產環境中。當然，持續交付並不是指軟體每一個改動都要儘快部署到產品環境中，它指的是任何的程式碼修改都可以在任何時候實施部署。

持續部署

持續部署（continuous deployment）是持續交付的下一步，指的是程式碼通過評審以後，自動部署到生產環境。

持續部署的目標是，程式碼在任何時刻都是可部署的，可以進入生產階段。

持續部署則是在持續交付的基礎上，把部署到生產環境的過程自動化。

持續整合、持續交付、持續部署恰恰可以早發現早解決，從而可以避免這個問題。

參考