本文介紹了CI/CD的概念以及各個(gè)階段可能用到的工具，供參考。

〇、前言

CI/CD 是現(xiàn)代軟件開發(fā)的核心實(shí)踐，通過自動(dòng)化和協(xié)作，顯著提升交付效率和質(zhì)量。

本文將對(duì) CI 和 CD 這兩個(gè)概念進(jìn)行簡(jiǎn)要介紹，供參考。

一、CI/CD 的核心概念

CI/CD 是 DevOps 實(shí)踐的核心組成部分，旨在通過自動(dòng)化流程加速軟件交付，提高質(zhì)量和可靠性。

它的核心概念有三個(gè)：持續(xù)集成、持續(xù)交付和持續(xù)部署。下面將詳細(xì)介紹。

另外，什么是 DevOps？

它是一種結(jié)合了 開發(fā)（Development） 和 運(yùn)維（Operations） 的文化和實(shí)踐，旨在通過協(xié)作和自動(dòng)化工具，加速軟件交付流程，同時(shí)提高質(zhì)量、靈活性和可靠性。DevOps 的核心目標(biāo)是打破開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)之間的壁壘，促進(jìn)跨職能協(xié)作，從而實(shí)現(xiàn)更高效的軟件生命周期管理。

1.1 持續(xù)集成（CI：Continuous Integration）

CI 就是在開發(fā)團(tuán)隊(duì)頻繁（通常每天多次）將代碼變更合并到共享主分支或開發(fā)分支時(shí)，通過自動(dòng)化構(gòu)建和測(cè)試，來驗(yàn)證代碼的正確性。

CI 的目標(biāo)是：

• 減少集成沖突：通過頻繁合并代碼，盡早發(fā)現(xiàn)和解決集成問題。
• 自動(dòng)化驗(yàn)證：每次代碼提交后自動(dòng)執(zhí)行編譯、單元測(cè)試和集成測(cè)試，確保代碼質(zhì)量。

流程示意圖如下：

關(guān)鍵節(jié)點(diǎn)如下詳細(xì)介紹：

1.1.1 代碼提交階段

開發(fā)人員將本地代碼推送到版本控制系統(tǒng)（如 Git）的遠(yuǎn)程倉庫。

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

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

代碼提交階段也可以叫做【版本控制】。簡(jiǎn)單來說，就是在一個(gè)版本的開發(fā)階段完成后，將有變更的代碼提交代碼庫中。

每個(gè)版本所修改的內(nèi)容都會(huì)被無限期地存儲(chǔ)，以供后續(xù)查找。管理編輯和提交變更的存儲(chǔ)庫稱為源代碼管理工具（配置管理工具）。

在開發(fā)人員提交代碼（代碼推送請(qǐng)求）后，代碼更改被合并到主線代碼分支中，這些主線代碼分支存儲(chǔ)在 GitHub 這樣的中央存儲(chǔ)庫中。

 

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

開發(fā)人員將新版本代碼提交到倉庫后，就會(huì)觸發(fā)下一階段：靜態(tài)代碼檢查。

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

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

開發(fā)過程中存在這種情況：提交的代碼可以構(gòu)建成功，但在部署期間構(gòu)建失敗。無論從機(jī)器還是人力資源的利用率而言，這都是一個(gè)緩慢而昂貴的過程，因此必須檢查代碼中的靜態(tài)策略。

SAST（Static Application Security Testing 靜態(tài)應(yīng)用程序安全性測(cè)試）：SAST 是一種白盒測(cè)試方法，可以使用 SonarQube，Veracode，Appscan 等 SAST 工具從內(nèi)部檢查代碼，以發(fā)現(xiàn)軟件缺陷，漏洞和弱點(diǎn)（例如 SQL 注入等）。這是一個(gè)快速檢查過程，其中檢查代碼是否存在語法錯(cuò)誤。

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

 

1.1.3 構(gòu)建

構(gòu)建階段就是編譯應(yīng)用程序的階段。

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

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

持續(xù)集成（CI）過程的目標(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è)試。

另外，Artifactory 存儲(chǔ)、構(gòu)建驗(yàn)證測(cè)試和單元測(cè)試也可以作為構(gòu)建過程的一部分。

Artifactory 存儲(chǔ)：它是由 JFrog 公司開發(fā)的一款二進(jìn)制存儲(chǔ)庫管理軟件，它提供了全面的解決方案來管理二進(jìn)制文件（如 jar、war、zip、tar.gz 等），這些文件通常是在軟件開發(fā)過程中生成的構(gòu)建輸出。Artifactory 支持廣泛的技術(shù)棧和生態(tài)系統(tǒng)，包括但不限于 Maven、Gradle、Docker、npm、NuGet 等，為開發(fā)者提供了一個(gè)集中的平臺(tái)來存儲(chǔ)、管理和分發(fā)他們的制品。

構(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è)試。

 

1.1.4 測(cè)試

構(gòu)建過程中進(jìn)行的一系列自動(dòng)測(cè)試驗(yàn)證的是代碼的準(zhǔn)確性，而此階段主要驗(yàn)證業(yè)務(wù)邏輯的準(zhǔn)確性，可幫助避免生產(chǎn)中的錯(cuò)誤。

參與者：測(cè)試人員、QA。

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

根據(jù)構(gòu)建結(jié)果的大小，此檢查可能持續(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è)試類型有完整性測(cè)試、集成測(cè)試、壓力測(cè)試等等。這些都是更高層次測(cè)試方法，在這個(gè)階段，可以發(fā)現(xiàn)開發(fā)人員忽視的某些代碼問題。

完整性測(cè)試（Integrity Testing）：是一種確保數(shù)據(jù)、系統(tǒng)或軟件在其整個(gè)生命周期中保持一致性和準(zhǔn)確性的測(cè)試方法。它關(guān)注的是驗(yàn)證數(shù)據(jù)是否完整無缺，沒有丟失或損壞，并且系統(tǒng)能夠正確地處理和維護(hù)這些數(shù)據(jù)。完整性測(cè)試對(duì)于保證系統(tǒng)的可靠性、安全性和功能性至關(guān)重要。

集成測(cè)試（Integration Testing）：也稱為組裝測(cè)試或聯(lián)合測(cè)試，是軟件測(cè)試的一個(gè)階段，在單元測(cè)試之后進(jìn)行。它的主要目的是驗(yàn)證各個(gè)模塊之間的接口是否正常工作，確保不同部分能夠正確地協(xié)同運(yùn)作。集成測(cè)試關(guān)注的是模塊間的交互，而不是單個(gè)模塊的功能，后者通常由單元測(cè)試負(fù)責(zé)。集成測(cè)試是使用 Cucumber、Selenium 等工具執(zhí)行的。

性能測(cè)試（Performance Testing）：旨在驗(yàn)證系統(tǒng)的響應(yīng)速度、吞吐量、資源利用率等關(guān)鍵性能指標(biāo)是否符合預(yù)期要求。它通常是在受控環(huán)境下模擬用戶活動(dòng)來測(cè)量應(yīng)用程序的表現(xiàn)，以確定其能否滿足性能目標(biāo)。

壓力測(cè)試（Stress Testing）：是一種特殊的性能測(cè)試形式，目的是了解系統(tǒng)在極端條件下（如超出正常操作范圍的高負(fù)載）的行為。通過故意使系統(tǒng)過載，可以揭示系統(tǒng)在極限情況下的穩(wěn)定性及恢復(fù)能力。

最后經(jīng)過開發(fā)人員將全部 Bug 修改完成，QA 進(jìn)行全部回歸后，整個(gè) CI 階段就算完成了。

 

1.2 持續(xù)部署（CD：Continuous Deployment）（Bake and Deploy）

持續(xù)部署就是，經(jīng)過一系列測(cè)試后的程序，自動(dòng)被部署到生產(chǎn)環(huán)境，無需任何人工干預(yù)。

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

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

在部署到生產(chǎn)環(huán)境之前，新版本的程序被部署到產(chǎn)品團(tuán)隊(duì)內(nèi)部使用的測(cè)試環(huán)境。但在這之前，構(gòu)建必須經(jīng)過 Bake 和 Deploy 的子階段，這兩個(gè)階段都是 Spinnaker 所支持的。 

關(guān)于 Spinnaker，它是一個(gè)多云持續(xù)交付平臺(tái)，它可以幫助開發(fā)者和運(yùn)維團(tuán)隊(duì)快速、可靠地部署應(yīng)用程序到云端。由 Netflix 開源，旨在解決現(xiàn)代云計(jì)算環(huán)境中的復(fù)雜部署挑戰(zhàn)。Spinnaker 支持多種云服務(wù)提供商，如 AWS、Google Cloud Platform、Microsoft Azure、Kubernetes 等，這使得它成為一個(gè)非常靈活的選擇，適用于希望避免被特定云供應(yīng)商鎖定的組織。

 

1.2.1 Bake：準(zhǔn)備【一致且可預(yù)配置】的操作環(huán)境

Bake 指的是創(chuàng)建或生成一個(gè)虛擬機(jī)鏡像（如Amazon Machine Image (AMI) 或 Google Compute Engine image）的過程。這個(gè)步驟是為后續(xù)的部署活動(dòng)準(zhǔn)備一致且預(yù)配置的操作環(huán)境。

主要目的：

1. 一致性：確保所有部署的實(shí)例基于相同的初始狀態(tài)啟動(dòng)，減少由于環(huán)境差異導(dǎo)致的問題。
2. 效率：通過預(yù)先安裝和配置必要的軟件和服務(wù)，減少了新實(shí)例啟動(dòng)時(shí)間，并加速了應(yīng)用的部署過程。
3. 安全性：可以在bake階段集成安全補(bǔ)丁和策略，增強(qiáng)基礎(chǔ)架構(gòu)的安全性。

在 Spinnaker 中，Bake 過程主要由 Rosco 服務(wù)處理。用戶可以通過定義一個(gè)“Bake Stage”來指定希望生成的鏡像類型（例如，AMI for AWS, GCE image for Google Cloud），并可以指定所需的軟件包或其他自定義腳本以包含在最終鏡像中。這使得開發(fā)者能夠自動(dòng)化地創(chuàng)建標(biāo)準(zhǔn)化、可復(fù)用的基礎(chǔ)架構(gòu)組件，簡(jiǎn)化了部署流程，并有助于實(shí)現(xiàn)更加可靠的持續(xù)交付實(shí)踐。

 

1.2.2 Deploy：部署到目標(biāo)環(huán)境并驗(yàn)證

Deploy 階段是將構(gòu)建好的軟件版本，部署到目標(biāo)環(huán)境中的一系列操作。這個(gè)過程是確保應(yīng)用程序能夠順利地從開發(fā)環(huán)境轉(zhuǎn)移到測(cè)試、預(yù)生產(chǎn)甚至生產(chǎn)環(huán)境的關(guān)鍵步驟。通過自動(dòng)化部署流程，團(tuán)隊(duì)可以快速且可靠地發(fā)布新功能或修復(fù)問題。

優(yōu)勢(shì)：

1. 自動(dòng)化部署：通過使用CI/CD工具自動(dòng)執(zhí)行部署流程，減少人工干預(yù)，降低錯(cuò)誤率。
2. 快速反饋：使新代碼能迅速部署至各個(gè)環(huán)境（如測(cè)試、預(yù)生產(chǎn)），以便及時(shí)獲取反饋并進(jìn)行必要的調(diào)整。
3. 一致性：確保應(yīng)用在不同環(huán)境之間保持一致的配置和行為，避免由于環(huán)境差異引起的問題。
4. 回滾機(jī)制：當(dāng)部署出現(xiàn)問題時(shí)，能夠快速回退到之前的穩(wěn)定版本，減少對(duì)用戶的影響。

有三種部署策略：

• 藍(lán)綠部署：維護(hù)兩套相同的生產(chǎn)環(huán)境，一套為當(dāng)前生產(chǎn)環(huán)境（藍(lán)色），另一套為待切換的新環(huán)境（綠色）。新版本發(fā)布時(shí)先部署到綠色環(huán)境，并進(jìn)行最終驗(yàn)證，確認(rèn)無誤后將流量切換到綠色環(huán)境。
• 金絲雀發(fā)布：逐步將新版本發(fā)布給少量用戶，觀察其表現(xiàn)是否符合預(yù)期，然后再?zèng)Q定是否完全替換舊版本。
• 滾動(dòng)更新：逐步更新服務(wù)實(shí)例，每次僅更新部分實(shí)例，直到所有實(shí)例都完成更新。這種方式可以在不中斷服務(wù)的情況下進(jìn)行更新。

Deploy 階段是確保軟件產(chǎn)品能夠以高質(zhì)量、高效率的方式交付給用戶的重要一步。

 

1.2.3 監(jiān)控

參與者：站點(diǎn)可靠性工程師（SRE）、運(yùn)營(yíng)團(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ā)行版延遲。發(fā)行版延遲指的是從軟件開發(fā)完成到實(shí)際對(duì)外發(fā)布的這段時(shí)間間隔。這包括了從代碼凍結(jié)、構(gòu)建、測(cè)試、審批到最后部署上線的整個(gè)過程。發(fā)行版延遲可能由多種因素造成，例如：功能復(fù)雜性增加、需求變更管理不善、自動(dòng)化發(fā)布不足、溝通不暢問題等等，都可能導(dǎo)致延誤。減少發(fā)行版延遲的關(guān)鍵在于優(yōu)化軟件開發(fā)生命周期中的各個(gè)環(huán)節(jié)，比如加強(qiáng)自動(dòng)化測(cè)試、改進(jìn)項(xiàng)目管理和溝通機(jī)制等。通過實(shí)施敏捷開發(fā)方法論和CI/CD實(shí)踐，可以幫助組織更快地將產(chǎn)品推向市場(chǎng)，并減少發(fā)行版延遲。

日志分析器將掃描由底層中間件和操作系統(tǒng)產(chǎn)生的大量日志，以識(shí)別行為并跟蹤問題的根源。如果生產(chǎn)中出現(xiàn)任何問題，將通知利益相關(guān)者以確保生產(chǎn)環(huán)境的安全性和可靠性。

 

1.3 持續(xù)交付（CD：Continuous Delivery）（反饋和協(xié)作工具：Feedback and Collaboration）

持續(xù)交付旨在確保軟件可以隨時(shí)可靠地發(fā)布到生產(chǎn)環(huán)境中。它建立在持續(xù)集成（Continuous Integration, CI）的基礎(chǔ)上，但更進(jìn)一步，不僅要求代碼變更能夠自動(dòng)集成和測(cè)試，還要求這些變更能夠方便、快速地部署到一個(gè)或多個(gè)環(huán)境，直至生產(chǎn)環(huán)境。

參與者：站點(diǎn)可靠性工程師（SRE）、運(yùn)營(yíng)和維護(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)。

參考：https://geekdaxue.co/read/fcant@operation/wlknwi