以下源引于網絡，非本人原創，純粹是為了友善了解和回顧
持續內建
強調開發人員送出了新代碼之後，立刻進行建構、（單元）測試。根據測試結果，我們可以确定新代碼和原有代碼能否正确地內建在一起。
確定新增的代碼能夠與原先代碼正确的內建
- 開發人員送出代碼到 Source Repository （源代碼倉庫），并通過 git hook 等
- 觸發 CI Server（持續內建伺服器）的相關功能。執行 編譯 -> 測試 -> 輸出結果 的流程，
- 向開發人員回報結果的 report
好處：
- 易于定位錯誤：每一次的代碼內建都需要執行相關的測試工作，持續內建頻繁的內建次數天然的将複雜的代碼邏輯切割為了小塊，也就使得每一次測試中遇到的錯誤能夠更加容易的被定位；
- 易于控制開發流程：更為細緻的工作送出也就意味着更容易判斷目前的工作進度，這對于管理者規劃開發流程而言提供了一個有效的參考，同時也為開發人員省下了彙報工作的時間；
- 易于CodeReview：對于大塊工作的切分自然也有助于做 CodeReview；
- 易于減少不必要的工作：build 以及 test 過程的自動化可以為你節約一大票的時間，進而投入到有價值的工作中去。
持續傳遞
強調客戶功能傳遞，使得軟體在較短的循環中可靠的釋出的軟體工程方法。在持續內建的基礎上，将內建後的代碼部署到更貼近真實運作環境的「類生産環境」（production-like environments）中。比如，我們完成單元測試後，可以把代碼部署到連接配接資料庫的 Staging 環境中更多的測試。如果代碼沒有問題，可以繼續手動部署到生産環境中。
與 持續內建 相比較，持續傳遞 添加了 Test -> Staging（模拟環境） -> Production 的流程，也就是為新增的代碼添加了一個保證： 確定新增的代碼在生産環境中是可用的 。
從開發到運維的工作能夠穩定地快速流動，確定不會造成生産環境的混亂或客戶服務的中斷。需要降低在生産環境中部署和釋出變更的風險。
在這一增加的流程中，Test 環節不僅僅包含基本的單元測試，還需要延伸到更為複雜的功能測試以及內建測試等。在這裡，Staging 指的是 類生産環境 ，其盡可能的對真實的網絡拓撲、資料庫資料以及硬體裝置等資源進行模拟，進而為測試人員回報代碼在生成環境中的可能表現。流程中每一個環節的執行結果都會對開發人員進行回報，每一個出現的錯誤都會導緻版本的復原。當測試完畢确認無誤之後，将由相關人員對其進行 手動部署到生産環境。
持續部署
強調自動化，則是在持續傳遞的基礎上，把部署到生産環境的過程自動化
通過自動化部署的手段将軟體功能頻繁的進行傳遞。與持續傳遞以及持續內建相比，持續部署強調了通過 automated deployment 的手段，對新的軟體功能進行內建。
強調 Production 的自動化。從開發人員送出代碼到編譯、測試、部署的全流程不需要人工的幹預，完全通過自動化的方式執行。這一政策加快了代碼送出到功能上線的速度，保證新的功能能夠第一時間部署到生産環境并被使用。
總結
對于 持續內建、 持續傳遞 和 持續部署 三者的了解是：
- 持續內建 是三者中最簡單的，同時也是開銷最低的。由于不需要類生産環境的配合，測試環境也可以僅支援單元測試的執行，使得持續內建的實作是最為便宜的。考慮到現實開發過程的種種限制，向資源與成本做妥協，舍棄持續傳遞或者持續部署這樣看起來很美的方法，退而轉向持續內建也是很合理的選擇；
- 持續傳遞 面向開發初期或者軟體穩定性或者安全性要求較高的領域，新增代碼送出、編譯、測試等一系列環節均可以通過自動化工具完成，很好的節約了人力資源的同時，還對新增代碼的功能進行了有效的保障。在手動執行的部署環節，還可以添加在執行完畢标準測試之外的可能需求，以保證釋出功能的可靠；
- 持續部署 面向穩定的釋出上線後的功能更新。自動的，無需人工幹預的部署可以保證新增功能第一時間被釋出到生産環境中，確定其盡快的被使用者所使用。其與持續傳遞相比，就在于其功能可靠性與功能及時性的側重不同。
阮一峰：http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
DevOps 更偏向于一種文化的建構，在 DevOps 文化指導下，團隊中将包含了具有不同技能的人員（開發、測試等），并通過自動化測試與釋出的手段，更快、更高品質的生産軟體。
handoff-傳遞，release-釋出，operate-營運
出處：轉載請注明 https://www.cnblogs.com/sun-null/