DevOps案例旨在幫助用戶在實(shí)踐中更好的運(yùn)用DevOps。

問題描述

Jenkins2.0 Pipeline框架iPipeline（即plll庫(kù)）對(duì)MergeCI的觸發(fā)條件的設(shè)置為Change merged模式且固定不變，即需要由代碼走查者+2分后，再由Core成員點(diǎn)擊Submit按鈕來將代碼推入庫(kù)，然后才來觸發(fā)MergeCI流程，該過程的VerifyCI和MergeCI流程如下圖所示：

結(jié)合上圖我們可以發(fā)現(xiàn)，這里有個(gè)問題是： 一旦代碼走查通過（+2分），然后Core成員通過（Submit）后，代碼立即入庫(kù)，然后觸發(fā)MergeCI流程，此時(shí)若MergeCI運(yùn)行出錯(cuò)，那錯(cuò)誤此時(shí)已經(jīng)入庫(kù)并且影響后續(xù)開發(fā)人員合入代碼。

再結(jié)合本項(xiàng)目協(xié)議開發(fā)自身的實(shí)際特點(diǎn)，很有可能VerifyCI通過后的MergeCI會(huì)和他人產(chǎn)生互相影響，這樣便可能導(dǎo)致主干分支代碼有錯(cuò)，開發(fā)人員之間互相影響，最終影響代碼提交合入的效率。

基于此種情況，我們提出的一種模式是，MergeCI由代碼審查人員在Gerrit上打出+2分來觸發(fā)，只有到MergeCI運(yùn)行通過，代碼才會(huì)被推入庫(kù)中，此種方式帶來的一個(gè)最直接的好處就是主干分支上的代碼永遠(yuǎn)正確的，而且不會(huì)因?yàn)镸ergeCI報(bào)錯(cuò)而影響他人合代碼，而且該方法帶來的另外一個(gè)好處便是無需設(shè)定關(guān)鍵角色來負(fù)責(zé)Submit代碼入庫(kù)，僅僅需要的是代碼走查人員即可，這樣也提高了自動(dòng)化程度，節(jié)省人力。將該流程可以示意如下圖：

因此plll庫(kù)的這種MergeCI的設(shè)置方式并不滿足本項(xiàng)目，因此我們決定擴(kuò)充plll庫(kù)對(duì)于MergeCI運(yùn)行模式的支持。

優(yōu)化實(shí)踐

通過重載了plll庫(kù)的屬性設(shè)置函數(shù)，加入了根據(jù)CI類型來完成MergeCI不同觸發(fā)條件的設(shè)置：

/**

* 工具名稱：set_default_properties

* 工具描述：設(shè)置默認(rèn)的參數(shù)

* 參數(shù)說明：

* - citype : CI類型

* - args : 參數(shù)列表

**/

def set_default_properties(citype, args){

def buildParameters =[]

def buildTriggers =[]

set_parameters_properties(buildParameters, args)

set_cron_properties(buildTriggers, args)

set_gerrit_properties(citype, buildParameters, buildTriggers, args)

/* --------參數(shù)------- */

properties([

[$class:'GitLabConnectionProperty', gitLabConnection:''],

[$class:'RebuildSettings', autoRebuild:false, rebuildDisabled:false],

buildDiscarder(logRotator(artifactDaysToKeepStr:'', artifactNumToKeepStr:'', daysToKeepStr:'14', numToKeepStr:'100')),

parameters(buildParameters),

pipelineTriggers(buildTriggers)

])

/* 清空臨時(shí)變量 */

buildParameters=null

buildTriggers=null

return

}

/**

* 函數(shù)名稱：設(shè)置gerrit屬性

**/

def set_gerrit_properties(citype, buildParameters, buildTriggers, args)

{

// ...此處代碼省略...

if("verifyci"=="${citype}"){

gerritEvents =[

patchsetCreated(

excludeDrafts:false,

excludeNoCodeChange:true,

excludeTrivialRebase:false

),

draftPublished()

]

// 如果CI類型是MergeCI，則設(shè)置器觸發(fā)條件為Code-Review +2方式來觸發(fā)

}elseif("mergeci"=="${citype}"){

gerritEvents =[

commentAdded(commentAddedTriggerApprovalValue:'+2', verdictCategory:'Code-Review')

]

}

// ...此處代碼省略...

}

由代碼可知，在set_gerrit_properties函數(shù)中，做了特殊判斷，若是MergeCI，則單獨(dú)將其觸發(fā)條件設(shè)置為Code-Review +2，這樣便可以滿足需求。

使用舉例：

在MergeCI的Jenkinsfile中調(diào)用plll.set_default_properties設(shè)置項(xiàng)目屬性時(shí)明確指定mergeci類型即可，以本項(xiàng)目的Jenkinsfile代碼中設(shè)置默認(rèn)屬性參數(shù)為例：

def set_default_properties(){

plll.set_default_properties("mergeci",[

/* 關(guān)聯(lián)gerrit */

gerrit:[

server:"${env.GERRIT_SERVER_NAME}",

projects:[[project:"${env.GERRIT_PROJECT}", branch:"${plll.getJobBaseName()}"]]

],

/* 自定義參數(shù) */

parameters:[

choice(choices:'yes\nno', description:'清空編譯環(huán)境', name:'CLEAN_ALL'),

string(defaultValue:"${plll.getJobBaseName()}", description:'觸發(fā)分支',name:'BRANCH_TAG')

],

]);

}

除此之外，還需要在Jenkins系統(tǒng)管理中MergeCI的Gerrit Trigger設(shè)置中作如下圖所示的配置即可：

優(yōu)缺點(diǎn)分析

1. 優(yōu)點(diǎn)

開發(fā)人員互相獨(dú)立，別人錯(cuò)誤的代碼無法入庫(kù)，不影響他人

主干分支代碼永遠(yuǎn)正確，不影響別人拉代碼驗(yàn)證和正常合入代碼

無需小組核心成員進(jìn)行submit操作，MergeCI一旦運(yùn)行正確，代碼則自動(dòng)入庫(kù)

2. 缺點(diǎn)

原理決定了其無法并行，所以需要根據(jù)不同的項(xiàng)目情況酌情考慮。但是從本項(xiàng)目實(shí)際實(shí)踐的整局來看，本項(xiàng)目VerifyCI支持?jǐn)?shù)個(gè)任務(wù)同時(shí)并發(fā)執(zhí)行，而MergeCI排隊(duì)執(zhí)行，但由于MergeCI執(zhí)行較快，而且沖突很少，因此MergeCI的代碼都能逐個(gè)順利地合入，幸福感較以前有很大提升。