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

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

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

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

問(wèn)題是你的整個(gè)團隊都陷入了困境。所有拉渠道錯誤提交的開(kāi)發(fā)人員都會(huì )花 5 分鐘的時(shí)間來(lái)排查為什么程序無(wú)法運行。有些人可能會(huì )嘗試查找錯誤的提交。有些人會(huì )嘗試與有問(wèn)題的代碼作者并行解決問(wèn)題。

這對你的團隊來(lái)說(shuō)是浪費時(shí)間。最糟糕的是，重復發(fā)生的事件加劇了對主分支的不信任，并鼓勵開(kāi)發(fā)人員分開(kāi)工作。

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

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

檢查應確保最低限度：
該應用程序應能夠構建并啟動(dòng)
最關(guān)鍵的功能應始終處于工作狀態(tài)（用戶(hù)注冊/登錄過(guò)程以及關(guān)鍵的業(yè)務(wù)功能）
所有開(kāi)發(fā)人員都依賴(lài)的應用程序的通用層應該是穩定的。這意味著(zhù)需要對這些通用代碼進(jìn)行單元測試。

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

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

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

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

通常至少每天一次，將你正在處理的任務(wù)拆分為較小的任務(wù)，經(jīng)常合并你的代碼，并經(jīng)常拉取。這樣一來(lái)，沒(méi)有人能分開(kāi)工作超過(guò)一兩天，問(wèn)題就沒(méi)有時(shí)間滾雪球了。

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

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

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

現在想象一下反饋在 3 分鐘之內到來(lái)。而且你知道會(huì )的。你可能根本不會(huì )啟動(dòng)新任務(wù)。你將有時(shí)間再次閱讀你的代碼，或者在等待時(shí)檢查 PR，失敗的通知將會(huì )到來(lái)。你將修復它，然后繼續下一個(gè)任務(wù)。這就是你的流程應啟用的焦點(diǎn)。

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