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

持續集成和持續部署（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 流水線來發布軟件，以提升代碼質量和組織的編碼規範。