Pipeline改造过程中的几点主要经验分享

概述

经过前面三篇文章的详细介绍，讲述了本项目在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://[e-mail]:29418/"

env.GERRIT_PROJECT = env.GERRIT_PROJECT?:"XXXXX/tool"// 实际代码库地址

plll.set_default_properties("verifyci",[

gerrit:[

server:"${env.GERRIT_SERVER_NAME}",

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

]

]);

如此一来便实现了二者的分离。