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

如果您在技術行業工作，您可能已經注意到軟件開發方法向流程自動化和 DevOps 實踐化的重大轉變。

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

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

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

為什么要轉向CI/CD？

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

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

轉向 CI/CD，團隊會獲得以下好處：

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

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

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

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

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

但老實講：CI/CD 的優點被談論的比缺點多。

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

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

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

1、在不穩定 CI 上構建CD

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

• 每個釋放單元不破壞系統性能；
• 構建應用程序的過程非常自動化且可重復（即重新構建相同的代碼將導致完全相同的結果）。

如果您不確定這些要點，請準備好應對持續不斷的 CD 流程中斷以及工程師需要查找和修復問題（例如新錯誤和崩潰構建）的需要。

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

2、自動化的好處值不值得其潛在的風險

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

讓我們看一個例子：

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

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

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

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

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

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

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

3、將持續部署理解為持續交付

持續部署是一種特定的實踐，代碼庫中的任何更改都應該自動且快速地投入生產。

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

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

如何避免：如果您決定使用持續部署，請提前為此準備您的項目，以避免破壞用戶體驗。當應用程序更新對用戶隱藏但對產品團隊仍然可見時，實施功能標志方法。這樣，您可以在正確的時間為某些用戶組打開和關閉它。

4、 不可靠的測試系統

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

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

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

5、缺乏有意義的儀表盤和指標

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

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

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

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

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

CI/CD 的結果

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

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