DevOps案例旨在幫助用戶在實踐中更好的運用DevOps

DevOps案例旨在幫助用戶在實踐中更好的運用DevOps。

問題描述

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

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

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

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

因此plll庫的這種MergeCI的設(shè)置方式并不滿足本項目，因此我們決定擴充plll庫對于MergeCI運行模式的支持。

優(yōu)化實踐

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

/**

* 工具名稱：set_default_properties

* 工具描述：設(shè)置默認的參數(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)

])

/* 清空臨時變量 */

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，則單獨將其觸發(fā)條件設(shè)置為Code-Review +2，這樣便可以滿足需求。

使用舉例：

在MergeCI的Jenkinsfile中調(diào)用plll.set_default_properties設(shè)置項目屬性時明確指定mergeci類型即可，以本項目的Jenkinsfile代碼中設(shè)置默認屬性參數(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)缺點分析

1. 優(yōu)點

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

主干分支代碼永遠正確，不影響別人拉代碼驗證和正常合入代碼

無需小組核心成員進行submit操作，MergeCI一旦運行正確，代碼則自動入庫

2. 缺點

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