一、前言

1、CI/CD

CI/CD 是一種通過在應(yīng)用開發(fā)階段引入自動化來頻繁向客戶交付應(yīng)用的方法。CI/CD 的核心概念是持續(xù)集成、持續(xù)交付和持續(xù)部署。

作為一種面向開發(fā)和運維團隊的解決方案，CI/CD 主要針對在集成新代碼時所引發(fā)的問題（亦稱：“集成地獄”）。

具體而言，CI/CD 可讓持續(xù)自動化和持續(xù)監(jiān)控貫穿于應(yīng)用的整個生命周期（從集成和測試階段，到交付和部署）。這些關(guān)聯(lián)的事務(wù)通常被統(tǒng)稱為“CI/CD管道（Pipeline，一般也稱為管線或流水線）”，由開發(fā)和運維團隊以敏捷方式協(xié)同支持。

1、CI持續(xù)集成（Continuous Integration）
現(xiàn)代應(yīng)用開發(fā)的目標是讓多位開發(fā)人員同時處理同一應(yīng)用的不同功能。但是，如果企業(yè)安排在一天內(nèi)將所有分支源代碼合并在一起（稱為“合并日”），最終可能造成工作繁瑣、耗時，而且需要手動完成。

這是因為當一位獨立工作的開發(fā)人員對應(yīng)用進行更改時，有可能會與其他開發(fā)人員同時進行的更改發(fā)生沖突。如果每個開發(fā)人員都自定義自己的本地集成開發(fā)環(huán)境（IDE），而不是讓團隊就一個基于云的 IDE 達成一致，那么就會讓問題更加雪上加霜。

持續(xù)集成（CI）可以幫助開發(fā)人員更加頻繁地（有時甚至每天）將代碼更改合并到共享分支或“主干”中。一旦開發(fā)人員對應(yīng)用所做的更改被合并，系統(tǒng)就會通過自動構(gòu)建應(yīng)用并運行不同級別的自動化測試（通常是單元測試和集成測試）來驗證這些更改，確保這些更改沒有對應(yīng)用造成破壞。
這意味著測試內(nèi)容涵蓋了從類和函數(shù)到構(gòu)成整個應(yīng)用的不同模塊。如果自動化測試發(fā)現(xiàn)新代碼和現(xiàn)有代碼之間存在沖突，CI 可以更加輕松地快速修復(fù)這些錯誤。

2、CD持續(xù)交付（Continuous Delivery）
對于一個成熟的 CI/CD 管道來說，最后的階段是持續(xù)部署。作為持續(xù)交付——自動將生產(chǎn)就緒型構(gòu)建版本發(fā)布到代碼存儲庫——的延伸，持續(xù)部署可以自動將應(yīng)用發(fā)布到生產(chǎn)環(huán)境。由于在生產(chǎn)之前的管道階段沒有手動門控，因此持續(xù)部署在很大程度上都得依賴精心設(shè)計的測試自動化。

實際上，持續(xù)部署意味著開發(fā)人員對云應(yīng)用的更改在編寫后的幾分鐘內(nèi)就能生效（假設(shè)它通過了自動化測試）。這更加便于持續(xù)接收和整合用戶反饋?？偠灾?，所有這些 CI/CD 的關(guān)聯(lián)步驟都有助于降低應(yīng)用的部署風(fēng)險，因此更便于以小件的方式（而非一次性）發(fā)布對應(yīng)用的更改。不過，由于還需要編寫自動化測試以適應(yīng) CI/CD 管道中的各種測試和發(fā)布階段，因此前期投資還是會很大。

2、云化流水線

云化流水線是交付新版本軟件必須執(zhí)行的一系列步驟，是一種專注于通過自動化在整個軟件開發(fā)生命周期中改進軟件交付的實踐，根據(jù)用戶需要的場景，如開發(fā)測試環(huán)境應(yīng)用部署、生產(chǎn)環(huán)境應(yīng)用部署等，對這些自動化任務(wù)進行自定義編排，一次配置后就可以一鍵自動化觸發(fā)調(diào)度執(zhí)行，避免頻繁低效的手工操作。

通過在軟件開發(fā)生命周期的整個開發(fā)、測試、生產(chǎn)和監(jiān)控階段自動執(zhí)行 CI/CD，能夠更快、更安全地開發(fā)更高質(zhì)量的代碼。盡管可以手動執(zhí)行 CI/CD 管道的每個步驟，但 CI/CD 管道的真正價值是通過自動化實現(xiàn)的。

流水線是通過生成、測試和部署代碼的路徑（也稱為 CI/CD）推動軟件開發(fā)的過程。通過自動化該過程，目標是最大限度地減少人為錯誤，并維護軟件發(fā)布方式的一致過程。其中包含的工具可能包括編譯代碼、單元測試、代碼分析、安全性和二進制文件創(chuàng)建。

二、插件介紹

1、流水線插件介紹

從上面我們可以得知，流水線服務(wù)本質(zhì)上是一個可視化的自動化任務(wù)調(diào)度平臺，需要配合軟件開發(fā)生產(chǎn)線中編譯構(gòu)建、代碼檢查、測試計劃、部署等服務(wù)的自動化任務(wù)使用。

而流水線內(nèi)置了一系列常用的插件，供用戶在流水線進行編排時使用作為整個流程的某個環(huán)節(jié)。這樣的插件是可擴展、可自定義的。利用流水線在執(zhí)行過程中串行、并行的不同執(zhí)行類型，以及順序執(zhí)行場景下對于各個步驟是否執(zhí)行成功與否的判斷，流水線插件在CI/CD的過程中可以起到重要作用。

2、一些插件的簡單介紹

1、代碼檢查
在服務(wù)開始嘗試將代碼部署到機器上時，首先必須要執(zhí)行的就是將代碼從代碼倉中拉取、構(gòu)建、打包等操作。
而對于代碼本身而言，除了本地的一些代碼檢查規(guī)范外，我們還會在流水線中添加這樣的檢查步驟，對全量代碼進行諸如規(guī)范性、安全性、圈復(fù)雜度、CleanCode等一系列內(nèi)容的檢查。
當服務(wù)嘗試部署的代碼中可能存在影響質(zhì)量的嚴重問題時，代碼檢查中所暴露的問題會在該步驟的門禁檢查中發(fā)現(xiàn)并直接攔截，禁止流水線進一步的向下執(zhí)行，避免引入可能的風(fēng)險和問題。

2、安全病毒檢查
除了代碼層面的檢查外，我們還會對構(gòu)建產(chǎn)物進行安全與病毒掃描，這里會直接與中央的病毒樣例庫連接做病毒的掃描和查殺，避免存在惡意病毒文件連同代碼一起被打包上傳到現(xiàn)網(wǎng)機器。

3、開源依賴檢查
對于開源漏洞與依賴層面，我們也會進行相關(guān)的掃描與檢查。畢竟對于三方依賴而言，服務(wù)自身在做開發(fā)使用的過程中可能并不關(guān)注該依賴是否有開源問題、當前版本是否已經(jīng)過時存在漏洞等，因此對于這一系列依賴，我們會直接與自身的中心倉庫做版本比較，其中包含三方庫與二方庫等，支持Maven、Pypi、Npm、Go等類型。
對于每一個依賴包而言，我們都會給出其對應(yīng)的每個版本號是否為優(yōu)選、可選或禁選。對于不再中心倉庫的依賴包或者版本為禁選類型，同樣的開源依賴檢查會無法通過、流水線也自然無法進一步向下執(zhí)行。

3、如何保證插件配置完整性

對于眾多的檢查與插件配置，上千個微服務(wù)、上萬條流水線，我們?nèi)绾尾拍鼙ＷC所有的流水線都能配置了對應(yīng)的具體插件呢？

對于高度自定義化的流水線而言，雖然可以提供某些模板機制，但本身插件配置對于不同環(huán)境、不同編程語言都會有各自不同的需求，由中央統(tǒng)一全量修改流水線雖然理論上可行，但過于機械、大費周章，被修改流水線的服務(wù)也有可能一頭霧水、甚至流水線都被修改的無法執(zhí)行，并不是最好的策略。

這個時候，我們一般會有更加直接且簡單的措施：生產(chǎn)準入門禁卡點機制。

1. 對于服務(wù)的流水線而言，一般會有Alpha、Beta、Gamma和生產(chǎn)四個發(fā)布階段，這其中前三個階段影響較小，而生產(chǎn)的部署是涉及到現(xiàn)網(wǎng)變更、影響具體C端用戶的，因此需要格外注意。這里，我們會在生產(chǎn)階段前添加一個檢查各項指標是否達標的生產(chǎn)準入門禁卡點，若服務(wù)在流水線中某項指標未達標，則會直接顯示檢查未通過、不允許下一步的操作——也即不允許升級生產(chǎn)。
   • 服務(wù)的門禁卡點指標未達標有可能是確實存在缺陷，也有可能是未配置對應(yīng)的檢查插件，由此便可以反推服務(wù)完成插件的配置。
2. 倘若希望添加新的檢查機制，一般會在準入門禁卡點中加入提示等級的信息，以告知服務(wù)用戶當前構(gòu)建包存在哪些問題、需要完成哪些整改、具體整改的DDL等，不做強制的攔截。
   • 這里需要注意的是，新的門禁卡點不是你想加就加的，需要在產(chǎn)品部TMG研討達成一致結(jié)論，并舉行相關(guān)宣講、賦能、郵件全量知會到具體負責(zé)人，才能進一步行使加卡點的權(quán)利。
3. 在一段時間后，我們會提升門禁卡點的等級，在要求服務(wù)整改的同時，也給予服務(wù)申請暫時屏蔽備案的選擇。
4. 最后在DDL后，我們會直接將門禁設(shè)為強制，此時如果服務(wù)當前的構(gòu)建包仍然包含對應(yīng)問題，則無法跳過、必須整改，否則將無法將代碼部署至生產(chǎn)環(huán)境。

三、插件實踐

除了上述的一些常見流水線插件外，筆者方面同樣基于插件開發(fā)規(guī)范、提供了相關(guān)流水線插件，旨在提升服務(wù)質(zhì)量提升與問題提前攔截。

1、用例通過率

在基于云化測試平臺的功能撥測與告警中我們提出，將服務(wù)在云化測試平臺中所撰寫的測試用例有效的組織起來，以不同的形式調(diào)度、檢查，對服務(wù)的在線功能質(zhì)量能夠起到重要作用。

這里同樣地，服務(wù)將當前所有認為較為重要的功能測試用例統(tǒng)一歸納在一個測試任務(wù)中，并在每個部署階段完成后全量執(zhí)行該測試任務(wù)，以檢查新版本代碼是否引入新的問題、是否對已有功能造成影響。

具體實現(xiàn)層面則較為簡單，直接以任務(wù)執(zhí)行是否達到100%為標準即可。對于存在失敗用例的情況，流水線層面不允許向下執(zhí)行。

2、接口覆蓋率

在第一點中我們提出了用例通過率插件用以衡量功能可用性，但是這其中還存在另外一個問題：

• 用例的實際覆蓋情況如何呢？
  • 假如我的服務(wù)有100個接口，但我的測試任務(wù)只包含了一個接口的測試，那么即使測試任務(wù)完全成功，我們也明白檢查是沒意義的。

對于用例的覆蓋率而言，一般有很多評判標準：例如分支覆蓋、代碼覆蓋等等。由于我們云化在線測試本質(zhì)上是對服務(wù)接口的測試，因此這里我們引入了接口覆蓋率來作為評判標準。

在具體實現(xiàn)上：

1. 我們會針對每個服務(wù)提供所需看護的API基線，一般而言，服務(wù)在生產(chǎn)環(huán)境中存在的接口我們認為是必須看護的。
   • 對于API基線的數(shù)據(jù)來源，我們一般采用調(diào)用鏈運行態(tài)數(shù)據(jù)而非直接套用API設(shè)計文檔接口信息。
     • 我們沒有直接使用API設(shè)計態(tài)的yaml作為API基線的來源，是因為本身API的測試覆蓋是需要有所側(cè)重的，評價一個接口是否有測試看護的價值，很重要的一個維度就是看該接口是否已經(jīng)在現(xiàn)網(wǎng)被用戶所使用。
     • 如果我們直接將全量的設(shè)計接口作為看護標準，一方面會給服務(wù)非常大的測試負擔(dān)與壓力；另一方面也會造成一些無謂的測試人力浪費，為很多整個生命周期都在研發(fā)階段的接口投入過度的測試看護精力。
     • 當然，這種策略一方面會造成測試看護存在一定的延遲性（只有服務(wù)接口先發(fā)布到現(xiàn)網(wǎng)，我們的API基線才會有看護要求）；另一方面也會因為設(shè)計實現(xiàn)的不一致而引發(fā)一些問題，這一點后面會提到。
2. 在服務(wù)執(zhí)行流水線的過程中，在完成全量用例任務(wù)執(zhí)行后，我們會根據(jù)用例執(zhí)行結(jié)果id等信息，完成對用例中所有對應(yīng)接口的獲取采集，并與所需看護的API基線進行比較：若覆蓋率未能達到既定百分比，則會認為當前測試任務(wù)覆蓋率未達標。
   • 這里，我們主要面向的發(fā)布階段為Alpha、Beta與Gamma階段，旨在對開發(fā)階段的測試完整性做檢查。
   • 在功能層面，我們首先會獲取到具體的測試任務(wù)執(zhí)行結(jié)果id，根據(jù)id獲取全量用例以及對應(yīng)的ActionWord信息。
   • 對于去重后的ActionWord，我們會逐個做內(nèi)容解析、并匯總?cè)康臏y試任務(wù)覆蓋API，同時與對應(yīng)的API基線做比照，以此來計算整體的覆蓋情況。
     • 在對于測試接口與API基線接口的比較也存在一定的問題：設(shè)計與實現(xiàn)可能存在不一致現(xiàn)象。這個現(xiàn)象始終困擾著整個開發(fā)團隊——至少是我們的團隊，很多時候API的實現(xiàn)未必是嚴格按照API設(shè)計文檔來執(zhí)行的，這其中有很多現(xiàn)實原因。而一旦接口完成了開發(fā)，反過去再修改設(shè)計文檔又顯得倒行逆施。
     • 針對這類不一致問題所帶來的API匹配與比較問題，我們一方面會推動服務(wù)完善API設(shè)計文檔，另一方面也通過一些模糊匹配、接口版本信息/路徑內(nèi)參數(shù)提取替換等方法，完成API設(shè)計態(tài)與實現(xiàn)態(tài)的匹配。

3、接口健壯性

除了必要的功能可用性與測試覆蓋率，我們還對接口本身的健壯度提供了相應(yīng)的自動化測試與評估插件。

在具體實現(xiàn)與原理上：

1. 所謂健壯性（Robustness），也就是我們之前一直提及的魯棒性，是指一個計算機系統(tǒng)在執(zhí)行過程中處理錯誤，以及算法在遭遇輸入、運算等異常時維持正常運行的能力。對于接口而言，也就是說在接收各種類型的請求參數(shù)時，能否正確的進行處理并返回預(yù)期結(jié)果的能力。
   • 舉個例子，例如普通的根據(jù)主鍵id查詢的接口，假如外部服務(wù)傳遞的id為-1，若不作相關(guān)參數(shù)校驗直接查表，必然會返回5xx類型錯誤。
2. 我們會搭建接口健壯性測試平臺，服務(wù)需完成對應(yīng)API設(shè)計文檔yaml地址、測試階段、測試地址、認證token等配置。
3. 在服務(wù)執(zhí)行流水線的過程中，會觸發(fā)接口健壯性檢查任務(wù)。此時測試平臺會自動拉取最新的yaml文檔、分析接口構(gòu)成、具體參數(shù)與取值范圍，并完成非常規(guī)請求參數(shù)構(gòu)造并根據(jù)測試地址發(fā)起測試，根據(jù)接口的返回值情況來做進一步的接口健壯性判斷。
   • 對于非常規(guī)請求參數(shù)的構(gòu)造，主要是以yaml文檔中對于API參數(shù)的定義類型與取值范圍做相應(yīng)的模板化構(gòu)造：例如，對于int類型參數(shù)，我們就可以取0、-1、邊界值等作為請求參數(shù)；對于String類型則可以取類似%、*等類型的符號等。
   • 對于測試結(jié)果而言，我們一般認為2xx、4xx類型為成功，而5xx類型為系統(tǒng)內(nèi)部故障、屬于失敗類型。

接口健壯性測試可以協(xié)助服務(wù)提前返現(xiàn)代碼中可能存在的異常情況判斷與接口狀態(tài)碼規(guī)范問題，檢查的結(jié)果也主要起到參考作用，并不會直接參與門禁卡點與強制攔截。

四、結(jié)語

在CI/CD流水線的大背景下，雖然插件只是其中很小的組成部分，但合理的開發(fā)、運用與推廣插件，不僅能夠極大程度降低質(zhì)量看護與運營門檻、提升效率，而且還能為服務(wù)帶來很多額外的質(zhì)量看護視角，從而提升服務(wù)在研發(fā)段的質(zhì)量看護能力，降低現(xiàn)網(wǎng)的故障產(chǎn)生。

參考文章：

什么是 CI/CD - RedHat文章來源地址http://www.zghlxwxcb.cn/news/detail-817707.html

到了這里，關(guān)于CI/CD流水線插件在服務(wù)質(zhì)量看護中的實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！