概述

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

經驗分享

XXX項目遷移到Pipeline已經有一段時間了，期間不斷重構，不斷改進和演化，本文準備在此給出幾條本項目Pipeline改造過程中的幾點主要經驗分享。

1. 建議項目打造分層模式的Pipeline流程

本項目啟用CI分層策略，打造了4個層次的CI流程，分別為：

VerifyCI

MergeCI

DailyCI

TagCI

其中VerifyCI和MergeCI用于開發人員平時合代碼、DailyCI對應每日構建，而TagCI則用于版本構建，各司其職，層次分明。

具體如下圖所示：

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

不同Pipeline之間可并行Jenkins已天然支持，而利用iPipeline則能支持同一個Pipeline的不同任務之間的并行，而再具體到某個任務內則設計者應根據各自項目實際情況，盡量將任務內各步驟設計成并行模式。本項目對VerifyCI任務內的各步驟運行規劃如下，能并行的步驟盡量并行執行：

3. 關于MergeCI的運行模式與流程的摸索

該部分可以參考：-Jenkins2.0 Pipeline框架（iPipeline）優化實踐之路（三：MergeCI機制研究）

4. 關于Jenkinsfile托管方式的小技巧

雖然說一般要求將Jenkinsfile與所在代碼庫的代碼放在一起托管，即將Jenkinsfile置于代碼庫根目錄，但我們在實際實踐中發現一個問題是，一旦代碼庫比較龐大，每次Pipeline運行時去解析Jenkinsfile時也是需要很長時間的，背后的原因不言而喻。

因此我們實際試驗發現：Jenkinsfile 與 代碼庫可分離！即可以將置于其他Gerrit庫路徑中Jenkinsfile對另外一個Gerrit庫的代碼做CI編排，原因在于要做CI編排的庫路徑是人為地配置在Jenkinsfile中的。

舉例來說明：

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

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

然后我們的代碼庫地址則是另外一個，其配置于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:// 實際代碼庫地址

plll.set_default_properties("verifyci",[

gerrit:[

server:"${env.GERRIT_SERVER_NAME}",

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

]

]);

如此一來便實現了二者的分離。