歡迎關(guān)注微信公眾號【廈門微思網(wǎng)絡(luò)】。www.xmws.cn專業(yè)IT認證培訓(xùn)19周年
主要課程：思科、華為、紅帽、ORACLE、VMware、CISP、PMP等認證培訓(xùn)及考證?

在 CI /CD 和 DevOps領(lǐng)域中，持續(xù)交付和持續(xù)部署是一個老生常談的話題。持續(xù)集成這個術(shù)語最早是在1994年由Grady Booch提出。

微服務(wù)提出者Martin ?Flower 在2014年發(fā)表的論文《Microservice》中也對軟件開發(fā)持續(xù)集成提供了可參考原則。持續(xù)集成是借助工具對軟件項目進行持續(xù)的自動化的編譯打包構(gòu)建測試發(fā)布，來檢查軟件交付質(zhì)量的一種行為。

而持續(xù)部署是基于持續(xù)交付的優(yōu)勢自動將經(jīng)過測試的代碼推入生產(chǎn)環(huán)境的過程。下文從細節(jié)描述了持續(xù)集成和持續(xù)部署各階段的關(guān)鍵步驟。

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

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

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

DerOps工程師經(jīng)常會將 CI / CD 各階段的和其 CI / CD 流水線混淆。盡管不同的工具可以將每個復(fù)雜階段自動化完成分階段的 CI / CD ，但是整體 CI / CD 軟件鏈仍然可能由于不可避免的人工干預(yù)而中斷。

因此我們首先需要了解 CI / CD 流程中的各個階段，以及從快速、規(guī)模交付的視角探討為什么 CI / CD 流水線對于我們的組織是必不可少的。
?

?

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

企業(yè)應(yīng)用程序開發(fā)參與者通常由開發(fā)人員，測試人員/ QA 工程師，運維工程師以及SRE（站點可靠性工程師）或IT 運營團隊組成。

他們緊密合作，目標是高質(zhì)量軟件交付。? CI / CD 是兩個獨立過程的組合：持續(xù)集成和持續(xù)部署。下面列出每個步驟中的主要步驟：
?

持續(xù)集成

持續(xù)集成是構(gòu)建軟件和完成初始測試的過程。持續(xù)部署是將代碼與基礎(chǔ)設(shè)施相結(jié)合的過程，確保完成所有測試并遵循策略，然后將代碼部署到預(yù)期環(huán)境中。

當(dāng)然，許多公司也有自己特有的流程，但主要步驟如下：

CI：代碼提交階段

參與者：開發(fā)工程師，數(shù)據(jù)庫管理員（DBA），基礎(chǔ)架構(gòu)團隊

技術(shù)：GitHub，GitLab，SVM，BitBucket

流程：代碼提交階段也稱為版本控制。提交是將開發(fā)人員編寫的最新代碼變更發(fā)送到代碼存儲庫的操作。開發(fā)人員編寫的代碼的每個版本都被無限期地存儲。在與合作者討論和審查變更之后，開發(fā)人員將編寫代碼，并在軟件需求、特性增強、bug修復(fù)或變更請求完成后提交。管理編輯和提交變更的存儲庫稱為源代碼管理工具（配置管理工具）。在開發(fā)人員提交代碼（代碼推送請求）后，代碼更改被合并到主線代碼分支中，這些主線代碼分支存儲在GitHub這樣的中央存儲庫中。

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

參與者：開發(fā)工程師，數(shù)據(jù)庫管理員（DBA），基礎(chǔ)架構(gòu)團隊

技術(shù)：GitHub，GitLab，SVM，BitBucket

流程：開發(fā)人員編寫代碼并將其推送到存儲庫后，系統(tǒng)將自動觸發(fā)以啟動下一個代碼分析過程。開發(fā)過程中存在這種情況：提交的代碼可以構(gòu)建成功，但在部署期間構(gòu)建失敗。無論從機器還是人力資源的利用率而言，這都是一個緩慢而昂貴的過程。因此必須檢查代碼中的靜態(tài)策略。

SAST（靜態(tài)應(yīng)用程序安全性測試）：SAST是一種白盒測試方法，可以使用SonarQube，Veracode，Appscan等SAST工具從內(nèi)部檢查代碼，以發(fā)現(xiàn)軟件缺陷，漏洞和弱點（例如SQL注入等）。

這是一個快速檢查過程，其中檢查代碼是否存在語法錯誤。盡管此階段缺少檢查運行時錯誤的功能，但該功能將在以后的階段中執(zhí)行。

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

CI：構(gòu)建

參與者：開發(fā)工程師

技術(shù)：Jenkins，Bamboo CI，Circle CI，Travis CI，Maven，Azure DevOps

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

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

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

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

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

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

CI：測試階段

參與者：測試人員、QA

技術(shù)：Selenium，Appium，Jmeter，SOAP UI，Tarantula

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

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

? ?集成測試：
?

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

性能和壓力測試：

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

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

參與者：基礎(chǔ)架構(gòu)工程師，SRE，運維工程師

技術(shù)：Spinnaker，Argo CD，Tekton CD

過程：在測試階段完成之后，可以部署到服務(wù)器的標準代碼準備就緒。在部署到生產(chǎn)中之前，它們將被部署到產(chǎn)品團隊內(nèi)部使用的測試環(huán)境或beta環(huán)境。在將構(gòu)建移至這些環(huán)境之前，構(gòu)建必須經(jīng)過Bake和Deploy的子階段。這兩個階段都是Spinnaker所支持存在的。

CD：Bake

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

CD：部署

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

CD：驗證

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

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

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é)

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

往期回顧：

運維基礎(chǔ)（1）Nginx

運維基礎(chǔ)（2）實用工具篇

運維基礎(chǔ)（3）備份篇

運維基礎(chǔ)（4）流量監(jiān)控工具篇

運維基礎(chǔ)（5）Ansible

歡迎關(guān)注微信公眾號【廈門微思網(wǎng)絡(luò)】。www.xmws.cn專業(yè)IT認證培訓(xùn)19周年
主要課程：思科、華為、紅帽、ORACLE、VMware、CISP、PMP等認證培訓(xùn)及考證?

總結(jié)

以上是生活随笔為你收集整理的运维基础（6）CI / CD的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。