CI/CD 最佳實踐的基本原則

阿新 • • 發佈：2020-10-22

點選上方“民工哥技術之路”，選擇“設為星標”

回覆“1024”獲取獨家整理的學習資料！

持續整合和持續部署（CI/CD）是許多組織使用的敏捷方法。它正在幫助這些組織有效、安全地發行軟體。

根據 GitLab 2020 DevSecOps 調查，幾乎 83％的開發人員表示，他們正在比以前更快、更頻繁地釋出程式碼。59％的公司表示他們幾乎每天都要釋出多次。而這是因為採用了 DevOps 方法，並且主要歸功於持續整合、自動化測試和持續部署。

每個組織都試圖在建立 CI/CD 流水線時引入自己的方法，最終找到完美的平衡，我們通常將其稱為“最佳實踐”。本文就來談一些有效且安全的 CI/CD 流水線的基本原則。

可靠性

在軟體開發生命週期中擁有 CI/CD 流水線工具是組織能夠快速構建和交付應用程式的一大福音，但與此同時，選擇正確的 CI/CD 工具也相當重要，其應當能夠隨業務組織發展而擴充套件，並且執行準確無誤。而且，它還應該足夠靈活，可以處理多種用例和多種軟體交付需求。

CI 流水線應當很快

使 CI/CD 流水線儘可能快是非常重要的。我們所有的自動化測試都執行在開發環境中的 CI 流水線上，而其最終會被部署到生產環境中。因此，涵蓋所有邊緣情況和潛在的致命失效非常重要，同時，我們需要確保所有這些更改不會在我們的程式碼中造成任何無法預料的錯誤。因此，同時保持 CI 流水線簡單、快速和安全非常重要。

隨著微服務架構的廣泛採用，CI 流水線變得簡單明瞭（不同於單體架構的情形）。但是如果流水線任務繁重，最好移除一些不會產生重大影響的測試，並且記錄下這種取捨。我們還應該確定測試的優先順序。執行較快的測試應首先執行。例如，單元測試比較快，而且是程式功能或模組的基礎，因此應當首先執行，然後再進行功能測試和整合測試。這樣，我們可以儘早發現錯誤並節省時間。開發者應該在推送程式碼之前在本地執行測試以儘早發現錯誤。

在獨立環境中構建和執行

從 CI/CD 流水線的安全性以及確保它類似於預釋出環境和生產環境的角度講，在獨立的環境中執行 CI/CD 流水線一直都很重要，這可以確保我們的測試結果更加準確。

我們可以使用 Docker 或其他任何容器化工具來執行我們的測試套件，也可以在 Docker 容器中為我們的應用程式安裝其他依賴。這樣，我們可以確保測試在完全隔離的環境中執行，並且不受底層主機的任何影響。由於我們的 CI/CD 平臺可以完全訪問我們的程式碼倉庫，因此大多陣列織也習慣於在自己的雲平臺基礎設施中部署 CI/CD 工具以確保安全。

許多組織邁出了更大一步，他們還在隔離環境中渲染和測試 UI 元件。在將它們作為獨立的構建塊交付並整合到一個或多個專案中之前，此過程是一種驗證它們確實獨立的方法（這通常使用 Bit（Github）完成）。

預釋出環境和生產環境等價

建議始終保持預釋出環境和生產環境等價，以避免執行測試時發生意外錯誤導致釋出暫停這種小概率事件。我們的 CI/CD 流水線首先經過執行測試和在預釋出環境中部署的階段。測試後，該應用會自動升級（或手動部署）到生產環境。

使開發和測試環境完全等價於生產環境非常困難，但我們可以在需要時做出決定保持他們儘可能相似，並且瞭解我們正在做出的取捨。大多陣列織還使用“藍綠部署”或“金絲雀釋出”的部署策略，在該策略中，我們首先在生產環境中部署應用並處理大約 1% 的流量。然後將流量提高到 100%，或者也可以較為輕鬆的回滾到之前的版本。

總結

所有 CI/CD 工具都不相同，每個組織都儘可能以最有效和便捷的方式利用 CI/CD。但以上是一些最佳實踐，每個人都應注意並遵循這些最佳實踐，以避免將來出現問題。每個組織都應授權並僅通過 CI/CD 流水線來發布軟體，以提高程式碼質量和組織的編碼規範。