【51CTO.com快譯】持續(xù)集成(CI)/持續(xù)交付(CD)管道是一系列步驟，其中包括從CI/CD流程開(kāi)始的所有階段，并負(fù)責(zé)創(chuàng)建自動(dòng)化和無(wú)縫的軟件交付。而使用CI/CD管道，軟件發(fā)布工件可以從代碼檢入階段到測(cè)試、構(gòu)建、部署和生產(chǎn)階段一直在管道中前進(jìn)。這一概念之所以強(qiáng)大，是因?yàn)橐坏┲付斯艿?，就可以將其部分或全部?shí)現(xiàn)自動(dòng)化，從而加快了流程，并減少了錯(cuò)誤。換句話說(shuō)，CI/CD管道使組織每天更輕松地自動(dòng)多次交付軟件。

DevOps工程師往往會(huì)因?yàn)镃I/CD中各個(gè)階段的自動(dòng)化而與CI/CD管道混淆。雖然不同的工具可以使CI/CD中的各個(gè)復(fù)雜階段實(shí)現(xiàn)自動(dòng)化，但由于人工干預(yù)，CI/CD的整個(gè)軟件供應(yīng)鏈仍然可能被中斷。以下將探討持續(xù)集成(CI)/持續(xù)交付(CD)流程的各個(gè)階段，以及為什么CI/CD管道對(duì)于組織以快速和大規(guī)模的方式交付代碼至關(guān)重要的原因。

CI/CD階段：了解人員、流程和技術(shù)

組織應(yīng)用程序開(kāi)發(fā)團(tuán)隊(duì)通常由開(kāi)發(fā)人員、測(cè)試人員/質(zhì)量保證(QA)工程師、運(yùn)營(yíng)工程師和站點(diǎn)可靠性工程師(SRE)或IT運(yùn)營(yíng)團(tuán)隊(duì)組成。他們緊密合作，將高質(zhì)量的軟件交付到客戶(hù)手中。持續(xù)集成(CI)/持續(xù)交付(CD)是兩個(gè)獨(dú)立過(guò)程的組合：持續(xù)集成和持續(xù)交付。以下列出了CI/CD管道中的主要步驟。

持續(xù)集成(CI)：代碼提交

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

• 人員：開(kāi)發(fā)人員和工程師、數(shù)據(jù)庫(kù)管理員(DBA)、基礎(chǔ)設(shè)施團(tuán)隊(duì)。
• 技術(shù)：GitHub、Gitlab、SVM、BitBucket。
• 過(guò)程：

代碼提交階段也稱(chēng)為版本控制。提交是將開(kāi)發(fā)人員編寫(xiě)的最新更改發(fā)送到存儲(chǔ)庫(kù)的操作。開(kāi)發(fā)人員編寫(xiě)的每一個(gè)版本的代碼都是無(wú)限期存儲(chǔ)的。在與合作者討論和審查更改之后，開(kāi)發(fā)人員將編寫(xiě)代碼，并在軟件需求、功能增強(qiáng)、錯(cuò)誤修復(fù)或更改請(qǐng)求完成后提交。管理編輯和提交更改的存儲(chǔ)庫(kù)稱(chēng)為源代碼管理(SCM工具)。開(kāi)發(fā)人員在提交代碼(代碼推送請(qǐng)求)后，代碼更改將合并到存儲(chǔ)在中心存儲(chǔ)庫(kù)(如GitHub)中的基本代碼分支中。

持續(xù)集成(CI)：靜態(tài)代碼分析

• 人員：開(kāi)發(fā)人員和工程師、數(shù)據(jù)庫(kù)管理員(DBA)、基礎(chǔ)設(shè)施團(tuán)隊(duì)、測(cè)試人員。
• 技術(shù)：GitHub、Gitlab、SVM、BitBucket。
• 過(guò)程：

開(kāi)發(fā)人員編寫(xiě)代碼并將其推送到存儲(chǔ)庫(kù)后，系統(tǒng)將自動(dòng)觸發(fā)以啟動(dòng)下一個(gè)代碼分析過(guò)程。想象一下這樣一個(gè)步驟：提交的代碼可以直接構(gòu)建，而在構(gòu)建或交付期間失敗。就機(jī)器和人力的資源利用率而言，這都是一個(gè)成本昂貴的緩慢過(guò)程。組織必須檢查代碼中的靜態(tài)策略，靜態(tài)應(yīng)用程序安全測(cè)試(SAST)是一種白盒測(cè)試方法，可以使用SonarQube、Veracode、Appscan等SAST工具從內(nèi)部檢查代碼，以發(fā)現(xiàn)軟件缺陷、漏洞和弱點(diǎn)(例如SQL注入等)。這是一個(gè)快速檢查過(guò)程，其中檢查代碼是否存在語(yǔ)法錯(cuò)誤。盡管此階段缺少檢查運(yùn)行時(shí)錯(cuò)誤的功能，但該功能將在以后的階段中執(zhí)行。

將其他策略檢查放入自動(dòng)管道中可以顯著地減少在該過(guò)程中發(fā)現(xiàn)的錯(cuò)誤數(shù)量。

持續(xù)集成(CI)：構(gòu)建

• 人員：開(kāi)發(fā)人員和工程師。
• 技術(shù)：Jenkins、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps。
• 過(guò)程：持續(xù)集成(CI)過(guò)程的目標(biāo)是進(jìn)行常規(guī)代碼提交并不斷構(gòu)建二進(jìn)制工件。持續(xù)集成過(guò)程通過(guò)檢查添加的新模塊是否與現(xiàn)有模塊配合良好，有助于更快地發(fā)現(xiàn)錯(cuò)誤。這有助于減少驗(yàn)證新代碼更改的時(shí)間。生成工具根據(jù)用于編寫(xiě)源代碼的編程語(yǔ)言來(lái)幫助編譯和創(chuàng)建可執(zhí)行文件或程序包(.exe、.dll、.jar等)。在交付期間，還將生成SQL腳本，然后與基礎(chǔ)設(shè)施配置文件一起對(duì)其進(jìn)行測(cè)試。總之，構(gòu)建階段就是編譯應(yīng)用程序的階段。作為構(gòu)建過(guò)程一部分的其他子活動(dòng)是工件存儲(chǔ)、構(gòu)建驗(yàn)證和單元測(cè)試。

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

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

在這些檢查之后，將單元測(cè)試(UT)添加到管道中，以進(jìn)一步減少生產(chǎn)中的故障。單元測(cè)試測(cè)試開(kāi)發(fā)人員編寫(xiě)的代碼的各個(gè)單元或組件，以驗(yàn)證它們是否按預(yù)期執(zhí)行。

工件存儲(chǔ)：

一旦準(zhǔn)備好構(gòu)建，數(shù)據(jù)包就存儲(chǔ)在一個(gè)稱(chēng)為工件或存儲(chǔ)庫(kù)工具的集中位置或數(shù)據(jù)庫(kù)中。每天可能會(huì)生成很多構(gòu)建，并且跟蹤所有構(gòu)建可能會(huì)很困難。因此，一旦生成并驗(yàn)證構(gòu)建，它就被發(fā)送到存儲(chǔ)庫(kù)進(jìn)行存儲(chǔ)。存儲(chǔ)庫(kù)工具(如Jfrog Artifactory)用于存儲(chǔ)二進(jìn)制文件，如.rar、.war、.exe、Msi等。在此，測(cè)試人員可以通過(guò)人工選擇，并在測(cè)試環(huán)境中部署工件以進(jìn)行測(cè)試。

持續(xù)集成(CI)：測(cè)試階段

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

這些自動(dòng)化測(cè)試由測(cè)試人員(或質(zhì)量保證工程師)設(shè)置，他們根據(jù)用戶(hù)案例設(shè)置了測(cè)試用例和場(chǎng)景。他們執(zhí)行回歸分析和壓力測(cè)試以檢查與預(yù)期輸出的偏差。測(cè)試涉及的活動(dòng)包括健全性測(cè)試、集成測(cè)試、壓力測(cè)試。這是一種非常高級(jí)的測(cè)試。在這里，可以發(fā)現(xiàn)開(kāi)發(fā)人員可能未知的問(wèn)題。

集成測(cè)試：

集成測(cè)試是使用諸如Cucumber、Selenium等工具執(zhí)行的，其中將單個(gè)應(yīng)用程序模塊組合并作為一組進(jìn)行測(cè)試，同時(shí)評(píng)估是否符合指定的功能需求。在集成測(cè)試之后，需要有人批準(zhǔn)該組中的更新集應(yīng)該移動(dòng)到下一階段，這通常是性能測(cè)試。這種核查過(guò)程可能很繁瑣，但它是整個(gè)過(guò)程的重要組成部分。在測(cè)試過(guò)程中出現(xiàn)了一些新的解決辦法。

負(fù)載平衡和壓力測(cè)試：

負(fù)載平衡和壓力測(cè)試也使用自動(dòng)化測(cè)試工具(如Selenium、JMeter等)執(zhí)行，以檢查應(yīng)用程序運(yùn)行是否穩(wěn)定，并且在高流量環(huán)境下是否良好。由于全面的壓力測(cè)試是長(zhǎng)期運(yùn)行的，因此通常不會(huì)在每次更新上運(yùn)行這一測(cè)試。當(dāng)要發(fā)布主要的新功能時(shí)，將對(duì)多個(gè)更新進(jìn)行分組，并完成完整性能測(cè)試。如果將單個(gè)更新移動(dòng)到下一階段，則管道可能包括金絲雀測(cè)試作為替代。

• 人員：基礎(chǔ)設(shè)施工程師、站點(diǎn)可靠性工程師(SRE)、運(yùn)營(yíng)工程師。
• 技術(shù)：Spinnaker、Argo CD、Tekton CD。
• 過(guò)程：在測(cè)試階段完成之后，標(biāo)準(zhǔn)的代碼準(zhǔn)備部署到服務(wù)器中，這些代碼將與主要應(yīng)用程序集成。在部署到生產(chǎn)中之前，他們將被部署到測(cè)試/暫存或產(chǎn)品團(tuán)隊(duì)內(nèi)部使用的測(cè)試環(huán)境中。在將構(gòu)建移動(dòng)到這些環(huán)境之前，構(gòu)建必須經(jīng)過(guò)兩個(gè)子庫(kù)，其名稱(chēng)為Bake和Deploy。這兩個(gè)階段都是Spinnaker所固有的。

持續(xù)交付(CD)：Bake

Bake是指從源代碼中創(chuàng)建一個(gè)不可變的映像實(shí)例，該實(shí)例在生產(chǎn)環(huán)境中具有當(dāng)前配置。這些配置可能是數(shù)據(jù)庫(kù)更改和其他基礎(chǔ)設(shè)施更新之類(lèi)的內(nèi)容。Spinnaker可以觸發(fā)Jenkins來(lái)執(zhí)行這個(gè)任務(wù)，而有些組織更喜歡使用Packer。

持續(xù)交付(CD)：Deploy

Spinnaker自動(dòng)將Bake的映像傳遞到Deploy階段。這是將服務(wù)器組設(shè)置為部署到集群的位置。與上述測(cè)試過(guò)程類(lèi)似，在Deploy階段執(zhí)行功能相同的過(guò)程，首先轉(zhuǎn)移到測(cè)試階段，然后轉(zhuǎn)移到產(chǎn)品環(huán)境，最后進(jìn)行批準(zhǔn)和檢查。其整個(gè)過(guò)程由Spinnaker之類(lèi)的工具處理。

持續(xù)交付(CD)：驗(yàn)證

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

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

持續(xù)交付(CD)：監(jiān)控

• 人員：站點(diǎn)可靠性工程師(SRE)、運(yùn)營(yíng)團(tuán)隊(duì)。
• 技術(shù)：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli。
• 過(guò)程：為了使軟件發(fā)行版具有故障安全性和健壯性，在生產(chǎn)環(huán)境中跟蹤發(fā)行版的運(yùn)行狀況至關(guān)重要。應(yīng)用程序監(jiān)視工具將跟蹤性能指標(biāo)，例如CPU利用率和發(fā)行版延遲。日志分析器將掃描由底層中間件和操作系統(tǒng)產(chǎn)生的大量日志，以識(shí)別行為并跟蹤問(wèn)題的根源。如果生產(chǎn)中出現(xiàn)任何問(wè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)營(yíng)和維護(hù)團(tuán)隊(duì)。
• 技術(shù)：JIRA、ServiceNow、Slack、電子郵件、Hipchat。
• 過(guò)程：DevOps團(tuán)隊(duì)的目標(biāo)是更快地持續(xù)發(fā)布，然后不斷減少錯(cuò)誤和性能問(wèn)題。這是通過(guò)不時(shí)地通過(guò)發(fā)送電子郵件向開(kāi)發(fā)人員、項(xiàng)目經(jīng)理提供有關(guān)新版本的質(zhì)量和性能的反饋。通常情況下，反饋系統(tǒng)是整個(gè)軟件交付過(guò)程的一部分。因此，交付中的任何更改都會(huì)頻繁地登錄到系統(tǒng)中，以便交付團(tuán)隊(duì)可以對(duì)它采取行動(dòng)。

結(jié)語(yǔ)

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

原文標(biāo)題：What Is a CI/CD Pipeline?，作者：Jyoti Sahoo

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】