持续集成 Pipeline 实践:将 Jenkinsfile 与项目分离

某某wang · October 13, 2019 · Last by Rick replied at October 18, 2019 · 1012 hits

背景

众所周知,配置pipeline需要在项目中配置一个Jenkinsfile文件,存放pipeline脚本(不考虑job中直接写脚本的方式,维护起来太繁琐)。

我猜这个设计的初衷应该是让开发人员能自己维护Jenkinsfile,但是对于多数互联网公司而言,这个环节一般是qa团队在维护。当Jenkinsfile散落在多个项目中时,维护起来也是一件麻烦事。有没有办法将Jenkinsfile都集中管理起来呢?

前段时间在知乎上看到一篇技术专栏,作者@pulord借助pipeline-multibranch-defaults插件巧妙的实现了Jenkinsfile和项目代码的分离。兴奋之余,赶紧尝试了一番,也在项目中实践了起来。在此分享一下使用过程和踩坑记录。

插件介绍--pipeline-multibranch-defaults

workflow-multibranch插件是一个能扫描项目分支、自动生成分支流水线job的插件,使用起来十分便利。

pipeline-multibranch-defaults插件正是由它修改而来,该插件作者在workflow-multibranch插件的基础上增加了Default Jenkinfile的功能。

简单来说,该插件除了能自动创建多分支的job以外,还能给这些job指定一个默认的Jenkinsfile,该Jenkinsfile可以配置在Jenkins中,无需在项目代码中配置。

1.插件详细介绍(原作者)2.插件地址(Jenkins官方库)

将Jenkinsfile与项目分离

@pulord使用的方法比较巧妙,详细过程可以参看原文👉:Jenkins-Pipeline实践浅谈

大致流程如下:

0. 安装插件:pipeline-multibranch-defaults

1. 将不同项目、不同分支的Jenkinfile统一放置在一起,成为一个git项目。

按照以下目录结构存放Jenkinsfile:

#例:

--项目名称1
-分支1
-Jenkinsfile
-分支2
-Jenkinsfile

--app_server
-master
-Jenkinsfile
-dev
-Jenkinsfile

# 备注:Jenkinsfile中就是各个项目/分支真正的流水线脚本,比如一个完整的声明式pipeline

2. 在Jenkins系统管理中的Managed files中新建一个groovy脚本,作为默认的Jenkinsfile。

脚本内容如下:

#!/usr/bin/env groovy
import groovy.transform.Field

@Field def job_name=""

node()
{
// 获取当前job名称。也可以按需自定义
job_name="${env.JOB_NAME}".replace('%2F', '/').split('/')
job_name=job_name[0]

// 自定义workspace
workspace="/data/jenkins/workspace/CI"

ws("$workspace")
{
dir("pipeline")
{
// clone Jenkinsfile项目
git url: 'git@XXYY.com:pipeline.git'

// 根据job name、构建分支,自动加载对应的Jenkinsfile
def check_groovy_file="${job_name}/${env.BRANCH_NAME}/Jenkinsfile"
load "${check_groovy_file}"
}
}
}

// 该脚本的作用:clone包含所有Jenkinsfile的代码库,根据项目名称load对应的Jenkinsfile.
// 与原作者有一点出入,我没有在自己的Jenkinsfile中定义start()函数,所以此处删去了调用。load之后便会自动执行pipeline脚本。个人猜测,原作者的Jenkinsfile采用脚本化语法

3. 新建Multibranch pipeline job,job名称保持和步骤1中的"项目名称"一致。 Build Configuration 中选择by default Jenkinsfile,输入步骤2中的script ID。

4. Done!👏👏👏

避坑

1. Multibranch job自定义构建的分支

使用该插件部署的job,默认会为所有分支创建单独的job。如果分支过多简直是噩梦...

想要指定构建的分支也很简单,只需在 “行为”配置项中新增一个“根据名称过滤”,然后写正则表达式即可。

2. Jenkinsfile中load自定义函数

作者的举例中有自定义一个common_util.grroovy函数库。在Jenkinsfile中使用该函数库时,不能以它们的真实路径load。

因为Jenkinsfile已经被Default-Jenkinsfile加载到了项目根目录,所以应该以项目根目录为起点,再去load common_util.groovy

3. 快速校验pipeline语法

编写声明式脚本时,总会遇到一些语法问题(官方文档也烂)。为了快速调试语法规范性,可以借助一款vscode插件---Jenkins Pipeline Linter Connector,实现一键校验脚本语法。

Jenkins官网有提及,详细使用可以参看插件作者介绍:插件地址

该插件的工作原理就是利用Jenkins的接口校验脚本的语法规范性。

4. 调试技巧

由于Jenkins服务器不在本地,每次调试都要先push代码,再执行job。不仅效率低,还会导致一些垃圾commit。

为了省事,换了一种思路:

就是用docker在本地搭一个Jenkins环境(当然,如果Jenkins环境就在本地再好不过了。在此顺便夸一下docker的便利性🙂),然后把Default Jenkinsfile中clone pipeline操作注释掉,直接在workspace目录下修改脚本,这样就省去了commit步骤。

(虽然方法粗暴,可是当时的瓜脑袋一直没想到,直到push了30多次才反应过来...)

5. 配置webhook

使用Generic Webhook Trigger插件即可。

不过关于它的使用,估计又能写一篇....🤦

参考

  1. Jenkins-Pipeline实践浅谈
  2. Jenkins官方文档
共收到 7 条回复 时间 点赞

没有代码权限,那白盒测试怎么做的?还有code review和代码规范检查这些怎么做?
我感觉只有传统公司对代码管理会这么严格吧,比如政府和银行这些,互联网公司反而比较开放。

开发测试,如果泾渭分明,也难以密切合作。当然,文章中提到的也确实解决了一些问题。
另外,补充下,建议文章作者给出 Jenkins 官方仓库的地址,https://github.com/jenkinsci/pipeline-multibranch-defaults-plugin

对公司来说代码不应该安全级别高,生产环境的数据才是应该保护好的

arrow 回复

其实我司的业务代码是可以给qa权限的,但是一般仅限于查看,不让随便提交。和公司性质无关,只是缺少相应的代码规范制度,毕竟公司还在发展初期。
我个人只是试验性质的尝试pipeline,所以权限问题不是关键,主要是提供了一个思路。除了能解决权限问题以外,还能方便集中管理Jenkinsfile,也是一个优点。

再次,建议文章作者给出 Jenkins 官方仓库的地址,https://github.com/jenkinsci/pipeline-multibranch-defaults-plugin

Rick 回复

嗯,感谢建议,已经标明。为了尊重插件作者,我贴的原作者地址,jenkins官方也只是fork了一下,并且原作者介绍的更详细。

某某wang 回复

从社区的流程来说,只会发布 jenkinsci 这个 org 下面的插件,另外,从这个页面 https://github.com/jenkinsci/pipeline-multibranch-defaults-plugin/graphs/contributors 中也能看到有哪些贡献者。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up