持續集成、持續交付和持續部署 的真正區別

有很多介紹什么是持續集成、持續交付和持續部署的內容。但是這些流程首先要做什么？

了解 CI 和 CD 解決的問題以正確使用它們至關重要。這將使你的團隊可以改善流程。并避免花力氣追求那些不會給你的過程帶來任何價值的幻想指標。
持續集成是一個團隊問題
如果你和同一團隊的多個開發者在一個存儲庫中工作，其中載有最新版本的代碼位于存儲庫的主分支。開發人員在不同分支上從事不同的工作。 一旦某人完成變更后，他會將其推送或合并到主分支。最終，整個團隊將拉取到這一變更。

我們要避免的情況是錯誤的提交進入主分支。錯誤意味著代碼無法編譯，或者應用無法啟動或無法使用。為什么？并不是因為應用程序損壞了或者因為所有測試必須始終為綠色。那不是問題，你可能永遠不會部署該版本并等待修復。

問題是你的整個團隊都陷入了困境。所有拉渠道錯誤提交的開發人員都會花 5 分鐘的時間來排查為什么程序無法運行。有些人可能會嘗試查找錯誤的提交。有些人會嘗試與有問題的代碼作者并行解決問題。

這對你的團隊來說是浪費時間。最糟糕的是，重復發生的事件加劇了對主分支的不信任，并鼓勵開發人員分開工作。

持續集成就是為了防止主分支被破壞，從而使你的團隊不會陷入困境。也就是說，這并不是要讓所有測試始終保持綠色并且主分支在每次提交時都可以部署到生產中。

持續集成的過程獨立于任何工具。你可以手動驗證分支和主分支的合并在本地是否有效，然后將合并推送到存儲庫，但是這種方式是非常低效的。這就是使用自動檢查實施持續集成的原因。

檢查應確保最低限度：
該應用程序應能夠構建并啟動
最關鍵的功能應始終處于工作狀態（用戶注冊/登錄過程以及關鍵的業務功能）
所有開發人員都依賴的應用程序的通用層應該是穩定的。這意味著需要對這些通用代碼進行單元測試。

實際上，這意味著你需要拉取適用于你的任何單元測試框架并保護應用程序的公共層。有時，代碼不是很多，可以很快完成。另外，你還需要添加“冒煙測試”以驗證代碼是否已編譯以及應用程序是否啟動。這對于帶有瘋狂依賴注入的技術（例如 Java Spring 或 .NET Core）尤其重要。在大型項目中，很容易錯誤修改依賴項，因此必須確認該應用程序至少總是始終啟動。

如果你有成百上千的測試，則無需為每個合并運行所有測試。這將花費大量時間，并且大多數測試可能會驗證“非團隊阻止者”功能。

我們將在接下來的部分中看到持續交付的流程將如何充分利用這許多測試。
與工具無關
工具和自動檢查都可以。但是，如果你的開發人員僅合并他們工作了幾個星期的巨型分支機構，那么他們將無濟于事。團隊將花費大量時間合并分支并修復最終將出現的代碼不兼容問題。與錯誤的提交阻塞在一起一樣浪費時間。

持續集成與工具無關。這是關于小塊工作并將新代碼集成到主分支并頻繁提取的問題。

通常至少每天一次，將你正在處理的任務拆分為較小的任務，經常合并你的代碼，并經常拉取。這樣一來，沒有人能分開工作超過一兩天，問題就沒有時間滾雪球了。

一項大型任務不必全部都在一個分支中，應該永遠不會。將進行中的工作合并到主分支的技術稱為“抽象分支”和“功能切換”。有關更多詳細信息，請參見博客文章《如何開始進行持續集成》。
良好的 CI 關鍵點
這非常簡單，保持簡短，最多 3-7 分鐘。這與CPU和資源無關，這與開發人員的生產力有關。生產力的首要規則是專注。做一件事，完成它，然后移到下一件事。

上下文切換成本很高。研究表明，當你被打擾時，大約需要 23 分鐘才能重新專注于某件事。想象一下，你推動分支進行合并，然后開始另一個任務，你花了15到20分鐘才能解決。在進入區域后的一分鐘，你會從前一個任務的20分鐘的 CI 構建中收到“構建失敗”通知。你再次推送它，你來回切換很容易超過20分鐘。

每天一次或兩次將 20 分鐘乘以你的團隊中的開發人員的數量……這浪費了很多寶貴的時間。

現在想象一下反饋在 3 分鐘之內到來。而且你知道會的。你可能根本不會啟動新任務。你將有時間再次閱讀你的代碼，或者在等待時檢查 PR，失敗的通知將會到來。你將修復它，然后繼續下一個任務。這就是你的流程應啟用的焦點。

原文轉自：https://fire.ci/blog/the-difference-between-ci-and-cd/