CI/CD 是軟件開發(fā)中最流行的實踐之一，但其實施的陷阱可能成為其收益的嚴(yán)重障礙。

如果您在技術(shù)行業(yè)工作，您可能已經(jīng)注意到軟件開發(fā)方法向流程自動化和 DevOps 實踐化的重大轉(zhuǎn)變。

根據(jù) 2020 年 DevOps 趨勢調(diào)查，99% 使用 DevOps 實踐并實施 CI/CD 的公司都有了重大改進。例如：更快的發(fā)布周期和更高的軟件質(zhì)量。然而，根據(jù)同一份報告，85% 的團隊在早期實施 DevOps 實踐方面存在問題。

大約四年前，我們 Techstack 開始將我們的團隊轉(zhuǎn)向 CI/CD 方法。我們已經(jīng)看到團隊合作和業(yè)務(wù)成果的持續(xù)改進，但一開始，我們和大多數(shù)團隊一樣，面臨著陷阱和障礙，這讓我們懷疑是否需要 CI/CD。

今天，我們已經(jīng)克服了這些困難，并在大多數(shù)項目中成功地使用了 CI/CD。根據(jù)我們的經(jīng)驗，讓我們探索這種方法的好處，以及最常見的錯誤和避免它們的方法。

為什么要轉(zhuǎn)向CI/CD？

CI/CD（持續(xù)集成和持續(xù)交付）方法基于短而快速的迭代，以最大限度地減少錯誤、加快開發(fā)過程并提高產(chǎn)品質(zhì)量。

下面的信息圖顯示了 CI/CD 管道的工作原理。

轉(zhuǎn)向 CI/CD，團隊會獲得以下好處：

1、由于排除了人為因素，并且驗證階段是自動化的，因此增加了釋放流程的可靠性。

2、發(fā)布小塊工作的能力使團隊能夠首先發(fā)布重要的東西。

3、減少頻繁發(fā)布對 QA 團隊的壓力。

4、降低涉及同一項目中多個團隊工作的發(fā)布的復(fù)雜性。自動化有助于避免多個團隊工作中的潛在沖突，并在出現(xiàn)沖突時提供工具。

5、改進所有發(fā)布停止的可見性，例如失敗或非工作構(gòu)建，因為自動系統(tǒng)會在正確的時間將問題通知正確的人。

但老實講：CI/CD 的優(yōu)點被談?wù)摰谋热秉c多。

讓我們弄清楚工程團隊在實施 CI/CD 時可能會面臨哪些問題。

使用CI/CD 的5 個錯誤以及如何避免它們

盡管具有優(yōu)勢，但 CI/CD 是一個相當(dāng)復(fù)雜的多步驟過程。這些步驟中的每一個都可能帶來困難和障礙。以下是遷移到 CI/CD 的團隊最常遇到的五個主要錯誤：

1、在不穩(wěn)定 CI 上構(gòu)建CD

要構(gòu)建 CD，您需要一個已存在于項目中的可靠 CI 流。這樣，您將確保：

• 每個釋放單元不破壞系統(tǒng)性能；
• 構(gòu)建應(yīng)用程序的過程非常自動化且可重復(fù)（即重新構(gòu)建相同的代碼將導(dǎo)致完全相同的結(jié)果）。

如果您不確定這些要點，請準(zhǔn)備好應(yīng)對持續(xù)不斷的 CD 流程中斷以及工程師需要查找和修復(fù)問題（例如新錯誤和崩潰構(gòu)建）的需要。

如何避免：確保 CI 流程的所有階段都得到實施，團隊對 CI 工作的結(jié)果有信心。例如，一旦編譯并通過測試的代碼，可以保證將來收集并通過測試。

2、自動化的好處值不值得其潛在的風(fēng)險

在自動化流程時，考慮自動化成本與將獲得的收益比至關(guān)重要。

讓我們看一個例子：

我們有一個項目，每兩周發(fā)布一次更新。為了使其自動化，QA 團隊需要花費兩個月的時間編寫自動測試（手動回歸，耗時不超過四個小時）。很明顯，自動化這樣的過程可能永遠(yuǎn)不會有回報。

相反，如果團隊的目標(biāo)是不斷致力于減少代碼交付時間，那么 CD 可以顯著節(jié)省 QA 團隊的時間，并保證應(yīng)用程序可靠性的增加。

如何避免：在開始 CI/CD 實施之前，清楚地比較這種自動化的收益和成本。

這里有一些問題可以幫助你做到這一點：

• 這個過程多久重復(fù)一次？
• 多久時間？
• 有多少人和資源參與其中？
• 缺乏自動化會導(dǎo)致流程出錯嗎？
• 為什么這個過程現(xiàn)在需要自動化？

根據(jù)答案，確定此過程需要自動化的緊迫程度，以及是否需要自動化。

如果項目當(dāng)前不需要完整的 CI/CD 流程，那么考慮迭代 CI/CD 實施的可能性很重要，但各個階段的自動化將有助于解決緊急問題。此外，您可以只自動化產(chǎn)品的一部分：例如，在后端實現(xiàn) CI/CD，而無需接觸移動應(yīng)用程序，移動應(yīng)用程序是此后端的消費者。

3、將持續(xù)部署理解為持續(xù)交付

持續(xù)部署是一種特定的實踐，代碼庫中的任何更改都應(yīng)該自動且快速地投入生產(chǎn)。

一方面，大多數(shù)工程團隊對此持謹(jǐn)慎態(tài)度，因為快速更改可能會使用戶感到困惑。另一方面，他們可以通過不立即將更改啟動到生產(chǎn)中，來確保不將 CD 成為方法論的一部分。事實上，他們只是將持續(xù)部署理解為持續(xù)交付。

持續(xù)部署是一種獨立的機制，是持續(xù)交付的附加組件，不會取代它。在實施 CI/CD 過程時，將持續(xù)部署視為每個特定項目中可能需要也可能不需要的單獨功能。

如何避免：如果您決定使用持續(xù)部署，請?zhí)崆盀榇藴?zhǔn)備您的項目，以避免破壞用戶體驗。當(dāng)應(yīng)用程序更新對用戶隱藏但對產(chǎn)品團隊仍然可見時，實施功能標(biāo)志方法。這樣，您可以在正確的時間為某些用戶組打開和關(guān)閉它。

4、 不可靠的測試系統(tǒng)

可靠的測試是 CI/CD 過程的基礎(chǔ)。它們保證代碼正常工作，并允許您進一步向下發(fā)布流程。如果不信任自動化測試，團隊要么通過手動測試重復(fù)工作（這貶低了編寫自動化測試的工作），要么在生產(chǎn)階段面臨大量錯誤（這將直接損害產(chǎn)品）。

如何避免：確保您使用的測試系統(tǒng)足夠可靠。檢查它們是否滿足兩個關(guān)鍵要求：

• 測試保證了所有功能的充分覆蓋：所有應(yīng)用程序模塊和所有主要流程都被測試覆蓋。
• 每個單獨測試的結(jié)果都是可信的：測試不會自己崩潰，如果測試通過，那么這部分功能就真的測試過了。

5、缺乏有意義的儀表盤和指標(biāo)

有時，敏捷團隊甚至還沒來得及了解哪些對他們來說真正有用的跟蹤哪些不是，就收到了一個指標(biāo)列表。結(jié)果，重要的指標(biāo)根本沒有被跟蹤，大量的時間花在記錄沒有任何好處的指標(biāo)上。

盡管敏捷和 CI/CD 的目標(biāo)不同，但它們應(yīng)該互相幫助。這兩種方法都基于持續(xù)改進實踐——對完成、修訂和進步的不斷分析。實現(xiàn)它的最簡單方法是使用指標(biāo)和儀表板很好地覆蓋所有流程。團隊必須能夠看到當(dāng)前狀態(tài)以了解下一步該去哪里。

此外，任何問題都應(yīng)盡早發(fā)現(xiàn)并解決。這同樣適用于敏捷和 CI/CD。例如，從事 SCRUM 的團隊需要了解他們的性能和消耗率，以及他們的交付時間，以查看發(fā)布流程中可能存在的瓶頸。

如果沒有這種理解，那么團隊將不知道系統(tǒng)的哪一部分是無效的，因此不會專注于改進。

如何避免：確保團隊擁有顯示 CI/CD 過程成功的指標(biāo)。設(shè)置流程，使團隊能夠看到任何問題并主動做出響應(yīng)。

CI/CD 的結(jié)果

CI/CD 是一種可靠的方法，可幫助團隊提高工作效率，同時提高產(chǎn)品質(zhì)量和發(fā)布速度。盡管如此，只有在正確構(gòu)建流程時，單擊鼠標(biāo)的部署路徑才會有效。不僅特殊工具可以在這方面有所幫助，而且每個團隊成員的文化改變也有幫助。

原文鏈接：https://dzone.com/articles/common-mistakes-in-ci-cd-implementation