关于提交和合并流水线的实践

作者

泽阳，运维工程师，实际工作经验4-5年，经历了传统运维到自动化运维整个过程。整理分享DevOps、CICD、编程开发、监控、日志等相关技术实践！定期更新，来吧一起踏上技术的征途！整理的最新Jenkins实践文档 http://zeyangli.github.io

1 简介

今天干了点什么呢？干了件坏事~~ 嘿嘿嘿

• 实践Gitlab push 和Merge 流水线；

2 流水线触发场景

我们非常推荐以版本控制系统为源的构建流水线设计，从每一位开发人员提交代码即可对当前提交代码进行检查编译构建，尽快将错误反馈给每位提交人员。

提交流水线

• 提交即构建
• 编译单测打包代码质量检查
• 构建错误第一时间通知提交人

合并流水线

• codereview
• 配置分支保护
• 创建合并请求对将代码审查结果在评论区展现
• 由assignUser合并代码

3 提交流水线设计

我使用的方式是通过webhook触发jenkins构建，这样很灵活。相信很多人也是通过这种方式进行配置的。

首先配置Jenkins项目

• 使用generic webhook方式触发项目构建
• 配置构建触发器参数（获取gitlab返回的数据，比如分支、用户等信息）
• 配置构建触发器中的token（确保唯一，建议可以用项目名称）
• 配置触发器中的请求过滤（merge_request，opend）

其次是Gitlab的配置

• 项目-》集成-》新建webhook
• 填写webhook地址?token=projectName
• ☑️MergeRequest操作触发

剩下的就是编写Jenkinsfile了，下面列出几个关键点

1.获取gitlab数据中的分支名称，作为本次构建的分支名称。

2.获取gitlab数据中的用户邮箱，作为构建失败后通知对象。

4 合并流水线设计

关于合并流水线的步骤其实跟提交流水线很类似，但是在代码质量检查的步骤中严格要求检查质量阈的状态，当质量阈状态为错误的时候，需要立即失败并通知发起人。

第一次设计

• 开发人员创建MR并指定AssignUser。
• Jenkins开始对MR中的源分支进行编译构建打包代码检查。
• 构建成功（代码质量没问题）在MR页面评论提示信息。
• 构建失败在MR页面评论失败信息

第二次设计（借助GitlabCI）

• 项目配置当流水线成功时才能merge。
• 开发人员创建MR并指定AssignUser。
• Jenkins开始对MR中的源分支的最后一次commit状态改为running。
• 然后进行编译构建打包代码检查。
• 构建成功，更新最后一次commit的状态为 success。
• 构建失败，更新最后一次commit的状态为faild。

5 总结

流水线的实现方式各式各样，这只是实现方式的一种。可能你会有更好的想法，欢迎您回复。其实最后我把这两种流水线整合到了一个Jenkinsfile中了。因为提交和合并流水线太相似了，大部分步骤都是公用的。可以使用when语法对不通操作所要运行的步骤配置触发条件。