Pipeline改造過程中的幾點(diǎn)主要經(jīng)驗(yàn)分享

概述

經(jīng)過前面三篇文章的詳細(xì)介紹，講述了本項(xiàng)目在Jenkins2.0 Pipeline實(shí)踐和iPipeline框架（plll庫(kù)）應(yīng)用的過程中的一些思考、改進(jìn)以及實(shí)踐，而本文作為系列文章的最后一篇，主要想分享一下本項(xiàng)目在過去一段時(shí)間中對(duì)于Jenkins2.0 Pipeline改造的一些經(jīng)驗(yàn)。

經(jīng)驗(yàn)分享

XXX項(xiàng)目遷移到Pipeline已經(jīng)有一段時(shí)間了，期間不斷重構(gòu)，不斷改進(jìn)和演化，本文準(zhǔn)備在此給出幾條本項(xiàng)目Pipeline改造過程中的幾點(diǎn)主要經(jīng)驗(yàn)分享。

1. 建議項(xiàng)目打造分層模式的Pipeline流程

本項(xiàng)目啟用CI分層策略，打造了4個(gè)層次的CI流程，分別為：

VerifyCI

MergeCI

DailyCI

TagCI

其中VerifyCI和MergeCI用于開發(fā)人員平時(shí)合代碼、DailyCI對(duì)應(yīng)每日構(gòu)建，而TagCI則用于版本構(gòu)建，各司其職，層次分明。

具體如下圖所示：

2. 建議打造多層次并行的Pipeline流程

不同Pipeline之間可并行Jenkins已天然支持，而利用iPipeline則能支持同一個(gè)Pipeline的不同任務(wù)之間的并行，而再具體到某個(gè)任務(wù)內(nèi)則設(shè)計(jì)者應(yīng)根據(jù)各自項(xiàng)目實(shí)際情況，盡量將任務(wù)內(nèi)各步驟設(shè)計(jì)成并行模式。本項(xiàng)目對(duì)VerifyCI任務(wù)內(nèi)的各步驟運(yùn)行規(guī)劃如下，能并行的步驟盡量并行執(zhí)行：

3. 關(guān)于MergeCI的運(yùn)行模式與流程的摸索

該部分可以參考：-Jenkins2.0 Pipeline框架（iPipeline）優(yōu)化實(shí)踐之路（三：MergeCI機(jī)制研究）

4. 關(guān)于Jenkinsfile托管方式的小技巧

雖然說一般要求將Jenkinsfile與所在代碼庫(kù)的代碼放在一起托管，即將Jenkinsfile置于代碼庫(kù)根目錄，但我們?cè)趯?shí)際實(shí)踐中發(fā)現(xiàn)一個(gè)問題是，一旦代碼庫(kù)比較龐大，每次Pipeline運(yùn)行時(shí)去解析Jenkinsfile時(shí)也是需要很長(zhǎng)時(shí)間的，背后的原因不言而喻。

因此我們實(shí)際試驗(yàn)發(fā)現(xiàn)：Jenkinsfile 與 代碼庫(kù)可分離！即可以將置于其他Gerrit庫(kù)路徑中Jenkinsfile對(duì)另外一個(gè)Gerrit庫(kù)的代碼做CI編排，原因在于要做CI編排的庫(kù)路徑是人為地配置在Jenkinsfile中的。

舉例來說明：

本項(xiàng)目VerifyCI的Jenkinsfile托管路徑位于：xxx.xxx.com.cn/XXXXX/xxxxx_lib_verifyci

從VerifyCI的屬性參數(shù)中可以看出，如下圖所示：

然后我們的代碼庫(kù)地址則是另外一個(gè)，其配置于Jenkinsfile之中：

env.GERRIT_SERVER_NAME ="XXXXX_VerifyCI"

env.GERRIT_SERVER_URL ="ssh://xxxxx_jenkins@gerrit.zte.com.cn:29418/"

env.GERRIT_PROJECT = env.GERRIT_PROJECT?:"XXXXX/tool"http:// 實(shí)際代碼庫(kù)地址

plll.set_default_properties("verifyci",[

gerrit:[

server:"${env.GERRIT_SERVER_NAME}",

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

]

]);

如此一來便實(shí)現(xiàn)了二者的分離。