張曉帆，劉 寧，潘 帆

(1.中國電子科技集團(tuán)第10研究所，四川 成都 610036；2.四川大學(xué) 電子信息學(xué)院，四川 成都 610207)

0 引 言

作為敏捷軟件開發(fā)的核心實(shí)踐，持續(xù)集成/持續(xù)交付向開發(fā)和交付團(tuán)隊(duì)提供及時有效的反饋，以持續(xù)提升開發(fā)和交付的效率和質(zhì)量[1-3]。持續(xù)集成/持續(xù)交付成功實(shí)踐的關(guān)鍵在于開發(fā)/測試/交付團(tuán)隊(duì)間的緊密合作。然而，不同的團(tuán)隊(duì)具有不同的背景和領(lǐng)域知識，因此緊密合作要求集成/交付相關(guān)信息高效地傳遞到正確的團(tuán)隊(duì)/人員，以便在正確的時間采取正確的行動?！案咝А钡臏贤ㄔ谥行突虼笮徒M織中始終是一個挑戰(zhàn)，而將持續(xù)集成/持續(xù)交付過程進(jìn)行“可視化”將大大有助于信息的高效傳遞。

目前，對持續(xù)集成/持續(xù)交付的研究主要集中于對集成/交付步驟和各步驟相關(guān)工具的研究，對全過程可視化的研究相對較少。文獻(xiàn)[4-5]提出了由開發(fā)集成，驗(yàn)收測試，部署發(fā)布構(gòu)成的持續(xù)交付基本過程，并提出了對全過程進(jìn)行監(jiān)控的概念。文獻(xiàn)[6]提出了由構(gòu)建，單元測試，集成測試，驗(yàn)收測試構(gòu)成的持續(xù)交付的驗(yàn)證步驟。文獻(xiàn)[7]提出了DevOps常用的CI/CD工具集合。文獻(xiàn)[8]提出了通過可視化方法，對敏捷團(tuán)隊(duì)中各成員的貢獻(xiàn)進(jìn)行統(tǒng)計和呈現(xiàn)。

針對上述問題，文中提出一種持續(xù)集成(CI)/持續(xù)交付(CD)的可視化設(shè)計體系和方法，包括：哪些信息需要可視化；信息如何可視化；信息如何被動或主動地傳遞到合適的團(tuán)隊(duì)；在發(fā)現(xiàn)問題時，相應(yīng)團(tuán)隊(duì)該如何采取行動。同時，提出該“可視化”系統(tǒng)的實(shí)現(xiàn)架構(gòu)參考，包括由業(yè)界主流開源軟件Jenkins、BitBucket、Jira等工具組成的系統(tǒng)架構(gòu)。該體系設(shè)計和架構(gòu)有效地將各種信息呈現(xiàn)或推送給相關(guān)人員，提升了持續(xù)集成/持續(xù)交付的實(shí)施效率，幫助團(tuán)隊(duì)有效提升了開發(fā)和交付的質(zhì)量和效率。

1 可視化體系設(shè)計

持續(xù)集成/持續(xù)交付系統(tǒng)的可視化體系設(shè)計如圖1所示。

圖1 CI/CD可視化視圖

該體系由兩部分構(gòu)成：

持續(xù)集成(CI)狀態(tài)視圖：該部分主要向開發(fā)團(tuán)隊(duì)傳遞集成過程相關(guān)信息。對比文獻(xiàn)[9-10]，文中提出了CI排隊(duì)過程和隊(duì)列視圖。

持續(xù)集成(CI)/持續(xù)交付(CD)健康視圖：該部分主要向開發(fā)/測試/交付團(tuán)隊(duì)傳遞產(chǎn)品交付相關(guān)信息。文中提出了CI/CD核心階段和擴(kuò)展階段的概念，并針對不同階段的重要程度和反饋成本，提出了多種系統(tǒng)同步和可視化通知手段。

1.1 持續(xù)集成(CI)狀態(tài)視圖

該部分顯示了對開發(fā)團(tuán)隊(duì)很重要的CI狀態(tài)信息，包括請求排隊(duì)狀態(tài)和集成流水線狀態(tài)。典型的CI過程如圖2所示，包括排隊(duì)階段和流水線階段。

圖2 CI排隊(duì)和流水線

(1)CI隊(duì)列視圖。

在中等規(guī)模的組織(約100個開發(fā)工程師)中，考慮每個CI持續(xù)時間為10分鐘，如果每個工程師每日提交集成請求，則集成請求將不得不在CI系統(tǒng)中排隊(duì)以依次處理。

CI隊(duì)列視圖可以讓每個工程師知道CI系統(tǒng)的繁忙程度，了解CI系統(tǒng)是否接受了集成請求，并預(yù)測何時可以處理該集成請求。因此，CI相關(guān)的信息都應(yīng)在此展示，如圖3，包括請求提交者名稱、提交者時間以及為集成提交的分支。

圖3 CI隊(duì)列視圖

(2)CI流水線視圖。

如圖4，該視圖讓每個工程師知道其集成請求處理的狀態(tài)，不同的顏色給出了CI流水線各步驟的不同狀態(tài)。典型的CI步驟包括：系統(tǒng)空閑→構(gòu)建→UT→IT→內(nèi)部發(fā)布。

圖4 CI流水線視圖

當(dāng)某步驟失敗時，CI系統(tǒng)該如何處理？不同的團(tuán)隊(duì)有不同的看法，有團(tuán)隊(duì)建議暫停CI流水線并向團(tuán)隊(duì)發(fā)出警報，有團(tuán)隊(duì)建議直接回滾版本并給提交者以提示。根據(jù)筆者數(shù)年的實(shí)踐經(jīng)驗(yàn)，總結(jié)該部分的設(shè)計如下：

·如果該系統(tǒng)服務(wù)于一個小團(tuán)隊(duì)，集成系統(tǒng)的吞吐量不會成為問題，團(tuán)隊(duì)的溝通和立即行動是可行的。在這種情況下，CI失敗時，可以選擇暫停CI流水線并向團(tuán)隊(duì)發(fā)出警報。

·如果該系統(tǒng)服務(wù)于中/大規(guī)模的團(tuán)隊(duì)，則集成系統(tǒng)吞吐量將成為問題。與此同時，大中型團(tuán)隊(duì)的溝通問題會更加嚴(yán)重，團(tuán)隊(duì)成員對集成時發(fā)現(xiàn)的問題的響應(yīng)會更為遲緩。在這種情況下，CI系統(tǒng)自動回退版本并給提交者以提示，騰空CI系統(tǒng)以使系統(tǒng)可以處理下一位工程師的集成請求。這種方式可以使集成系統(tǒng)保持高吞吐量，以提升中/大規(guī)模團(tuán)隊(duì)的持續(xù)集成效率。

1.2 持續(xù)集成(CI)/持續(xù)交付(CD)健康視圖

該部分視圖呈現(xiàn)每個版本的CI/CD健康狀況，開發(fā)/測試/交付團(tuán)隊(duì)都應(yīng)該關(guān)注該部分呈現(xiàn)的信息：

·開發(fā)/測試團(tuán)隊(duì)?wèi)?yīng)采取行動解決測試中發(fā)現(xiàn)的各種問題；

·交付團(tuán)隊(duì)可以根據(jù)各版本的健康狀況，選擇合適的版本以進(jìn)行交付。

每個版本的CI/CD過程也是一個流水線。該流水線通常有4個階段，如圖5所示。

圖5 版本CI/CD流水線視圖

(1)持續(xù)集成(CI)核心階段：build/UT/IT。

該部分呈現(xiàn)了build/UT/IT的健康狀態(tài)。

此階段中的任何步驟失敗都將導(dǎo)致CI失敗。如果發(fā)生任何失敗，都不會進(jìn)行新版本(內(nèi)部)發(fā)布，并且主干版本將回滾到最后一次成功發(fā)布的版本，并將郵件發(fā)送給提交者以指示失敗原因。

(2)持續(xù)集成(CI)擴(kuò)展階段：代碼靜態(tài)檢查。

此階段主要完成代碼的靜態(tài)檢查，包括build warning，或通過lint工具進(jìn)行的代碼規(guī)范靜態(tài)檢查，如文獻(xiàn)[11]。如果此階段中的步驟失敗，流水線不會終止，但開發(fā)團(tuán)隊(duì)會收到一封警告郵件。

工程師需要從CI獲得快速反饋，需要通過CI在每天進(jìn)行多次構(gòu)建和軟件測試，因此單次CI的時間需要縮短。對于某些不太重要，并且耗時的驗(yàn)證步驟，如代碼靜態(tài)檢查，或代碼圈復(fù)雜性分析，都可以將其置于擴(kuò)展階段。由于這些驗(yàn)證處于擴(kuò)展階段而非核心階段，當(dāng)在此階段檢查出問題時，比如引入大量新構(gòu)建警告時，因?yàn)闆]有版本回退機(jī)制，開發(fā)團(tuán)隊(duì)可能會也可能不會修復(fù)這些問題。筆者在過去幾年遇到了這個問題：越來越多的build warning被引入集成主線，而沒有人采取行動。因此，在可視化設(shè)計中，將擴(kuò)展階段的結(jié)果公示到整個團(tuán)隊(duì)，讓整個團(tuán)隊(duì)知道誰在哪個版本引入新警告，使得提交者有壓力不要引入build warning或盡快修復(fù)它們。

(3)持續(xù)交付(CD)核心階段：驗(yàn)收測試(user acceptance test)。

此階段從產(chǎn)品交付的角度，進(jìn)行驗(yàn)收測試。如文獻(xiàn)[12-13]，驗(yàn)收測試通常自動化進(jìn)行。如果驗(yàn)收測試通過，該版本可以進(jìn)行發(fā)布。如果驗(yàn)收測試失敗，整個CI/CD系統(tǒng)將被暫停，并向開發(fā)團(tuán)隊(duì)進(jìn)行紅色警報，以便推動開發(fā)團(tuán)隊(duì)及時修復(fù)在驗(yàn)收測試中發(fā)現(xiàn)的問題。

通常，從用戶角度進(jìn)行的驗(yàn)收測試會耗費(fèi)較長時間，比如1～2小時或更長?？紤]到CI的典型持續(xù)時間為10分鐘，對每個通過CI的版本進(jìn)行驗(yàn)收測試是不可行的。在該系統(tǒng)中，采用異步機(jī)制以處理CI過程和驗(yàn)收測試過程難以同步的問題：驗(yàn)收測試輪詢最新(內(nèi)部)發(fā)布的CI版本以開始測試，這里某些CI版本可能被“繞過”，如圖6所示。

圖6 異步執(zhí)行長時間的驗(yàn)收測試

因?yàn)镃I和驗(yàn)收測試采用了異步的設(shè)計，在驗(yàn)收測試失敗的情況下，集成流水線該如何進(jìn)行？如圖6，如果AT2失敗，系統(tǒng)如何處理，如何向用戶進(jìn)行反饋。通常解決方法有3種：

·通過郵件指示失敗，并且CI/CD系統(tǒng)繼續(xù)處理新的CI請求。

·V2失敗，則回退以使用V1進(jìn)行驗(yàn)收測試。

·暫停整個流水線直到AT2失敗的問題修復(fù)，并向整個團(tuán)隊(duì)及時告警通知。

根據(jù)實(shí)踐，方法1存在開發(fā)團(tuán)隊(duì)沒有動力/壓力來解決AT故障的問題，因?yàn)殚_發(fā)團(tuán)隊(duì)的新CI請求可以繼續(xù)處理。當(dāng)越來越多的新CI請求集成入主線時，主線版本的質(zhì)量持續(xù)惡化。方法2也有一些限制：首先，它使系統(tǒng)更復(fù)雜，其次，它加長了反饋周期，因?yàn)樗枰L時間重新運(yùn)行V1的AT。方法3是最終使用的方法，當(dāng)AT2失敗時，系統(tǒng)會自動采取3項(xiàng)行動，迫使開發(fā)團(tuán)隊(duì)立即采取行動以修復(fù)問題：

①CI系統(tǒng)將被暫停，開發(fā)團(tuán)隊(duì)不能再提新的CI請求，迫使開發(fā)團(tuán)隊(duì)必須采取行動；

②郵件將廣播給開發(fā)團(tuán)隊(duì)，提示驗(yàn)收測試(AT)在V1或V2版本失敗，CI系統(tǒng)暫停；

③系統(tǒng)將可視化“紅色警報”，如圖7所示。

圖7 可視化“紅色警報”(針對驗(yàn)收測試失敗)

(4)持續(xù)交付(CD)擴(kuò)展階段：可靠性測試(reliability test)。

不僅可靠性測試，其他測試，如性能測試、探索測試等也可以在該階段進(jìn)行。

如果擴(kuò)展階段的驗(yàn)證失敗，則應(yīng)在問題跟蹤系統(tǒng)(如Jira)中記錄和跟蹤問題，以便開發(fā)團(tuán)隊(duì)可以跟進(jìn)。如果可靠性測試通過，對于交付團(tuán)隊(duì)，該版本將是更有信心的候選交付版本。可靠性測試的典型持續(xù)時間為1～2天，因此，與CI和驗(yàn)收測試的異步設(shè)計類似，可靠性測試也以異步方式運(yùn)行：并非所有通過驗(yàn)收測試的版本都會進(jìn)行可靠性測試，可靠性測試將輪詢通過驗(yàn)收測試的最新版本以進(jìn)行測試，并且可以繞過某些版本。

表1總結(jié)了CI/CD系統(tǒng)的可視化反饋/指示，以及各團(tuán)隊(duì)所需的響應(yīng)。

表1 CI/CD可視化總結(jié)

2 實(shí)現(xiàn)架構(gòu)參考

可視化系統(tǒng)的實(shí)現(xiàn)架構(gòu)參考如圖8所示。

圖8 可視化系統(tǒng)架構(gòu)設(shè)計

可視化服務(wù)是采用NodeJS框架的Web服務(wù)，用于顯示CI/CD的狀態(tài)和數(shù)據(jù)。

如文獻(xiàn)[14]，CI/CD系統(tǒng)由多種子系統(tǒng)構(gòu)成，其核心為Jenkins。Jenkins提供了流水線功能，并提供了CI/CD系統(tǒng)可視化所需的數(shù)據(jù)。

(1)可視化服務(wù)需要查詢Jenkins的數(shù)據(jù)，如提交者名稱，時間，構(gòu)建和測試結(jié)果的種類。

Node.js提供了一個模塊和接口，以查詢Jenkins的數(shù)據(jù)。下面是數(shù)據(jù)查詢樣例代碼片段：

var jenkinsapi=require('jenkins-api');

# Get last build

var jobName='Jenkins-build-jobs'

jenkinsapi.last_build_info(jobName, function(err, data) {

callback(err,data);

});

# Get one specific build

var jobName='Jenkins-build-jobs';

var buildNum=10;

jenkinsapi.build_info(jobName, buildNum,function(err, data) {

callback(err,data);

});

通過查詢接口，如下JSON格式的數(shù)據(jù)將從Jenkins返回Node.js的模塊。

"builds" :

{

"buildNumber" : 294,

"duration" : "4 min",

"icon" : "blue.png",

"jobName" : "A-Jenkins-BuildJob",

"parentBuildNumber" : 384,

"parentJobName" : " A-Jenkins-BuildJob-Parent",

"phaseName" : " Build",

"result" : "SUCCESS",

"url" : "url for the Jenkins job"

},

其后，可視化服務(wù)解析數(shù)據(jù)，并按設(shè)計顯示CI/CD的狀態(tài)和數(shù)據(jù)。

(2)可視化系統(tǒng)還提供了到Jira的超鏈接。所有團(tuán)隊(duì)都可以通過超鏈接直達(dá)Jira，以報告反饋/問題。

作為最流行的CI/CD工具，Jenkins具有強(qiáng)大的集成功能，以與各種構(gòu)建/測試/通知系統(tǒng)互通：

·在該架構(gòu)中，BitBucket用作版本控制系統(tǒng)。BitBucket是私有Git倉庫，用于存儲來自開發(fā)團(tuán)隊(duì)的代碼，通過其WebHook，BitBucket可以在某個分支上發(fā)生提交時觸發(fā)Jenkins作業(yè)。如文獻(xiàn)[15]，Jenkins從BitBucket中獲取代碼更改，并進(jìn)行本地構(gòu)建。

·使用構(gòu)建輸出，Jenkins與測試系統(tǒng)接口。測試系統(tǒng)的參考是CppUnit+labview。 CppUnit適用于UT/IT。它可以在非目標(biāo)環(huán)境中高效運(yùn)行。對于驗(yàn)收測試和可靠性測試，由于需要真實(shí)的目標(biāo)環(huán)境，labview可用于鏈接和控制各種設(shè)備進(jìn)行自動測試。

·當(dāng)獲得測試結(jié)果時，Jenkins可以與郵件系統(tǒng)連接以通知團(tuán)隊(duì)，并將失敗作為問題記錄入輕量級問題跟蹤工具Jira。

3 結(jié)束語

提出了一種持續(xù)集成/持續(xù)交付系統(tǒng)的可視化體系設(shè)計和參考架構(gòu)。該設(shè)計將各種信息在不同的視圖進(jìn)行合理組織，將信息呈現(xiàn)或推送給最相關(guān)人員，并建議了團(tuán)隊(duì)在各種情況下應(yīng)該采取的行動。該設(shè)計連接了開發(fā)/測試團(tuán)隊(duì)和產(chǎn)品交付團(tuán)隊(duì)，有效在團(tuán)隊(duì)中共享信息，促進(jìn)團(tuán)隊(duì)協(xié)作，高效持續(xù)集成以持續(xù)交付高質(zhì)量的產(chǎn)品。

可視化是持續(xù)交付的重大進(jìn)步，而探索永遠(yuǎn)不會停止。持續(xù)交付仍有許多機(jī)遇和挑戰(zhàn)：CI/CD系統(tǒng)在展示數(shù)據(jù)的同時，會記錄大量數(shù)據(jù)。如何利用這些數(shù)據(jù)以不斷改進(jìn)系統(tǒng)本身和開發(fā)/交付過程，這是一個可以進(jìn)一步探索的主題。當(dāng)軟件準(zhǔn)備交付時，可以進(jìn)一步為最終用戶進(jìn)行持續(xù)部署。然而，對于嵌入式設(shè)備/系統(tǒng)來說，持續(xù)部署將是一個巨大的挑戰(zhàn)，當(dāng)成百上千個設(shè)備通過有線或無線連接分布在不同位置時，可以想象將新軟件部署/升級到每個設(shè)備的難度。該難題也是可以進(jìn)一步探索的主題。