在CI/CD和DevOps領(lǐng)域中，持續(xù)交付和持續(xù)部署是一個(gè)老生常談的話題。持續(xù)集成這個(gè)術(shù)語最早是在1994年由Grady Booch提出。微服務(wù)提出者M(jìn)artin Flower在2014年發(fā)表的論文《Microservice》中也對(duì)軟件開發(fā)持續(xù)集成提供了可參考原則。

持續(xù)集成是借助工具對(duì)軟件項(xiàng)目進(jìn)行持續(xù)的自動(dòng)化的編譯打包構(gòu)建測(cè)試發(fā)布，來檢查軟件交付質(zhì)量的一種行為。而持續(xù)部署是基于持續(xù)交付的優(yōu)勢(shì)自動(dòng)將經(jīng)過測(cè)試的代碼推入生產(chǎn)環(huán)境的過程。下文從細(xì)節(jié)描述了持續(xù)集成和持續(xù)部署各階段的關(guān)鍵步驟，以下是原文。

本文將探討CI（持續(xù)集成）/CD（持續(xù)部署）流程中的各個(gè)階段；以及從快速、規(guī)模交付的視角探討為什么CI/CD流水線對(duì)于我們的組織是必不可少的。

CI/CD流水線工作流包括CI/CD流程開始時(shí)所有階段等一系列步驟，負(fù)責(zé)創(chuàng)建自動(dòng)、連貫的軟件交付模型。

通過CI/CD流水線，軟件研發(fā)可以實(shí)現(xiàn)從代碼簽入、測(cè)試、構(gòu)建和部署直至生產(chǎn)階段都在流水線中向前推進(jìn)。此概念之所以高大上，是因?yàn)橐坏?shí)施了流水線，就可以將其部分或全部自動(dòng)化，從而加快開發(fā)流程并減少錯(cuò)誤。換句話說，CI/CD流水線使企業(yè)可以更輕松地應(yīng)對(duì)軟件的自動(dòng)、快速、持續(xù)交付。

DevOps工程師經(jīng)常會(huì)將CI/CD各階段的和其CI/CD流水線混淆。盡管不同的工具可以將每個(gè)復(fù)雜階段自動(dòng)化完成分階段的CI/CD，但是整體CI/CD軟件鏈仍然可能由于不可避免的人工干預(yù)而中斷。因此我們首先需要了解CI/CD流程中的各個(gè)階段，以及從快速、規(guī)模交付的視角探討為什么CI/CD流水線對(duì)于我們的組織是必不可少的。

CI/CD 階段：理解參與者、流程、技術(shù)

企業(yè)應(yīng)用程序開發(fā)參與者通常由開發(fā)人員，測(cè)試人員/QA工程師，運(yùn)維工程師以及SRE（站點(diǎn)可靠性工程師）或IT運(yùn)營團(tuán)隊(duì)組成。他們緊密合作，目標(biāo)是高質(zhì)量軟件交付。CI/CD是兩個(gè)獨(dú)立過程的組合：持續(xù)集成和持續(xù)部署。下面列出了每個(gè)步驟中的主要步驟：

持續(xù)集成（CI）是構(gòu)建軟件和完成初始測(cè)試的過程。持續(xù)部署（CD）是將代碼與基礎(chǔ)設(shè)施相結(jié)合的過程，確保完成所有測(cè)試并遵循策略，然后將代碼部署到預(yù)期環(huán)境中。當(dāng)然，許多公司也有自己特有流程，但主要步驟如下。

CI：代碼提交階段

• 參與者：開發(fā)工程師，數(shù)據(jù)庫管理員（DBA），基礎(chǔ)架構(gòu)團(tuán)隊(duì)
• 技術(shù)：GitHub，GitLab，SVM，BitBucket
• 流程：代碼提交階段也稱為版本控制。提交是將開發(fā)人員編寫的最新代碼變更發(fā)送到代碼存儲(chǔ)庫的操作。開發(fā)人員編寫的代碼的每個(gè)版本都被無限期地存儲(chǔ)。在與合作者討論和審查變更之后，開發(fā)人員將編寫代碼，并在軟件需求、特性增強(qiáng)、bug修復(fù)或變更請(qǐng)求完成后提交。管理編輯和提交變更的存儲(chǔ)庫稱為源代碼管理工具（配置管理工具）。在開發(fā)人員提交代碼（代碼推送請(qǐng)求）后，代碼更改被合并到主線代碼分支中，這些主線代碼分支存儲(chǔ)在GitHub這樣的中央存儲(chǔ)庫中。

CI：靜態(tài)代碼檢查階段

• 參與者：開發(fā)工程師，數(shù)據(jù)庫管理員（DBA），基礎(chǔ)架構(gòu)團(tuán)隊(duì)
• 技術(shù)：GitHub，GitLab，SVM，BitBucket
• 流程：開發(fā)人員編寫代碼并將其推送到存儲(chǔ)庫后，系統(tǒng)將自動(dòng)觸發(fā)以啟動(dòng)下一個(gè)代碼分析過程。開發(fā)過程中存在這種情況：提交的代碼可以構(gòu)建成功，但在部署期間構(gòu)建失敗。無論從機(jī)器還是人力資源的利用率而言，這都是一個(gè)緩慢而昂貴的過程。因此必須檢查代碼中的靜態(tài)策略。SAST（靜態(tài)應(yīng)用程序安全性測(cè)試）：SAST是一種白盒測(cè)試方法，可以使用SonarQube，Veracode，Appscan等SAST工具從內(nèi)部檢查代碼，以發(fā)現(xiàn)軟件缺陷，漏洞和弱點(diǎn)（例如SQL注入等）。這是一個(gè)快速檢查過程，其中檢查代碼是否存在語法錯(cuò)誤。盡管此階段缺少檢查運(yùn)行時(shí)錯(cuò)誤的功能，但該功能將在以后的階段中執(zhí)行。

將額外的策略檢查加入自動(dòng)化流水線中可以顯著減少流程中稍后發(fā)現(xiàn)的錯(cuò)誤數(shù)量。

CI：構(gòu)建

• 參與者：開發(fā)工程師
• 技術(shù)：Jenkins，Bamboo CI，Circle CI，Travis CI，Maven，Azure DevOps
• 流程：持續(xù)集成過程的目標(biāo)是提交的代碼持續(xù)構(gòu)建為二進(jìn)制文件或構(gòu)建產(chǎn)物。通過持續(xù)集成來檢查添加的新模塊是否與現(xiàn)有模塊兼容，不僅有助于更快地發(fā)現(xiàn)bug，還有助于減少驗(yàn)證新代碼更改的時(shí)間。構(gòu)建工具可以根據(jù)幾乎所有編程語言的源代碼創(chuàng)建可執(zhí)行文件或包（.exe，.dll，.jar等）。在構(gòu)建過程中，還可以生成SQL腳本，配合基礎(chǔ)設(shè)施配置文件一起進(jìn)行測(cè)試。簡而言之，構(gòu)建階段就是編譯應(yīng)用程序的階段。Artifactory存儲(chǔ)、構(gòu)建驗(yàn)證測(cè)試和單元測(cè)試也可以作為構(gòu)建過程的一部分。

構(gòu)建驗(yàn)證測(cè)試（BVT）/冒煙測(cè)試/單元測(cè)試：

創(chuàng)建構(gòu)建后立即執(zhí)行冒煙測(cè)試。BVT將檢查所有模塊是否正確集成，以及程序的關(guān)鍵功能是否正常運(yùn)行。這樣做的目的是拒絕嚴(yán)重?fù)p壞的應(yīng)用程序，以使QA團(tuán)隊(duì)不會(huì)在安裝和測(cè)試軟件應(yīng)用程序步驟浪費(fèi)時(shí)間。

在完成這些檢查后，將向流水線中執(zhí)行UT（單元測(cè)試），以進(jìn)一步減少生產(chǎn)中的故障。單元測(cè)試可驗(yàn)證開發(fā)人員編寫的單個(gè)單元或組件是否按預(yù)期執(zhí)行。

構(gòu)建產(chǎn)物存儲(chǔ)：

一旦構(gòu)建就緒，程序包就會(huì)存儲(chǔ)在稱為Artifactory或Repository工具的中央數(shù)據(jù)庫。隨著每天構(gòu)建量的增加，跟蹤所有構(gòu)建產(chǎn)物也會(huì)變得愈加困難。因此，一旦生成并驗(yàn)證了構(gòu)建產(chǎn)物，就將其發(fā)送到存儲(chǔ)庫進(jìn)行存儲(chǔ)管理。諸如Jfrog Artifactory之類的存儲(chǔ)庫工具可用于存儲(chǔ)諸如.rar，.war，.exe，Msi等之類的二進(jìn)制文件。測(cè)試人員可以從此處手動(dòng)進(jìn)行選擇，并在測(cè)試環(huán)境中部署構(gòu)建產(chǎn)物以進(jìn)行測(cè)試。

CI：測(cè)試階段

• 參與者：測(cè)試人員、QA
• 技術(shù)：Selenium，Appium，Jmeter，SOAP UI，Tarantula
• 過程：發(fā)布構(gòu)建過程后的一系列自動(dòng)測(cè)試將驗(yàn)證代碼的準(zhǔn)確性。此階段可幫助避免生產(chǎn)中的錯(cuò)誤。根據(jù)構(gòu)建的大小，此檢查可能持續(xù)數(shù)秒至數(shù)小時(shí)。對(duì)于由多個(gè)團(tuán)隊(duì)提交和構(gòu)建代碼的大型組織，這些檢查在并行環(huán)境中運(yùn)行，以節(jié)省寶貴的時(shí)間并盡早將錯(cuò)誤通知開發(fā)人員。

測(cè)試人員（或稱為QA工程師）基于用戶描述的測(cè)試用例和場(chǎng)景設(shè)置自動(dòng)化測(cè)試用例。他們執(zhí)行回歸分析、壓力測(cè)試來檢查與預(yù)期輸出的偏差。測(cè)試中涉及的活動(dòng)有完整性測(cè)試、集成測(cè)試、壓力測(cè)試。這是一個(gè)高層次測(cè)試方法。在這個(gè)階段，可以發(fā)現(xiàn)開發(fā)人員忽視的某些代碼問題。

集成測(cè)試：

集成測(cè)試是使用Cucumber、Selenium等工具執(zhí)行的，在這些工具中，單個(gè)應(yīng)用程序模塊被組合起來并作為一組進(jìn)行測(cè)試，同時(shí)評(píng)估其是否符合指定的功能需求。在集成測(cè)試之后，需要有人批準(zhǔn)該組中的更新集應(yīng)該移到下一個(gè)階段，這通常是性能測(cè)試。這個(gè)驗(yàn)證過程可能很麻煩，但它是整個(gè)過程的一個(gè)重要部分。驗(yàn)證這個(gè)過程業(yè)界有很多優(yōu)秀的方案。

性能和壓力測(cè)試：

Selenium、JMeter等自動(dòng)化測(cè)試工具也可執(zhí)行性能和壓力測(cè)試，以檢查應(yīng)用程序在面對(duì)高負(fù)載時(shí)是否穩(wěn)定和性能良好。該測(cè)試流程通常不會(huì)在每個(gè)更新提交上運(yùn)行，因?yàn)橥暾膲毫y(cè)試是長期運(yùn)行的。當(dāng)發(fā)布主要的新功能時(shí)，將對(duì)多個(gè)更新進(jìn)行分組，并完成完整的性能測(cè)試。在單個(gè)更新被轉(zhuǎn)移到下一階段的情況下，流水線可能將金絲雀測(cè)試加入作為可選。

持續(xù)部署：Bake和部署

• 參與者：基礎(chǔ)架構(gòu)工程師，SRE，運(yùn)維工程師
• 技術(shù)：Spinnaker，Argo CD，Tekton CD
• 過程：在測(cè)試階段完成之后，可以部署到服務(wù)器的標(biāo)準(zhǔn)代碼準(zhǔn)備就緒。在部署到生產(chǎn)中之前，它們將被部署到產(chǎn)品團(tuán)隊(duì)內(nèi)部使用的測(cè)試環(huán)境或beta環(huán)境。在將構(gòu)建移至這些環(huán)境之前，構(gòu)建必須經(jīng)過Bake和Deploy的子階段。這兩個(gè)階段都是Spinnaker所支持存在的。

CD：Bake

Baking是指在生產(chǎn)時(shí)使用當(dāng)前配置從源代碼創(chuàng)建不可變的鏡像實(shí)例。這些配置可能是數(shù)據(jù)庫更改和其他基礎(chǔ)結(jié)構(gòu)更新之類的事情。Spinnaker可以觸發(fā)Jenkins執(zhí)行此任務(wù)，并且某些組織更喜歡使用Packer。

CD：部署

Spinnaker自動(dòng)將已bake的鏡像發(fā)送到部署階段。這是將服務(wù)器組設(shè)置為部署到集群的位置。與上述測(cè)試過程類似，在部署階段將執(zhí)行功能相同的過程。首先將部署移至測(cè)試階段，然后最終移至生產(chǎn)環(huán)境，以進(jìn)行批準(zhǔn)和檢查。這個(gè)處理過程可以由Spinnaker等工具支持。

CD：驗(yàn)證

這也是團(tuán)隊(duì)優(yōu)化整個(gè)CI/CD流程的關(guān)鍵位置。因?yàn)楝F(xiàn)在已經(jīng)進(jìn)行了如此多的測(cè)試，所以失敗很少見。但是，此時(shí)必須盡快解決所有故障，以最大程度地減少對(duì)最終客戶的影響。團(tuán)隊(duì)也應(yīng)該考慮使流程的這一部分自動(dòng)化。

使用藍(lán)綠部署、金絲雀分析、滾動(dòng)更新等策略部署到產(chǎn)品。在部署階段，將監(jiān)視正在運(yùn)行的應(yīng)用程序以驗(yàn)證當(dāng)前部署是否正確或是否需要回滾。

CD：監(jiān)控

• 參與者：站點(diǎn)可靠性工程師（SRE）、運(yùn)營團(tuán)隊(duì)
• 技術(shù)：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
• 過程：為了使軟件發(fā)行版具有故障安全性和健壯性，在生產(chǎn)環(huán)境中跟蹤發(fā)行版的運(yùn)行狀況至關(guān)重要。應(yīng)用程序監(jiān)視工具將跟蹤性能指標(biāo)，例如CPU利用率和發(fā)行版延遲。日志分析器將掃描由底層中間件和操作系統(tǒng)產(chǎn)生的大量日志，以識(shí)別行為并跟蹤問題的根源。如果生產(chǎn)中出現(xiàn)任何問題，將通知利益相關(guān)者以確保生產(chǎn)環(huán)境的安全性和可靠性。此外，監(jiān)視階段可幫助組織收集有關(guān)其新軟件更改如何為收入貢獻(xiàn)的情報(bào)，幫助基礎(chǔ)設(shè)施團(tuán)隊(duì)跟蹤系統(tǒng)行為趨勢(shì)并進(jìn)行容量規(guī)劃。

持續(xù)交付（CD）：反饋和協(xié)作工具

• 參與者：站點(diǎn)可靠性工程師（SRE）、運(yùn)營和維護(hù)團(tuán)隊(duì)。
• 技術(shù)：JIRA、ServiceNow、Slack、電子郵件、Hipchat。
• 過程：DevOps團(tuán)隊(duì)的目標(biāo)是更快地持續(xù)發(fā)布，然后不斷減少錯(cuò)誤和性能問題。這是通過不時(shí)地通過發(fā)送電子郵件向開發(fā)人員、項(xiàng)目經(jīng)理提供有關(guān)新版本的質(zhì)量和性能的反饋。通常情況下，反饋系統(tǒng)是整個(gè)軟件交付過程的一部分。因此，交付中的任何更改都會(huì)頻繁地錄入系統(tǒng)，以便交付團(tuán)隊(duì)可以對(duì)它采取行動(dòng)。

總結(jié)

企業(yè)必須評(píng)估一個(gè)整體的持續(xù)交付解決方案，該解決方案可以自動(dòng)化或促進(jìn)上述這些階段的自動(dòng)化。

文章轉(zhuǎn)載：DevOps技術(shù)棧
（版權(quán)歸原作者所有，侵刪）