准时下班的秘密：集成 GitLab && JIRA 实现自动化工做流

佛罗伦萨 - 圣母百花圣殿（图）

前言

GitLab 和 Jira 是平时开发过程当中使用很是高频的代码管理系统（开发人员）和项目管理系统（项目管理），经过两套系统的协做完成日常大多数的功能开发，可是两套系统在没有集成状况下是彻底两套独立的系统，不只信息没有互通，并且开发人员须要反复的登录两套不一样的系统，进行一些重复的操做才能保证功能流的正常流转，不只效率低下，浪费时间和人力，并且由于人自己的不可靠属性，因此致使状态的流转并不能很是的及时和准确，这种重复和机械的动做偏偏是自动化所擅长的地方，今天我介绍一下如何集成 GitLab 和 Jira 的工做流，提升团队的开发体验，提高你们的开发效率，能够把腾出的精力和时间都放在更有价值的事情上

1. GitLab 如何开启 JIRA 的入口？
2. GitLab 如何打通 JIRA 的信息流？
3. GitLab 如何自动化 JIRA 的工做流（workflow）？
4. GitLab 如何批量触发 JIRA 的工做量 ？

GitLab 如何开启 JIRA 的入口？

GitLab 须要一个专属的 JIRA 帐号，而且拥有相应的权限，用于在 JIRA issues 添加注释和操做系统，具体如何在 JIRA 中建立和配置帐号这里就不介绍了，不熟悉的小伙伴能够直接看官方文档 Creating a username and password for Jira Server 的介绍

而后进入 GitLab 选择对应的 Project -> Setting ->Integrations -> Jira

GitLab JIRA 的配置页面：

配置也很是简单，这里我简要说明一下：

• Web url ：大家公司的 JIRA 访问地址
• Jira API URL：使用 JIRA cloud 填写的 api 地址，可选项，没有使用为空便可
• username or email：在上面建立 JIRA 的帐号
• password：在上面建立 JIRA 的密码
• Transition id(s)：这里比较关键，是自动化工做流的核心，有如下几点注意事项：
  1. 首先这里是指 GitLab commit or merge 动做关键字触发对应的 JIRA workflow ID（状态 ID，多个状态使用 , or ; 号分割）
  2. 限制：workflow id 必须是连续的状态，若是是有中间状态则会跳转失败
  3. 只会对 JIRA status: resolution = unresolved 的 issues 生效，就是说 GitLab 不会去触发 issue 状态为 close 或者为 done 的工做流

配置成功后会显示 JIRA active

而且在 project 主菜单的左侧增长 JIRA 的快捷入口，点击快捷跳转到配置好的 JIRA web url，如图：

Setting -> Integrations 显示：

到这里第一步，配置就完成了

GitLab 如何打通 JIRA 的信息流？

完成第一步配置，后续的信息流就简单的多了，可是功能强大，让使用在 GitLab JIRA 之间无缝切换，行云流水，具体有如下几种玩法：

首先是 JIRA issue 的映射，只要是 push 到远端仓库的 commit 会自动关联到 JIRA 对应的 issue 页面，点击便可访问，在项目下的 commit history 能够看到：

点击 TEST-220 则能够直接跳转到对应的。JIRA 详情：

在解决该 issue 的过程当中，全部的 commit log 也会被自动关联到 JIRA issue 的注释中，在 JIRA 系统中造成问题的解决历史和思路，方便复盘和回顾：

JIRA issue 的自动注释的格式规范：

USER mentioned this issue in RESOURCE_NAME of [PROJECT_NAME|LINK_TO_COMMENT]:
ENTITY_TITLE

更方便的是 issue 下面的自动 commit 注释，也是访问 GitLab 的超连接，点击进去能够查看到当次 commit 的修改详情，例如咱们点击这个 Commit - TEST-220 resolver a problem ... ，能够看到具体的代码改动项：

要享受以上的全部收益，只须要遵循一条简单的 commit 规范，既在项目配置 JIRA active 的状况下，在 commit 中代码 JIRA issue 编号便可，并且 commit 信息一旦被推送到 GitLab 远端分支，就会立刻被在对应 JIRA issue 下面增长 commit. 注释，能够说使用起来很是的方便，示例的 commit 以下：

git commit -am 'TEST-220 resolver a problem'

GitLab 如何自动化 JIRA 的工做流（workflow）？

这里应该算是集成中最实用，也比较复杂的功能，经过 GitLab 的 commit or merge 动做改变 JIRA issue 状态（根据咱们上面配置的 transition ID 来流转），自动触发状态流转的关键字有如下 3 个：

• Resolvers Issue-1
• Closes Issue-1
• Fixed Issue-1

固然触发工做流的动做也是有限制的，咱们先看官方文档的描述：

Notes:

• Only commits and merges into the project’s default branch (usually master) will close an issue in Jira. You can change your projects default branch under project settings.

• The Jira issue will not be transitioned if it has a resolution.

我在这里简单转述一下：

1. 只有默认分支（master 能够在 GitLab -> Settings 中配置）的 commit and merge 会触发关闭 JIRA issue
2. 已有解决方案的 JIRA issue 则不会发生状态流转（就是我以前说的：只会对 JIRA.issue.status.resolution = unresolved 的 issues 生效）

咱们目前的痛点是：

每次需求上线后，都开发人员在 JIRA 里面点 On Line 来肯定功能已经发布，可是此时 On Line 状态的需求一般不挂在开发人员身上，开发人员每次需求上线后须要作如下操做：

1. 登录 Jira 系统，输入帐号密码
2. 找到项目，经过需求编号，找到对应已经上线的需求
3. 在状态项点击 On Line 按钮，改变 JIRA issue 的状态

以上操做虽然不复杂，可是每个需求上线都须要作一次重复的操做，有时候版本功能多，全部任务都须要逐个搜索出来手动更改状态，不只效率不高，并且容易遗忘，尽管项目负责人常常反复提醒，依旧没法避免人工操做不及时的问题，最终致使 JIRA 统计 LeadTime 流程被拉长，因此这是急需自动化的痛点

介绍到这里差很少了，咱们来看看如何经过自动化的 workflow 简化咱们的开发环节：（这里仅仅表明咱们团队的工做流，并不适用于大部分的场景）

首先这里能够看到这个 issue 任务已经完成，处于等待上线的状态（done） ：

开发人员只需在 GitLab 将对应的 TEST-225 分支提交 merge request，这里能够看到 GitLab 很智能的在 merge 描述中加入的触发 JIRA issue 的关键字，merge request 生效后，对应的工做流也自动触发了（状态为 unresolved），如图：

能够直接点击描述的 issue 跳到 JIRA 系统查看

GitLab 如何批量触发 JIRA 的工做量 ？

以上仅仅是对单个 Feature 的提交合并触发工做流，可是平常开发中这种场景比较少，不少 Feature 一般都是批量发布和上线，以咱们目前的项目为例，咱们目前最大的痛点是 Feature 上线后能够自动触发 Jira 的 On Line workflow，若是能够经过在 Release 合并进 Master 批量触发工做流将能够大大的简化咱们目前的工做，提升效率。

在 GitLab 中有两种方式能够实现批量触发工做流，两种实现方式不一样，但各有利弊：

• Release 分支经过 Merge Request 的 Description 批量添加 Closes issue id 实现
• Feature 分支经过本地 commit -m 'Closes issue id' 而后合并到默认分支实现（master）

Release 分支经过 Merge Request 的 Description 批量添加 Closes issue id 实现

这种操做实现起来对项目经理和负责人要求会高一些，须要事先整理和汇总全部要上线的分支和对应的 issue ，而后 GitLab 会在 Release -> Master 节点的时候经过 Merge 的时候自动触发 Jira 的工做流，那咱们就须要在 Release 进行 Merge Request 的时候在合并描述 Description 添加触发关键字 Closes Issue 便可，具体如图所示：

在负责人点击 Merge 对应的 issue 就会自动触发 Jira 工做流，流转对应的状态

Feature 分支经过本地 commit -m 'Closes issue id' 而后合并到默认分支实现（master）

这种操做实现起来对开发人员要求会高一些，要求开发人员遵循规范，在完成 Feature 分支功能开发后，按照规范提交 commit 关键字来触发工做流，具体以下：

git checkout phoenix/feature/TEST-223
git commit -m 'Closes TEST-223'

这种方式的好处是项目负责人不须要提早收集和整理 issue，也不须要在 Release 进行 Merge Request 的时候在合并描述 Description 添加触发关键字，直接提交 Release 分支合并便可，具体以下：

它的工做原理是 GitLab 会自动在 Feature 分支的 commit log 找到触发关键字而后执行自动化工做流，点击 Merge 后经过 issue 连接跳转过去就会发现 Jira 的状态已经更新，很是方便，虽然两种方式最终实现的效果都是同样的，可是我我的比较推荐使用第二种方式，比较方便不说，并且能够培养开发人员的规范意识也是比较好的

总结

到这里集成工做就基本完成了，自从 GitLab 集成 JIRA 后开发团队的效率和幸福感大增，今后过上了幸福的生活，距离走上人生的巅峰也不远了………………

PS：这里只是进行了简单的集成，若是你们发现更好的功能，能够分享出来交流和讨论

参考资料：

• GitLab Jira integration