一篇文章了解CI/CD管道全流程
原創
最后编辑：李晓琳 于 2022-08-18 09:03:03
1572次查看
本篇目錄
從CI/CD過程開始，包含所有階段並負責創建自動化和無縫的軟件交付的一系列步驟稱爲CI/CD管道工作流。使用CI/CD管道，軟件發布工件可以從代碼提交階段到測試、構建、部署和生産階段在管道中移動和前進。這個概念非常強大，因爲一旦指定了一個管道，它的一部分或全部就可以實現自動化，從而加快流程並減少錯誤。換句話說，CI/CD管道使企業更容易一天自動多次交付軟件。
DevOps工程師經常會因爲CI/CD中各個階段的自動化而與CI/CD管道混淆。雖然不同的工具可以使CI/CD中的各個複雜階段實現自動化，但由于人工幹預，CI/CD的整個軟件供應鏈仍然可能被打破。那麽，就首先了解CI/CD過程中的各個階段，以及CI/CD管道爲什麽對于組織快速、大規模地交付代碼至關重要。
人員：開發人員和工程師、數據庫管理員（DBA）、基礎架構團隊
技術：GitHub、Gitlab、BitBucket
過程：代碼提交階段也稱爲版本控制。提交是將開發人員編寫的最新更改發送到存儲庫的操作。開發人員編寫的代碼的每個版本都被無限期地存儲。在與合作者討論和審查變更之後，開發人員將編寫代碼，並在軟件需求、功能增強、bug修複或變更請求完成後提交。管理編輯和提交變更的存儲庫被稱爲源代碼管理（SCM工具）。在開發人員提交代碼（代碼推送請求）後，代碼更改被合並到存儲在中央存儲庫（如GitHub）中的基本代碼分支中。
技術：GitHub、Gitlab、BitBucket
过程：一旦开发人员编写了代码并将其推送到存储库，系统就会自动触发，开始下一个代码分析过程。想象一下这样一个步骤：提交的代码直接进行构建，但在构建或部署过程中失败了。就资源利用率而言，无论是机器还是人力，这都是一个缓慢而昂贵的过程。必须检查代码的静态策略。SAST（Static Application Security Test）：SAST是一种白盒测试方法，使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码，以发现软件缺陷、漏洞和弱点（如SQL注入等）。这是一个快速检查过程，检查代码是否有语法错误。虽然此阶段缺少检查运行时错误的功能，但这将在稍后的阶段执行。
將附加的策略檢查放到自動化管道中可以顯著減少稍後在該過程中發現的錯誤數。
人員：開發人員和工程師
技术：Jenkins,、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps
过程：持续集成流程的目标是接受常规的代码提交，并持续构建二进制工件。持续集成过程通过检查添加的新模块是否与现有模块配合良好，有助于更快地发现bug。这有助于减少验证新代码更改的时间。构建工具有助于编译和创建可执行文件或包（.exe、。dll， .jar等）取决于用于编写源代码的编程语言。在构建过程中，还会生成SQL脚本，然后与基础设施配置文件一起测试。简而言之，构建阶段是编译应用程序的阶段。构建过程的其他子活动包括工件存储、构建验证和单元测试。
人員：測試人員和QA工程師
技术：Selenium、Appium、 Jmeter、SOAP UI、Tarantula
过程：发布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于防止错误到达産品。根据构建的大小，此检查可以持续数秒到数小时。对于由多个团队提交和构建代码的大型组织，这些检查将在并行环境中运行，以节省宝贵的时间并尽早将Bug通知给开发人员。
這些自動化測試是由測試人員（或者稱爲QA工程師）建立的，他們已經根據用戶故事建立了測試用例和場景。他們進行回歸分析，壓力測試，以檢查與預期産出的偏差。測試中涉及的活動有健全性測試、集成測試和壓力測試。這是一個非常先進的測試水平。在這裏會發現開發代碼的開發人員可能不知道的問題。
集成測試：
集成測試是使用Cucumber、Selenium等工具來執行的，其中各個應用程序模塊作爲一個組進行組合和測試，同時評估是否符合指定的功能需求。在集成測試之後，需要有人批准將該組中的更新集移動到下一階段，這通常是性能測試。這個驗證過程可能很麻煩，但它是整個過程的重要組成部分。核查過程中出現了一些新的解決辦法。
負載和壓力測試：
負載平衡和壓力測試也使用自動化測試工具（如Selenium、JMeter等）來執行，以檢查應用程序在高流量環境下是否穩定和性能良好。此測試通常不會在每個更新上運行，因爲完整的壓力測試是長期運行的。在發布主要的新功能時，將對多個更新進行分組，並完成完整的性能測試。在單個更新被轉移到下一個階段的情況下，管道可能包括金絲雀測試作爲替代方案。
人員：基礎設施工程師、現場可靠性工程師（SRE）、運維工程師
技术：Spinnaker、Argo CD、Tekton CD
过程：测试阶段完成后，清除了标准的代码就可以部署到服务器中，在那里它们将与主应用程序集成。在部署到生产环境之前，它们将被部署到産品团队内部使用的测试/暂存或beta环境中。在将构建移动到这些环境之前，构建必须经过两个子阶段Bake和Deploy。这两个阶段都是Spinnaker固有的。
部署到生産環境是使用部署策略（如藍綠部署、金絲雀分析、滾動更新等）執行的。在部署階段，將監視正在運行的應用程序，以驗證當前部署是否正確或是否需要回滾。
技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
過程：要使一個軟件發行版具有故障安全性和健壯性，在生産環境中跟蹤發行版的運行狀況是至關重要的。應用程序監控工具將跟蹤CPU利用率和發布延遲等性能指標。日志分析器將掃描底層中間件和操作系統産生的日志流，以識別行爲並跟蹤問題的來源。在生産過程中出現任何問題時，都會通知相關人員，以確保生産環境的安全性和可靠性。此外，監視階段幫助企業收集有關新軟件更改如何爲收入做出貢獻的信息，並幫助基礎架構團隊跟蹤系統行爲趨勢和進行容量規劃。
人員：SRE、Ops和維護團隊
技術：禅道、ServiceNow、Slack、Email、Hipchat
DevOps團隊的目標是更迅速、持續地發布，然後不斷減少錯誤和性能問題。這是通過slack或電子郵件頻繁地向開發人員和項目經理反饋新版本的質量和性能，並在ITSM工具中及時提高票價來實現的。通常，反饋系統是整個軟件交付過程的一部分；因此交付過程中的任何更改都會頻繁地記錄到系統中，以便交付團隊可以對其采取行動。
企業必須評估一個整體的持續交付解決方案，它可以自動化或促進上述階段的自動化。
DevOps工程師經常會因爲CI/CD中各個階段的自動化而與CI/CD管道混淆。雖然不同的工具可以使CI/CD中的各個複雜階段實現自動化，但由于人工幹預，CI/CD的整個軟件供應鏈仍然可能被打破。那麽，就首先了解CI/CD過程中的各個階段，以及CI/CD管道爲什麽對于組織快速、大規模地交付代碼至關重要。
CI/CD階段：了解人員、過程和技術
企業應用程序開發團隊通常由開發人員、測試人員/QA工程師、運營工程師和SRE（站點可靠性工程師）或IT運營團隊組成。他們緊密合作，將高質量的軟件交付給客戶。CI/CD是兩個獨立過程的組合:持續集成和持續部署。下面列出了其中的主要步驟。
CI持續集成
持續集成(CI)是構建軟件並完成初始測試的過程。持續部署(CD)是將代碼與基礎設施結合起來的過程，確保完成所有測試並遵循策略，然後將代碼部署到預期的環境中。當然，許多公司都有自己的流程，但主要步驟如下。CI：代碼提交
技術：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：測試階段
技术：Selenium、Appium、 Jmeter、SOAP UI、Tarantula
过程：发布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于防止错误到达産品。根据构建的大小，此检查可以持续数秒到数小时。对于由多个团队提交和构建代码的大型组织，这些检查将在并行环境中运行，以节省宝贵的时间并尽早将Bug通知给开发人员。
這些自動化測試是由測試人員（或者稱爲QA工程師）建立的，他們已經根據用戶故事建立了測試用例和場景。他們進行回歸分析，壓力測試，以檢查與預期産出的偏差。測試中涉及的活動有健全性測試、集成測試和壓力測試。這是一個非常先進的測試水平。在這裏會發現開發代碼的開發人員可能不知道的問題。
集成測試：
集成測試是使用Cucumber、Selenium等工具來執行的，其中各個應用程序模塊作爲一個組進行組合和測試，同時評估是否符合指定的功能需求。在集成測試之後，需要有人批准將該組中的更新集移動到下一階段，這通常是性能測試。這個驗證過程可能很麻煩，但它是整個過程的重要組成部分。核查過程中出現了一些新的解決辦法。
負載和壓力測試：
負載平衡和壓力測試也使用自動化測試工具（如Selenium、JMeter等）來執行，以檢查應用程序在高流量環境下是否穩定和性能良好。此測試通常不會在每個更新上運行，因爲完整的壓力測試是長期運行的。在發布主要的新功能時，將對多個更新進行分組，並完成完整的性能測試。在單個更新被轉移到下一個階段的情況下，管道可能包括金絲雀測試作爲替代方案。
持續部署：bake和部署
技术：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利用率和發布延遲等性能指標。日志分析器將掃描底層中間件和操作系統産生的日志流，以識別行爲並跟蹤問題的來源。在生産過程中出現任何問題時，都會通知相關人員，以確保生産環境的安全性和可靠性。此外，監視階段幫助企業收集有關新軟件更改如何爲收入做出貢獻的信息，並幫助基礎架構團隊跟蹤系統行爲趨勢和進行容量規劃。
持續部署：反饋和協作工具
技術：禅道、ServiceNow、Slack、Email、Hipchat
DevOps團隊的目標是更迅速、持續地發布，然後不斷減少錯誤和性能問題。這是通過slack或電子郵件頻繁地向開發人員和項目經理反饋新版本的質量和性能，並在ITSM工具中及時提高票價來實現的。通常，反饋系統是整個軟件交付過程的一部分；因此交付過程中的任何更改都會頻繁地記錄到系統中，以便交付團隊可以對其采取行動。
企業必須評估一個整體的持續交付解決方案，它可以自動化或促進上述階段的自動化。
DevOps幹貨
