点击上方“中兴开发者社区”,关注我们
每天读一篇一线开发者原创好文
DevOps案例旨在帮助用户在实践中更好的运用DevOps。
问题描述
Jenkins2.0 Pipeline框架iPipeline(即plll库)对MergeCI的触发条件的设置为Change merged模式且固定不变,即需要由代码走查者+2分后,再由Core成员点击Submit按钮来将代码推入库,然后才来触发MergeCI流程,该过程的VerifyCI和MergeCI流程如下图所示:
结合上图我们可以发现,这里有个问题是: 一旦代码走查通过(+2分),然后Core成员通过(Submit)后,代码立即入库,然后触发MergeCI流程,此时若MergeCI运行出错,那错误此时已经入库并且影响后续开发人员合入代码。
再结合本项目协议开发自身的实际特点,很有可能VerifyCI通过后的MergeCI会和他人产生互相影响,这样便可能导致主干分支代码有错,开发人员之间互相影响,最终影响代码提交合入的效率。
基于此种情况,我们提出的一种模式是,MergeCI由代码审查人员在Gerrit上打出+2分来触发,只有到MergeCI运行通过,代码才会被推入库中,此种方式带来的一个最直接的好处就是主干分支上的代码永远正确的,而且不会因为MergeCI报错而影响他人合代码,而且该方法带来的另外一个好处便是无需设定关键角色来负责Submit代码入库,仅仅需要的是代码走查人员即可,这样也提高了自动化程度,节省人力。将该流程可以示意如下图:
因此plll库的这种MergeCI的设置方式并不满足本项目,因此我们决定扩充plll库对于MergeCI运行模式的支持。
优化实践
通过重载了plll库的属性设置函数,加入了根据CI类型来完成MergeCI不同触发条件的设置:
/**
* 工具名称:set_default_properties
* 工具描述:设置默认的参数
* 参数说明:
* - citype : CI类型
* - args : 参数列表
**/
def set_default_properties(citype, args) {
def buildParameters = []
def buildTriggers = []