2020 年上半年，Atlassian 在 Jira Cloud 上推出了一个非常不错的新功能 Jira Automation，将强大的无代码自动化功能带入 Jira Cloud 原生功能中，不用安装额外的插件，就可以非常方便的实现如下能力：
-
协助团队在不用编码的情况下，将很多重复且乏味的工作自动化，帮助团队专注在价值更高的工作上；
-
在多团队、多工具的情况下，流程会因为每个人对于执行细则和工具使用的理解不一样而变得混乱。自动化可以帮助团队标准化的梳理和组织各种活动，而 Jira Automation 为其提供了高效而低成本的实现方式；
-
通过 Jira Automation 可以非常方便的集成工作中使用的 IM 工具，极大降低信息同步成本，提高效率；
-
通过 Jira Automation 可以帮助团队更加系统的进行编码到产出的 Devops 实践。
作为 Jira Cloud 的用户，我们尝试在工作中逐步引入 Jira Automation，进行了一些探索和实践，这篇文章梳理和总结了这过程中的一些经验和心得和大家进行分享。
功能介绍
管理页面及入口
Jira Automation 的管理界面比较简洁，管理界面的规则页面，按照规则类型：全部规则、全局规则、项目规则对所有自动化规则进行了分类，用户可以自定义标签进行规则过滤。列表的每个条目展示了规则名称、拥有者、项目名称，开闭状态开关。单条规则可以进行复制、移出和导出操作。
其入口有两处：
-
每个项目的项目管理侧边栏中有 Jira Automation 的入口，可以直接进入该项目的管理界面，看到属于该项目，以及拥有者为当前用户的规则列表。
-
在系统设置的“System”页面侧边栏有另外一个入口，需要有系统管理员权限才能访问而，进入后可以看到所有的规则。
管理页面的右上角有“创建规则”按钮，旁边的“...”菜单中有“性能洞察”可以看到每条规则的执行次数，总时长和平均时长以及执行结果的数据。菜单的其它功能基本都是常规操作，这里不再赘述。
管理页面中还提供了“审计日志（Audit Log）”以及“模板库（Library）”。审计日志可以看到每次规则执行的详细信息，模板库提供了一些常规的规则模板。
规则创建
规则详情
创建规则功能中可以配置规则的详细信息以及规则的过程定义。在规则详情中除了通用的规则名称、描述外，还可以进行如下定义：
-
规则的使用范围：是单个项目适用还是多项目共用；
-
允许其它规则触发；
-
错误通知的方式；
-
规则的拥有者；
-
规则的执行者。
规则过程定义
上述规则详情定义好以后就是 Jira Automation 功能的重头戏规则的过程定义了。Jira Automation 将规则抽象成了四类组件：
-
触发器组件（trigger）
-
条件判断组件（condition）
-
执行组件（action）
-
分支组件（branch）
触发器（trigger）
每次创建自动化规则，第一个需要定义的就是触发器组件，该组件作为规则的输入，规则中的后续判断和执行均依赖这个组件进行触发。Jira Automation 将触发器组件分成了四类：
- 事务触发器：
这类触发器是目前我们会频繁使用到的触发器，这类触发器可以定义 Jira 中项目（Project）、迭代（Sprint）、版本（Version）、事务（Issue）的各种变化作为触发条件。是内容最为丰富的一类触发器，基本上覆盖了 Jira 上与事务相关的所有使用场景。
- DevOps 触发器
这类触发器是用于代码、分支、构建、发布过程作为触发条件的触发器，需要这几类工具和 Jira 系统进行集成才能更好的使用。目前对这类触发器的使用我们在进行探索。
- Integrations 触发器
这是一个很有意思的触发器类型，定义这类触发器的时候 Jira 会生成一个 Webhook URL 用于接收其它系统发出的 webhook 请求，并可以接受 issue key 作为请求参数或者请求 body，或是触发一条 JQL 查询，或是不带任何数据的请求，用于触发后续规则。
- Scheduled 触发器
这是一个自定及计划安排的触发器，用于指定时间和指定周期触发后续规则，同事也支持 CRON 表达式的高级定义。
条件判断组件（Condition）
条件判断是当规则定义的触发条件触发后，用于判断后续规则如何执行的组件，Jira Automation 的条件判断相对比较简单，而且只能进行很简单的嵌套，但得益于 JQL 的强大过滤能力以及 Smart Values（下文会介绍）的灵活性，基本能们组绝大部分使用场景，下面挑选经常使用到的几项进行介绍：
- Advanced compare condition
用于比较两个值的条件判断，支持等于、包含、大小等基本逻辑，也可以使用正则表达式匹配进行判断，条件为真则继续执行后续规则。
- If / else block
基本的 if else 判断，下面可以在嵌套一层除 If / else block 之外的条件判断组件，并可以多个条件组成与的关系。满足分支条件则继续执行后续规则。
- Issue fields condition
用于判断事务的字段是否符合条件的组件，支持等于或包含逻辑，同时可以比较当前事务与触发事务、父事务、史诗事务、目标事务等关联事务的字段。
- JQL condition
Jira 传统艺能 JQL 的条件过滤，过滤出来的数据会进入后续规则的执行。和传统 JQL 不太一样的是，这里可以使用 smart-values，强强联合。
执行组件（Action）
这类组件没有什么特别的基本上就是 Jira 功能操作了，分成了四类：
- Issue actions
Jira 事务的增删改查操作基本上都在这里。
- Notifications
用于进行通知的功能都在这里，我们目前常用的主要是 Send email 和 Send web request。
这里需要重点介绍一下的是 Send web request 功能。该功能可以自定义一个 http 请求，包括 header 和 body，并且可以把请求的 response 保存到 samrt-values 变量中，用于后续的规则执行。目前我们基本上都是通过这个功能集成办公 IM 的机器人，用于 Jira 上信息的同步。
- Jira Service Management
Service desk 的一些操作，我们没有用，就不介绍了。
- Software
Jira 上关于版本的操作，可以创建、发布、取消发布 Jira 项目中定义的版本，版本名称可以使用正则表达式进行匹配。
- Advanced
这部分是 Jira Automation 特有的能力，其中 Look issues，可以获得 JQL 过滤出来的事务数据，Create variable 可以给 smart value 自定义一个名称。
分支组件（Branch）
使用分支组件可以将规则中一部分事务数据分离出来单独进行处理，而不会收到其他规则部分的影响。
- Advanced branching
单独处理事务数据中某个 smart value 对象。可以给指定的 smart value 对象定义别名用于后续规则的处理。
- Branch rule / related issues
在 Jira 中事务经常是相关联的，通过这个功能可以筛选出指定关联的事务用于后续规则的处理。
Smart Values
Smart Values 是配合 Jira Automation 使用的又一强大特性，使用 smart values 可以在 automation 中非常方便的访问和操作 Jira 事务的数据。你甚至可以在 automation 的 web request 请求体中使用 smart values，可以把你想要的数据通过 web 请求发送给第三方系统，实现数据同步。
-
可以访问和操作几乎所有的 Jira 事务数据，包括：Issue、Changelog、Commit、User、Sprint、Version 等，以及 Jira Automation 自定义的一些数据，如：lookupIssue、webhookResponse 等。下面例举官方文档中给出的示例，如果对 jira restful api 比较了解的，看到这些内容应该很熟悉，和 restful 中的定义基本保持一致。
-
返回事务中的描述字段 {{issue.description}}
-
返回事务的 key {{issue.key}}
-
返回事务的当前状态数据 {{issue.status}}
-
-
支持列表操作，包括：遍历、索引取值、求和平均等。
-
返回子任务的平均故事点数 {{issue.subtasks.Story Points.average}}
-
遍历事务的修复版本，并用“ - ”连接 {{issue.fixVersions.name.join(" - ")}}
-
遍历事务的修复版本，打印版本名称和发布日期，使用“，”号分隔 {{#issue.fixVersions}}{{name}} {{releaseDate}}, {{/}}
-
-
字符串操作，包括：大小写和数字的转换、拼接，正则表达式匹配，html、json、xml、url 的 encode 操作等。
-
字符串比对 {{issue.summary.equals(“hello world!”)}} -> false
-
字符串正则表达式匹配 {{issue.summary.match(".(lo).")}} -> lo {{issue.summary.match(".(o).")}} -> [o, o]
-
字符串替换 {{issue.summary.replace("Hello","Goodbye")}} -> Goodbye World!
-
smart values 非常灵活，想进一步了解的可以参考官方 smart values 帮助文档。
实践案例
经过一段时间的探索，我们在 Jira Automation 上也积累了一些实践，这里以定时任务、任务模板、版本跨项目同步、版本信息同步第三方工具为例子和大家进行一下案例分享。
Jira 及 Confluence 备份
在 Jira Automation 发布前，Jira 和 Confluence 的定期备份需要管理员在产品中手动进行，当然也可以通过脚本调用接口自动进行备份，但是需要一个服务器来稳定的执行脚本。Jira Automation 提供了非常方便低成本的解决方式。
- 设置 Scheduled 触发器
这里我们使用 cron 表达式定义备份计划，每周三 12 点（系统提示这里是 UTC 时间，也就是 CTS 20 点）进行触发备份任务。
2. 设置 Action
在这个规则中我们设置了两个 action，一个通过 send web request 调用 Jira 和 Confluence 的备份接口，另一个接受备份接口返回的 response，记录在审计日志中，用于检查跟踪备份的执行结果。
(1)Action 1: Send web request
在 request 中填上接口要求的 header 数据和 post body 数据就可以了，这里需要注意的是，Action 2 的执行需要勾选上 wait for response 选项，这样 response 会保存在 {{webhookResponse}} 的 smart value 中，用于后续步骤的执行。
(2)Action 2: Add value to the audit log
上一步设置好后，只需要将{{webhookResponse}} 填入 log message 中就可以了。
规则执行后就可以在规则的审计日志中看到每次执行的情况以及，接口返回的结果。
创建 Epic 时自动创建其子任务
在没有 Jira Automation 之前，如果不安装额外插件基本上没有办法在创建史诗任务时创建一些配套的子任务，从而形成一个史诗任务的模板。Jira Automation 只需要简单的几步操作就能解决这个问题。
1. 设置触发器
使用 Issue created 组件作为触发器，该触发器不需要额外的设置，只要有事务被创建就会触发。
2. 过滤出我们需要的事务类型
在触发器被触发后我们只需要过滤出我们需要的事务就可以了，条件判断的设置也非常简单，Issue Type 等于 Epic 就可以了。
3. 创建子任务
接下来只需要使用创建事务组件创建子任务就可以了。
创建子任务时会有一些特殊的设置：
-
Epic Link 需要设置为 Trigger issue，这样任务才会关联到条件判断过滤出来 Epic 下。
-
事务摘要中需要使用 {{triggerIssue}} 标记是哪个 Epic 的子任务，不然所有 Epic 下的任务会同名，不太容易区分出来。
同步开发发布的版本到实施侧的项目
在私有化部署产品开发过程中，迭代发布的版本不一定都会给客户进行部署。同时开发和实施的任务分别在两个 Jira 项目中进行管理，迭代发布版本在开发项目中进行管理，客户侧的版本升级需求在实施项目中进行管理，所以需要将客户侧可升级的版本发布从开发项目同步到实施项目中。Jira Automation 可以好的避免版本同步的延迟和人工同步时可能产生的错误操作。
1. 设置触发器
这里我们使用 Version released 作为触发器，使用正则表达式过滤掉不符合版本命名规范的发布版本。
在设置完触发器后，我们想在审计日志中记录一下发布的版本名称，方便后续问题排查。因此设置了一个添加审计日志的 action，记录 {{version.name}} 这个 smart value。
2. 设置条件判断组件
由于我们只希望同步指定开发项目中发布的版本到实施项目中，因此这里我们使用 {{version.project.key}} 进行了正则匹配过滤，只接受 PI 和 HZPI 两个项目发布的版本数据。
3. 后续创建和发布版本的执行
经过上面两部后就过滤出了我们需要的版本数据，接下来只要执行创建和发布版本的过程就可以达到目的了。这里以发布版本为例，创建版本操作一样，只需要把执行组件由发布版本改为创建版本即可。
同步版本中修复的 bug 到 IM 工作群
版本发布后实施部门的项目经理或者客户成功经理想快速了解当前发布的版本中修复能哪些 bug。以前我们都是通过在 Confluence 上发布 release notes 文档的方式进行信息同步，但是文档同步时效性比较差，而且项目经理或者客户成功经理在客户现场时访问 Confluence 也不太方便。Jira Automation 很好的解决了这个问题，将信息直接同步到 IM 工作群，项目经理或者客户成功经理可以及时方便的看到这些信息，从而提高了信息的触达率和沟通效率。
1. 设置触发器
和上面的案例一样，我们还是使用 Version released 组件，使用正则表达式过滤出我们需要发送的版本。
2. 过滤出需要同步的 Bug
接着我们需要过滤出对应版本中修复的 bug，这里我们使用 Looup issues 组件，在这个组件中我们使用 JQL 过滤出这些 bug，并保存到 {{loopupIssues}} 这个 smart value 中用于后续规则执行时调用。
3. 发送 Bug 数据到 IM 工作群
最后我们只需将数据按照 IM 指定的格式发送到 IM 服务接口就可以了。
这里有一个非常有意思的能力，在 web request 的 post body 中，我们可以利用 smart values 提供的列表能力嵌套在 json 数据中，发送 request 时，Jira Automation 会自动渲染出数据并完成发送，从而实现多个 bug 的数据在一个 IM 消息中发送，而不用发送多条 IM 消息污染群信息。
{
"msg_type": "post",
"content": {
"post": {
"zh_cn": {
"title": "{{version.name}} 发布，修复 bug 清单",
"content": [
{{#lookupIssues}}{{^last}}
[{
"tag": "a",
"href": "{{url}}",
"text": "{{key}}"
},
{
"tag": "text",
"text": "：{{summary}}"
},
{
"tag": "text",
"text": " @{{reporter.displayName}}"
}],
{{/}}{{/}}
// 此处是渲染 json 数据时最后一条记录没有结尾逗号的处理
{{#lookupIssues}}{{#last}}
[{
"tag": "a",
"href": "{{url}}",
"text": "{{key}}"
},
{
"tag": "text",
"text": "：{{summary}}"
},
{
"tag": "text",
"text": " @{{reporter.displayName}}"
}]
{{/}}{{/}}
]
}
}
}
}
最后 IM 工作群中看到的效果如下，项目经理或者客户成功经理如果想进一步了解 bug 修复的具体情况，可以直接点击链接打开查看：
总结
总结下来，Jira Automation 是一个操作简单但是功能强大的自动化工具，它能把 Jira 上很多需要重复人工劳动的工作以组件拖拽配置的方式进行自动化，极大降低了自动化的门槛。当然除了产品功能值得称赞之外，该款产品的设计思路和抽象逻辑也非常值得我们学习。
