如今應用程式的開發通常由多個開發人員組成的團隊完成。每個人或團隊在專案中發揮自己的作用，然後我們發現在專案的末尾總是有幾段程式碼需要編譯，根據每個人的工作方法，管理這種整合可能會浪費很多時間。持續整合和持續交付/部署（CI/CD）便用來解決該問題，確保釋出更新順利進行，避免不必要的延遲和衝突。
因此為應用程式開發和實施 CI/CD 工作流程越來越普遍，與此同時，實施 CI/CD 時也面臨許多挑戰。在今天的文章中我們將一同探討這些挑戰具體是什麼，以及我們應當如何對 CI/CD 進行擴充套件和優化。
速度是任何 CI/CD 過程的重要因素之一。如果您的 CI 伺服器和部署需要半小時才能完成該過程，並且您有多個團隊，每個團隊計劃每天部署幾次，那麼您的 CI/CD 流水線確實會被阻塞。開發人員必須在佇列中等待 CI/CD 可用。一些企業限制了可以在給定時間執行的流水線，但這樣依舊無法有效提供現代企業所需的快速釋出。
當今 CI/CD 流水線使用的基礎設施複雜且難以設定。大多數新應用程式都使用微服務，這會頻繁觸發新的 CI/CD 流水線啟動。但是當您擴充套件現有的 CI/CD 基礎架構時，必須處理與雲基礎架構相關的許多複雜問題。如果流水線和基礎設施管理不是自動化的，這將浪費許多時間在為新流水線設定基礎設施和設定上。
在基於微服務的應用程式部署中，CI 伺服器是平穩釋出工作流程的關鍵點。如前所述，微服務快速觸發 CI 伺服器，CI 伺服器由於請求過多而阻塞是很常見的。您可以垂直擴充套件 CI 伺服器，這將暫時解決問題，但最終您將需要建立多個具有獨立職責的 CI 伺服器。即使是一個整體但不斷增長的應用程式也會在衝刺結束時阻塞你的 CI 伺服器，因為在最後一分鐘有太多的程式碼更改，並且平均每 30 分鐘就會有不同的開發人員進行部署。
當微服務數量增加時，對 CI/CD 進行擴充套件是不可避免的。微服務數量的增加導致不同的流水線連線到單個 git 儲存庫，這增加了 CI 伺服器的負載並降低了效能。要擴充套件 CI/CD，為所有團隊建立一個標準化和自動化的開發流水線，確保開發人員交付和團隊交付的質量，同時還讓流水線的管理變得容易。
可以通過定義用於執行單元測試和驗證交付程式碼質量的CI 流程來實現擴充套件，隨後是用於構建映象並將它們持續部署到環境中的 CD 過程，最後定義用於構建映象並將它們部署到生產環境中的過程。接下來我們將按步驟來講解如何對 CI/CD 進行擴充套件。
流水線遵循 Git 分支到環境的對映（開發 ➡️ 開發和主控 ➡️ 批准和生產）。然後在每次拉取請求時觸發 CI 作業，在對映分支中的每次更改時觸發 CD 作業。可以按照以下步驟來建立 CI 和 CD 工作流。
CI 工作流程分為 7 個步驟：
檢視 Pull Request 源和目標分支；
檢查合併是否沒有需要手動解決的問題；
執行單元測試；
構建包以驗證完整性和程式碼可編譯性；
觸發程式碼質量驗證；
增加並提交專案版本到源分支；
通過 Webhook 或 Rest API 呼叫（Git 儲存庫）通知 Pull Request Git 儲存庫成功或失敗。
CD 作業流程遵循以下路徑：
通知的分支被簽出。
工使用正在處理的專案的特定構建工具構建工件。
工件構建好後，將庫專案傳送到 Nexus 工件儲存，流程結束。
然後執行以下操作：
第 1 步：為生成的工件建立 Docker 映象，將工件版本應用到 Docker 映象。
第 2 步：映象上傳到 Docker registry。
第 3 步：通過 Kubernetes 通過映象部署進行部署。
對於審批/生產環境中的應用程式專案，請按照上面的步驟 1 和 2，然後執行以下操作：
在審批環境中通過 Kubernetes 通過 image rollout 進行部署；
作業暫停等待 rollout 被批准用於生產；
如果通過，則將正在通過的映象進行生產；
如果不通過，它則會回滾批准的映象。
CI/CD 改善了應用開發週期，解決了整合新程式碼和增加交付頻率帶來的問題。接下來我們會一起探討如何進一步優化 CI/CD 的使用。
當構建出現故障時，修復故障應該是團隊的首要任務。如果構建不能在幾分鐘內修復，團隊必須決定是刪除程式碼還是禁用功能標誌。修復損壞的構建背後的主要思想是構建始終生成可以釋出的工作程式碼。
通常只要部署發生，應用程式的穩定性就會受到威脅。因此我們傾向於將部署分開，但這種方法的問題是部署中積累的變化太多，如果其中一項更改出錯，將會迫使我們回滾其他正在執行的更改。因此請將複雜的變化分解成小而簡單的變化，如果更頻繁地部署並小批次工作，則部署的風險更低。
您的本地環境與投入生產的環境之間可能存在許多不同之處，可以通過自動化 QA 任務（例如瀏覽器測試）來優化 CI/CD，從而降低錯誤影響實時應用程式的風險。
為了驗證開發人員何時整合新程式碼，CI 依賴於自動化且可靠的測試套件。如果需要編譯程式碼，第一個測試是編譯，然後您可以新增您認為關鍵的任意數量的測試。
那麼應該包括多少個測試？請記住 CI 的目標是儘快提供反饋。如果開發人員必須等待一個小時才能獲得反饋是行不通的。錯誤難以避免，當你發現生產中的錯誤時，可以建立一個測試用例並將其包含在 CI 迴圈中。
始終考慮 CI/CD 工具在整合到現有設定或環境中時的安全性。CI/CD 要求以程式設計方式呼叫所有安全測試工具，並將它們的結果聚合在一個地方。請尋找具有用於自動加密審計的 API 的工具。
當您通過自動化測試、自動交付和自動回滾來擴充套件 CI/CD 流程時，您可以減少流程中涉及的手動工作。手動操作會浪費很多時間並且容易出錯。自動化大部分 CI/CD 流程將節省時間，這些時間可用於修復生產錯誤等有價值的活動。
當您的 CI/CD 通過自動化擴充套件時，通過更頻繁地釋出較小的更改，您可以在開發過程中更早地發現錯誤。當您在開發的所有階段實施自動化測試時，可以更頻繁地釋出修復程式，而不必擔心 CI/CD 所花費的時間。自動化整合測試是構建執行狀況的關鍵點，您可以安全地將程式碼移至下一階段。如果需要，自動化管道可以更輕鬆地回滾更改。
當您的 CI/CD 流程被擴充套件時，您的開發人員可以專注於業務需求並監控產品的行為。他們可以在不依賴運營團隊的情況下自行自助服務任何產品部署。自助服務功能還使他們能夠嘗試創新的產品解決方案。這種自主和自力更生的感覺造就了一款非常精緻的產品。
CI/CD 使您的整合和交付更快。但是，重要的是根據企業的需求和市場變化對其進行擴充套件和優化，以避免該過程因複雜性增加而拖延產品交付的速度。