一篇文章瞭解CI/CD管道全流程

從CI/CD過程開始，包含所有階段並負責建立自動化和無縫的軟體交付的一系列步驟稱為CI/CD管道工作流。使用CI/CD管道，軟體釋出工件可以從程式碼提交階段到測試、構建、部署和生產階段在管道中移動和前進。這個概念非常強大，因為一旦指定了一個管道，它的一部分或全部就可以實現自動化，從而加快流程並減少錯誤。換句話說，CI/CD管道使企業更容易一天自動多次交付軟體。

DevOps工程師經常會因為CI/CD中各個階段的自動化而與CI/CD管道混淆。雖然不同的工具可以使CI/CD中的各個複雜階段實現自動化，但由於人工干預，CI/CD的整個軟體供應鏈仍然可能被打破。那麼，就首先了解CI/CD過程中的各個階段，以及CI/CD管道為什麼對於組織快速、大規模地交付程式碼至關重要。

CI/CD階段：瞭解人員、過程和技術

企業應用程式開發團隊通常由開發人員、測試人員/QA工程師、運營工程師和SRE（站點可靠性工程師）或IT運營團隊組成。他們緊密合作，將高質量的軟體交付給客戶。CI/CD是兩個獨立過程的組合:持續整合和持續部署。下面列出了其中的主要步驟。

CI持續整合

持續整合(CI)是構建軟體並完成初始測試的過程。持續部署(CD)是將程式碼與基礎設施結合起來的過程，確保完成所有測試並遵循策略，然後將程式碼部署到預期的環境中。當然，許多公司都有自己的流程，但主要步驟如下。

CI：程式碼提交

人員：開發人員和工程師、資料庫管理員（DBA）、基礎架構團隊 技術：GitHub、Gitlab、BitBucket 過程：程式碼提交階段也稱為版本控制。提交是將開發人員編寫的最新更改傳送到儲存庫的操作。開發人員編寫的程式碼的每個版本都被無限期地儲存。在與合作者討論和審查變更之後，開發人員將編寫程式碼，並在軟體需求、功能增強、bug修復或變更請求完成後提交。管理編輯和提交變更的儲存庫被稱為原始碼管理（SCM工具）。在開發人員提交程式碼（程式碼推送請求）後，程式碼更改被合併到儲存在中央儲存庫（如GitHub）中的基本程式碼分支中。

CI：靜態程式碼分析

人員：開發人員和工程師、資料庫管理員（DBA）、基礎設施團隊、測試人員 技術：GitHub、Gitlab、BitBucket 過程：一旦開發人員編寫了程式碼並將其推送到儲存庫，系統就會自動觸發，開始下一個程式碼分析過程。想象一下這樣一個步驟：提交的程式碼直接進行構建，但在構建或部署過程中失敗了。就資源利用率而言，無論是機器還是人力，這都是一個緩慢而昂貴的過程。必須檢查程式碼的靜態策略。SAST（Static Application Security Test）：SAST是一種白盒測試方法，使用SonarQube、Veracode、Appscan等SAST工具從內部檢查程式碼，以發現軟體缺陷、漏洞和弱點（如SQL隱碼攻擊等）。這是一個快速檢查過程，檢查程式碼是否有語法錯誤。雖然此階段缺少檢查執行時錯誤的功能，但這將在稍後的階段執行。

將附加的策略檢查放到自動化管道中可以顯著減少稍後在該過程中發現的錯誤數。

CI：build

人員：開發人員和工程師 技術：Jenkins,、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps 過程：持續整合流程的目標是接受常規的程式碼提交，並持續構建二進位制工件。持續整合過程通過檢查新增的新模組是否與現有模組配合良好，有助於更快地發現bug。這有助於減少驗證新程式碼更改的時間。構建工具有助於編譯和建立可執行檔案或包（.exe、。dll， .jar等）取決於用於編寫原始碼的程式語言。在構建過程中，還會生成SQL指令碼，然後與基礎設施配置檔案一起測試。簡而言之，構建階段是編譯應用程式的階段。構建過程的其他子活動包括工件儲存、構建驗證和單元測試。

CI：測試階段

人員：測試人員和QA工程師 技術：Selenium、Appium、 Jmeter、SOAP UI、Tarantula 過程：釋出一個構建過程一系列自動化測試來驗證程式碼的準確性。這一階段有助於防止錯誤到達產品。根據構建的大小，此檢查可以持續數秒到數小時。對於由多個團隊提交和構建程式碼的大型組織，這些檢查將在並行環境中執行，以節省寶貴的時間並儘早將Bug通知給開發人員。

這些自動化測試是由測試人員（或者稱為QA工程師）建立的，他們已經根據使用者故事建立了測試用例和場景。他們進行迴歸分析，壓力測試，以檢查與預期產出的偏差。測試中涉及的活動有健全性測試、整合測試和壓力測試。這是一個非常先進的測試水平。在這裡會發現開發程式碼的開發人員可能不知道的問題。

整合測試：

整合測試是使用Cucumber、Selenium等工具來執行的，其中各個應用程式模組作為一個組進行組合和測試，同時評估是否符合指定的功能需求。在整合測試之後，需要有人批准將該組中的更新集移動到下一階段，這通常是效能測試。這個驗證過程可能很麻煩，但它是整個過程的重要組成部分。核查過程中出現了一些新的解決辦法。

負載和壓力測試：

負載平衡和壓力測試也使用自動化測試工具（如Selenium、JMeter等）來執行，以檢查應用程式在高流量環境下是否穩定和效能良好。此測試通常不會在每個更新上執行，因為完整的壓力測試是長期執行的。在釋出主要的新功能時，將對多個更新進行分組，並完成完整的效能測試。在單個更新被轉移到下一個階段的情況下，管道可能包括金絲雀測試作為替代方案。

持續部署：bake和部署

人員：基礎設施工程師、現場可靠性工程師（SRE）、運維工程師 技術：Spinnaker、Argo CD、Tekton CD 過程：測試階段完成後，清除了標準的程式碼就可以部署到伺服器中，在那裡它們將與主應用程式整合。在部署到生產環境之前，它們將被部署到產品團隊內部使用的測試/暫存或beta環境中。在將構建移動到這些環境之前，構建必須經過兩個子階段Bake和Deploy。這兩個階段都是Spinnaker固有的。

CD：Bake

Bake是指從原始碼中建立一個不可變的映像例項，該例項在生產環境中具有當前配置。這些配置可能是資料庫更改和其他基礎設施更新之類的內容。Spinnaker可以觸發Jenkins來執行這個任務，有些組織更喜歡使用Packer。

CD：部署

Spinnaker將自動將烘焙的映像傳遞到部署階段。這是將伺服器組設定為部署到叢集的位置。與上述測試過程類似，在部署階段執行功能相同的過程。部署首先轉移到測試、階段，最後轉移到生產環境，然後進行批准和檢查。整個過程由Spinnaker之類的工具處理。

CD：驗證

這也是團隊優化整個CI/CD流程的關鍵所在。因為現在已經進行了很多測試，所以失敗應該很少。但此時的任何故障都需要儘快解決，以便將對最終客戶的影響降到最低。團隊也應該考慮自動化這部分流程。

部署到生產環境是使用部署策略（如藍綠部署、金絲雀分析、滾動更新等）執行的。在部署階段，將監視正在執行的應用程式，以驗證當前部署是否正確或是否需要回滾。

CD：監控

人員：SRE，運維團隊 技術：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli 過程：要使一個軟體發行版具有故障安全性和健壯性，在生產環境中跟蹤發行版的執行狀況是至關重要的。應用程式監控工具將跟蹤CPU利用率和釋出延遲等效能指標。日誌分析器將掃描底層中介軟體和作業系統產生的日誌流，以識別行為並跟蹤問題的來源。在生產過程中出現任何問題時，都會通知相關人員，以確保生產環境的安全性和可靠性。此外，監視階段幫助企業收集有關新軟體更改如何為收入做出貢獻的資訊，並幫助基礎架構團隊跟蹤系統行為趨勢和進行容量規劃。

持續部署：反饋和協作工具

人員：SRE、Ops和維護團隊 技術：禪道、ServiceNow、Slack、Email、Hipchat DevOps團隊的目標是更迅速、持續地釋出，然後不斷減少錯誤和效能問題。這是通過slack或電子郵件頻繁地向開發人員和專案經理反饋新版本的質量和效能，並在ITSM工具中及時提高票價來實現的。通常，反饋系統是整個軟體交付過程的一部分；因此交付過程中的任何更改都會頻繁地記錄到系統中，以便交付團隊可以對其採取行動。

企業必須評估一個整體的持續交付解決方案，它可以自動化或促進上述階段的自動化。