背景

持續集成和持續部署這兩個術語傾向于組合成首字母縮略詞CI / CD，通常兩者之間沒有任何區別。由此可以很容易地假設持續部署是持續集成的擴展，并且兩個過程的執行都是單個工具的責任。

假設CI / CD 只是具有部署步驟的CI，則忽略了兩個進程之間的一些基本差異。在文中，我們將看看：

什么是持續集成？

在高層次上，CI就是將開發人員編寫的代碼編譯打包，運行自動化測試并捕獲日志文件，以便解決任何失敗的構建或測試。CI服務器通過在每次提交時運行構建和測試來實現此過程。

CI過程可以描述為等式：

代碼+依賴項+構建工具+執行環境=測試結果+日志+編譯包

等式的左邊是開發人員編寫的代碼，代碼的任何依賴關系，構建工具以及執行構建和測試的環境。當這些輸入可用時，CI服務器完成構建以生成等式右側的元素。

正確配置CI服務器后，對存儲庫的每次提交都會導致構建正在運行，從而解決方程式而無需人工干預。

這意味著CI過程是機器驅動的，因此CI服務器通常具有只讀用戶界面，如Jenkins Blue Ocean UI。

CI方程的另一個重要方面是開發人員提供輸入，并為開發人員或其他技術角色的人員創建輸出。IT部門以外的員工很少與CI服務器交互。

從字面上看，CD從CI服務器執行的成功構建中獲取編譯的包，并將它們部署到生產環境中。在這種情況下，CD完全正確地是CI的擴展，并且兩者之間的區別變得簡單。

這種提交到消費者的管道在簡單的項目中很常見。只要已經建立了適當的測試和監控系統，更復雜的項目也可以擁有完全自動化的開發流程。

但是，雖然完全自動化部署具有許多優點，但部署涉及人為決策的情況并不少見。有許多正當理由不能自動將每個提交到主分支的部署到生產中，包括：

CI是機器驅動的，對于許多團隊而言，CD是人為驅動的。執行部署的大部分工作仍然是自動化的，但是促進從發布到生產的決定是人為的。重要的是，技術人員可能不會做出決定，而是產品所有者，經理或熬夜到午夜點擊部署按鈕的人。

為什么要使用單獨的CI和CD工具？

這是一個典型的例子，說明簡單的項目如何將CI和CD合并到一個流程中，一旦編譯完代碼就開始生產部署。

這個過程沒有任何問題，只要管道的每個部分都保持完全自動化，它就可以按預期工作。但是，如果人需要在應用程序發布之前測試并批準該應用程序，會發生什么？

要做出此決定，必須中斷部署過程。例如，我們首先將應用程序部署到測試環境，允許相關方驗證更改，并且當每個人都滿意時，將版本提升為生產。

這個單一決策點意味著我們曾經的機器驅動方程式：

面板與手動部署按鈕。

當CI / CD被呈現為僅在編譯代碼之后自動執行的部署步驟時，這種對人為干預的關注經常丟失。

例如：Jenkins文檔建議將測試和生產環境建模為CI管道中的階段。

乍一看，這個例子似乎為人工審核部署提供了一個過程，但是從未考慮將其推向生產的構建會發生什么？在應用程序向客戶公開之前，此類構建將被取消，從而導致構建失敗。這些失敗的構建很難與未能編譯或未通過測試的構建區分開來，即使在此實例中未提升到生產是CD過程的預期行為。

簡而言之，一個好的CD工具可以提高人工決策過程，這種過程對于部署來說是如此常見（如果不是必不可少的話），或者至少是環境之間部署的當前狀態，并使部署自動化。

認識到機器驅動的CI流程和人工驅動的CD流程之間的不同要求，對于以快速，可靠和可重復的方式向客戶交付功能至關重要，這就是為什么使用專用工具進行持續集成和持續部署，提高效率。

快樂的部署！