原文連結

如上圖所示，持續整合、持續交付和持續部署就像是方向相同的向量，但是大小不同。他們都有相同的目標：使我們的軟體開發和釋出流程更快更穩健。

這三個概念的主要差異在於採用自動化的程度。但是剛接觸這些的人就很容易被混淆，不理解他們之間的關係，實際上，他們更像是包含關係而不是互斥關係。

持續整合（CI）

開發者可能最先接觸到的就是持續整合，對於開發者而言，就是每天多次地向中心倉庫合併程式碼更新。而持續整合要做的就是，在每次的程式碼合併之後自動觸發構建和測試。

根據語言不同，可能先要編譯程式碼，在現在的環境下然後可能還要考慮構建docker映象，然後，自動測試驗證特定的程式碼單元、UI行為、應用程式效能、API可靠性等等。這些通常都認為是 “構建”階段的事。

CI充當一個安全網罩，讓開發人員在接觸到使用者之前就防止許多問題。因此，開發人員交付程式碼時更有信心，但不一定更快——部署過程可能仍然是手動的、冗長的，而且容易出錯。

開發人員所能做的最好的初始投資就是確保他們的自動化測試套件足夠全面和穩定，這樣他們就可以放心地將每一個通過測試的CI構建部署到測試環境，以及以後的生產環境中，而不需要長時間的手工QA(質量保證)過程。

第二件需要注意的事情是CI速度: 開發人員必須在10分鐘內得到CI結果，否則由於缺乏焦點和頻繁的上下文切換，他們的生產力會下降。優化CI時間的一個簡單方法是在一個強大的平臺上並行執行測試。

從持續交付（CD）到持續部署

持續交付(CD)是整個軟體釋出過程的自動化實踐。這個想法是做CI的同時，自動化地準備和追蹤產品釋出。預期的結果是，任何擁有足夠特權的人都可以在任何時候通過一次或幾次點選就可以完成產品新版本的部署。通過消除幾乎所有的手工任務，讓開發人員變得更加高效。

持續交付過程通常包括至少一個手工步驟，即確認和啟動部署到生產環境。在具有多個依賴項的複雜系統中，持續交付pipeline可能包括額外的步驟，這些步驟可以是手動的，也可以是自動的。

持續部署是在持續交付的基礎上，將原始碼的每次變更都自動部署到生產環境中，整個過程不再需要開發人員的確認。開發人員只需要檢查來自隊友的pull請求並將其合併到主分支。這時，一個CI/CD服務接管了執行所有測試並將程式碼部署到生產環境中的任務，同時要讓團隊知曉每個重要事件的結果。

當然，持續部署可能更需要一個強大的監控系統、團隊的隨時待命和快速恢復能力作為堅強後盾。