DevOps 案例 | Jenkins2.0 Pipeline框架（iPipeline）优化实践之路(四)

最新推荐文章于 2022-03-22 16:20:31 发布

中兴开发者社区

最新推荐文章于 2022-03-22 16:20:31 发布

阅读量528

点赞数

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

DevOps案例旨在帮助用户在实践中更好的运用DevOps。

经过前面三篇文章的详细介绍，讲述了本项目在Jenkins2.0 Pipeline实践和iPipeline框架（plll库）应用的过程中的一些思考、改进以及实践，而本文作为系列文章的最后一篇，主要想分享一下本项目在过去一段时间中对于Jenkins2.0 Pipeline改造的一些经验。

XXX项目迁移到Pipeline已经有一段时间了，期间不断重构，不断改进和演化，本文准备在此给出几条本项目Pipeline改造过程中的几点主要经验分享。

本项目启用CI分层策略，打造了4个层次的CI流程，分别为：

其中VerifyCI和MergeCI用于开发人员平时合代码、DailyCI对应每日构建，而TagCI则用于版本构建，各司其职，层次分明。

具体如下图所示：

640?wx_fmt=png

不同Pipeline之间可并行Jenkins已天然支持，而利用iPipeline则能支持同一个Pipeline的不同任务之间的并行，而再具体到某个任务内则设计者应根据各自项目实际情况，尽量将任务内各步骤设计成并行模式。本项目对VerifyCI任务内的各步骤运行规划如下，能并行的步骤尽量并行执行：

640?wx_fmt=png

虽然说一般要求将Jenkinsfile与所在代码库的代码放在一起托管，即将Jenkinsfile置于代码库根目录，但我们在实际实践中发现一个问题是，一旦代码库比较庞大，每次Pipeline运行时去解析Jenkinsfile时也是需要很长时间的，背后的原因不言而喻。

因此我们实际试验发现：Jenkinsfile 与代码库可分离！即可以将置于其他Gerrit库路径中Jenkinsfile对另外一个Gerrit库的代码做CI编排，原因在于要做CI编排的库路径是人为地配置在Jenkinsfile中的。

举例来说明：

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

从VerifyCI的属性参数中可以看出，如下图所示：

640?wx_fmt=png

然后我们的代码库地址则是另外一个，其配置于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" // 实际代码库地址
plll.set_default_properties("verifyci", [
gerrit:[
server:"${env.GERRIT_SERVER_NAME}",
projects:[[project:"${env.GERRIT_PROJECT}", branch:"${plll.getJobBaseName()}"]]
]
]);

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

拓展阅读

干货 | Jenkins2.0 Pipeline框架（iPipeline）优化实践之路（一）

640?wx_fmt=png

关注