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

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

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

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

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

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

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

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

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

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

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

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

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

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

構(gòu)建驗證測試(BVT)/煙霧測試和單元測試：

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

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

工件存儲：

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

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

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

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

集成測試：

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

負載平衡和壓力測試：

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)語

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

原文標題：What Is a CI/CD Pipeline?，作者：Jyoti Sahoo

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