在CI/CD和DevOps領域中，持續交付和持續部署是一個老生常談的話題，持續集成這個術語最早是在1994年由Grady Booch提出，微服務提出者Martin Flower在2014年發表的論文《Microservice》中也對軟體開發持續集成提供了可參考原則，持續集成是借助工具對軟體專案進行持續的自動化的編譯打包構建測驗發布，來檢查軟體交付質量的一種行為，而持續部署是基于持續交付的優勢自動將經過測驗的代碼推入生產環境的程序，下文從細節描述了持續集成和持續部署各階段的關鍵步驟，
本文將探討CI（持續集成）/CD（持續部署）流程中的各個階段；以及從快速、規模交付的視角探討為什么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）是構建軟體和完成初始測驗的程序，持續部署（CD）是將代碼與基礎設施相結合的程序，確保完成所有測驗并遵循策略，然后將代碼部署到預期環境中，當然，許多公司也有自己特有流程，但主要步驟如下，
CI：代碼提交階段
參與者：開發工程師，資料庫管理員（DBA），基礎架構團隊
技術：GitHub，GitLab，SVM，BitBucket
流程：代碼提交階段也稱為版本控制，提交是將開發人員撰寫的最新代碼變更發送到代碼存盤庫的操作，開發人員撰寫的代碼的每個版本都被無限期地存盤，在與合作者討論和審查變更之后，開發人員將撰寫代碼，并在軟體需求、特性增強、bug修復或變更請求完成后提交，管理編輯和提交變更的存盤庫稱為源代碼管理工具（配置管理工具），在開發人員提交代碼（代碼推送請求）后，代碼更改被合并到主線代碼分支中，這些主線代碼分支存盤在GitHub這樣的中央存盤庫中，
CI：靜態代碼檢查階段
參與者：開發工程師，資料庫管理員（DBA），基礎架構團隊
技術：GitHub，GitLab，SVM，BitBucket
流程：開發人員撰寫代碼并將其推送到存盤庫后，系統將自動觸發以啟動下一個代碼分析程序，開發程序中存在這種情況：提交的代碼可以構建成功，但在部署期間構建失敗，無論從機器還是人力資源的利用率而言，這都是一個緩慢而昂貴的程序，因此必須檢查代碼中的靜態策略，SAST（靜態應用程式安全性測驗）：SAST是一種白盒測驗方法，可以使用SonarQube，Veracode，Appscan等SAST工具從內部檢查代碼，以發現軟體缺陷，漏洞和弱點（例如SQL注入等），這是一個快速檢查程序，其中檢查代碼是否存在語法錯誤，盡管此階段缺少檢查運行時錯誤的功能，但該功能將在以后的階段中執行，
將額外的策略檢查加入自動化流水線中可以顯著減少流程中稍后發現的錯誤數量，
CI：構建
參與者：開發工程師
技術：Jenkins，Bamboo CI，Circle CI，Travis CI，Maven，Azure DevOps
流程：持續集成程序的目標是提交的代碼持續構建為二進制檔案或構建產物，通過持續集成來檢查添加的新模塊是否與現有模塊兼容，不僅有助于更快地發現bug，還有助于減少驗證新代碼更改的時間，構建工具可以根據幾乎所有編程語言的源代碼創建可執行檔案或包（.exe，.dll，.jar等），在構建程序中，還可以生成SQL腳本，配合基礎設施組態檔一起進行測驗，簡而言之，構建階段就是編譯應用程式的階段，Artifactory存盤、構建驗證測驗和單元測驗也可以作為構建程序的一部分，
構建驗證測驗（BVT）/冒煙測驗/單元測驗：
創建構建后立即執行冒煙測驗，BVT將檢查所有模塊是否正確集成，以及程式的關鍵功能是否正常運行，這樣做的目的是拒絕嚴重損壞的應用程式，以使QA團隊不會在安裝和測驗軟體應用程式步驟浪費時間，
在完成這些檢查后，將向流水線中執行UT（單元測驗），以進一步減少生產中的故障，單元測驗可驗證開發人員撰寫的單個單元或組件是否按預期執行，
構建產物存盤：
一旦構建就緒，程式包就會存盤在稱為Artifactory或Repository工具的中央資料庫，隨著每天構建量的增加，跟蹤所有構建產物也會變得愈加困難，因此，一旦生成并驗證了構建產物，就將其發送到存盤庫進行存盤管理，諸如Jfrog Artifactory之類的存盤庫工具可用于存盤諸如.rar，.war，.exe，Msi等之類的二進制檔案，測驗人員可以從此處手動進行選擇，并在測驗環境中部署構建產物以進行測驗，
CI：測驗階段
參與者：測驗人員、QA
技術：Selenium，Appium，Jmeter，SOAP UI，Tarantula
程序：發布構建程序后的一系列自動測驗將驗證代碼的準確性，此階段可幫助避免生產中的錯誤，根據構建的大小，此檢查可能持續數秒至數小時，對于由多個團隊提交和構建代碼的大型組織，這些檢查在并行環境中運行，以節省寶貴的時間并盡早將錯誤通知開發人員，
測驗人員（或稱為QA工程師）基于用戶描述的測驗用例和場景設定自動化測驗用例，他們執行回歸分析、壓力測驗來檢查與預期輸出的偏差，測驗中涉及的活動有完整性測驗、集成測驗、壓力測驗，這是一個高層次測驗方法，在這個階段，可以發現開發人員忽視的某些代碼問題，
集成測驗：
集成測驗是使用Cucumber、Selenium等工具執行的，在這些工具中，單個應用程式模塊被組合起來并作為一組進行測驗，同時評估其是否符合指定的功能需求，在集成測驗之后，需要有人批準該組中的更新集應該移到下一個階段，這通常是性能測驗，這個驗證程序可能很麻煩，但它是整個程序的一個重要部分，驗證這個程序業界有很多優秀的方案，
性能和壓力測驗：
Selenium、JMeter等自動化測驗工具也可執行性能和壓力測驗，以檢查應用程式在面對高負載時是否穩定和性能良好，該測驗流程通常不會在每個更新提交上運行，因為完整的壓力測驗是長期運行的，當發布主要的新功能時，將對多個更新進行分組，并完成完整的性能測驗，在單個更新被轉移到下一階段的情況下，流水線可能將金絲雀測驗加入作為可選，
持續部署：Bake和部署
參與者：基礎架構工程師，SRE，運維工程師
技術：Spinnaker，Argo CD，Tekton CD
程序：在測驗階段完成之后，可以部署到服務器的標準代碼準備就緒，在部署到生產中之前，它們將被部署到產品團隊內部使用的測驗環境或beta環境，在將構建移至這些環境之前，構建必須經過Bake和Deploy的子階段，這兩個階段都是Spinnaker所支持存在的，
CD：Bake
Baking是指在生產時使用當前配置從源代碼創建不可變的鏡像實體，這些配置可能是資料庫更改和其他基礎結構更新之類的事情，Spinnaker可以觸發Jenkins執行此任務，并且某些組織更喜歡使用Packer，
CD：部署
Spinnaker自動將已bake的鏡像發送到部署階段，這是將服務器組設定為部署到集群的位置，與上述測驗程序類似，在部署階段將執行功能相同的程序，首先將部署移至測驗階段，然后最終移至生產環境，以進行批準和檢查，這個處理程序可以由Spinnaker等工具支持，
CD：驗證
這也是團隊優化整個CI/CD流程的關鍵位置，因為現在已經進行了如此多的測驗，所以失敗很少見，但是，此時必須盡快解決所有故障，以最大程度地減少對最終客戶的影響，團隊也應該考慮使流程的這一部分自動化，
使用藍綠部署、金絲雀分析、滾動更新等策略部署到產品，在部署階段，將監視正在運行的應用程式以驗證當前部署是否正確或是否需要回滾，
CD：監控
參與者：站點可靠性工程師（SRE）、運營團隊
技術：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
程序：為了使軟體發行版具有故障安全性和健壯性，在生產環境中跟蹤發行版的運行狀況至關重要，應用程式監視工具將跟蹤性能指標，例如CPU利用率和發行版延遲，日志分析器將掃描由底層中間件和作業系統產生的大量日志，以識別行為并跟蹤問題的根源，如果生產中出現任何問題，將通知利益相關者以確保生產環境的安全性和可靠性，此外，監視階段可幫助組織收集有關其新軟體更改如何為收入貢獻的情報，幫助基礎設施團隊跟蹤系統行為趨勢并進行容量規劃，
持續交付（CD）：反饋和協作工具
參與者：站點可靠性工程師（SRE）、運營和維護團隊，
技術：JIRA、ServiceNow、Slack、電子郵件、Hipchat，
程序：DevOps團隊的目標是更快地持續發布，然后不斷減少錯誤和性能問題，這是通過不時地通過發送電子郵件向開發人員、專案經理提供有關新版本的質量和性能的反饋，通常情況下，反饋系統是整個軟體交付程序的一部分，因此，交付中的任何更改都會頻繁地錄入系統，以便交付團隊可以對它采取行動，
總結
企業必須評估一個整體的持續交付解決方案，該解決方案可以自動化或促進上述這些階段的自動化，
寫在最后
歡迎大家關注我的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在里面更新，整理的資料也會放在里面，
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288033.html
標籤：Java
上一篇：6、面向物件編程（中）