背景
公司现在有一套Jenkins流水线，每次构建的时候需要手动触发。对于发版频率比较低的生产和预发环境，手动构建问题不大，对于发版频率比较高的dev和test环境，采用手动构建的话，效率偏低。因此决定对现有的Jenkins流水线进行改造,使其支持开发和测试环境的自动构建部署功能。那要怎么做呢?
第一步 配置Jenkins
1.登录Jenkins,新建一个流水线任务
2. 找到通用==>Triggers菜单
勾选 Build when a change is pushed to GitLab，这时会显示一个Webhook消息地址，把这个Jenkins服务器地址填写到GitLab的Webhooks中的事件推送服务器地址那里,Jenkins就能接收到Gitlab推送过来的各种代码仓库操作事件。 接着选择接受的事件类型，一般只监听 Push Events(推送代码) 和 Accepted Merge Request Events(合并代码请求通过)事件
点击高级按钮，会弹出下拉配置面板，有两项需要配置一下，一个是对推送过来的事件按分支进行过滤，无论是什么事件。这点Jenkins比Gitlab做的精细，Gitlab不支持对合并事件按分支进行过滤。
另一个是生成访问凭据，点击Generate按钮，就能生成访问凭据。访问凭据的用途是：推送的代码仓库事件网络请求携带此凭据，才进行处理。虽然生成访问凭据不是必须项。但一般为了防止Jenkins服务器被postman这类的工具攻击，都会生成访问凭据。
第二步 配置Gitlab webhooks
公司的在线代码仓库管理平台使用的工具是Gitlab，GitLab有个Webhooks的功能，可以将Git各个分支的代码推送，合并，评论等事件推送到设置的服务器地址。要想实现向dev或test分支提交代码，自动触发dev或test环境的自动构建部署功能，就要使用此功能。有人可能会问，为什么我登录Gitlab在线平台后，看不到Webhooks菜单。那是因为你的角色权限不够。角色和Webhooks菜单的可见关系见下图：
Webhooks菜单入口位于左侧导航栏设置菜单下
需要配置的地方有：
- 推送事件的url，这里填写上一步我们在Jenkins中看到的那个服务器地址。
- 加密令牌--Jenkins会对事件消息进行拦截，有令牌的消息才进行处理。填写上一步在Jenkins流水线中生成的访问凭据。
- 选择要推送的事件，可以看到GitLab的事件类型有许多，自动构建部署需要用到的事件是推送和合并请求事件，其中推送事件,可以设置根据分支名进行过滤；合并请求事件在GitLab不支持事件过滤功能，在Jenkins里面支持对合并事件进行过滤。
配置完之后，可以点击下方的测试按钮，选择需要触发的事件类型进行测试，下方如果出现一条状态是200的新推送记录，说明配置的没问题。如果出现403，多半是因为加密令牌没配对。
第三步 自动部署测试
经过前两步的配置，我们已经将GitLab和Jenkins打通，由于前面我们设置的是只监听dev分支的代码推送和合并请求通过事件，要测试自动部署构建功能的话，需要向在线的代码仓库的dev分支进行推送和代码合并操作，推送更方便一些，我们选择对项目下的ReadMe文件进行一次无关痛痒的修改，先在本地dev分支提交，而后推送到远程Gitlab dev分支，看部署流水线是否执行。可以看到，触发了执行。
不过这个信息面板显示的内容比较单调，如果能显示出部署采用的分支和提交的hash值，会更好一些。查了一下，Jenkins支持对信息面板内容进行定制，不过展示的信息行数有限，超过4行就会显示成省略号。对于想追加的信息而言，够用了。
具体做法是在流水线菜单下，选择Pipeline script类型，编辑配置在线Groove脚本，添加一个设置面板信息的阶段， 在阶段的步骤里，将向定制展示的信息赋值给currentBuild.description这个环境变量，面板的信息就会显示定制的信息。
配置的脚本如下：
groove
stage('SetPanelInfo') {
steps {
def starter = env.gitlabUserName ?: env.BUILD_USER
def shortSha = sh(script: 'git rev-parse --short HEAD', returnStdout: true).trim()
def branch = "${env.gitlabBranch ?: params.BranchName}-${shortSha}"
currentBuild.description = "自动部署: ${env.DEPLOY_ENV}, 分支: ${branch}, 启动者: ${starter}"
}
}效果如图：
最后
实际上，参与的实际项目的流水线配置，比这个复杂一些。业务要求是：
- 正常迭代开发，向
dev分支推送代码或合并请求通过时，自动构建dev环境 - 正常迭代开发，向
release/*分支推送代码或合并请求通过时，自动构建test环境 - 正常迭代开发，canary和prod环境支持手动部署，采用的是
release/*分支最后一次的构建产物 - 修复生产问题，hotfix分支合并master请求通过时，自动构建prod环境
- 每次构建时要运行代码质量检查，将Jenkins流水线，PR信息(合并的link，提交说明，发起者，审核者等)，代码质量检查统计结果发送到产研负责人的邮箱
以上功能，经过不懈努力，已经实现。如果你们的项目也要求实现上面的功能，可以讨论交流。