JIRA自动化

Jira，作为功能强大的工具，为每个团队带来了效率和结构。Jira现有的自定义功能可以实现各种各样的可能，但如果我们想把效率再提升一步如何实现呢？
这就是我想给大家介绍的Jira自动化流程。自动化过程可以使工作更容易，减少工作量，让您和您的用户可以实现更多的可能性。
什么是Jira自动化？
Jira自动化是一种方法，使劳动密集型流程变得更有效率。它几乎消除了劳动密集型的过程，让用户更专注，而不是把时间花在不断点击或配置工具上。得益于它与强大的JQL结合，就让Jira自动化拥有了无数的可能性，你可以用它来灵活搜索数据。您也可以基于选择，管理单一的项目或多个的项目……包括权限。
有哪些自动化类型？
一般来说，有不少类型可实现自动化; 下面通过两个实际案例我会介绍Jira常用到的自动化类型；

• Jira Service Desk自动化（Jira Service Desk自带）
• Automation for Jira （插件）

第一个是Jira Service Desk 项目，后者将覆盖所有Jira项目类型。
用例#1：排在SLA队列前面 （Jira Service Desk）
在这种情况下，当SLA即将到期时我们会被提醒到，但仅适用于状态处于“开放”或“进行中”的问题。
我们必须定义三个步骤：“时间”，“如果”，“然后”。
所以我们做了这些：

当SLA只剩下30分钟，而且这个问题匹配某个JQL条件……然后提醒某个特定用户。
如果流程需要的话，您也可以定义其他有效的流程，“否则，如果”。利用自动化工具，你可以做很多。我相信，在大多数Jira环境，它会派上用场。这里很简单无需做太多配置就能排在特定SLA队列前面。很显然这只是众多可能性之一。还有一堆预先定义的规则可供使用。

欲了解更多关于Jira Service Desk自动化和它所有可能性，请访问自动化您的Jira Service Desk-文档
用例#2：基于“摘要”和自定义字段值自动设置“组件”和“问题类型” （Jira自动化）
Jira自动化具有更广泛的可能性，并延伸不仅仅是Service Desk。任何类型的Jira项目都可以使用。在这个用例中，我们将尝试一些更先进的方法。
我们收到邮件，并根据该邮件的内容，我们想自动在Jira里创建问题。根据“摘要”，以及基于我们存储了“收件邮件地址”的字段值，我们希望为工单创建特定“问题类型”和“组件”，使它能排列到项目正确的预先定义的队列里。

我们将定义下面的步骤：

“时间”，相关的问题“类型”，“如果”，“然后”。
每当创建一个“问题”，对于这些“问题”，检查特定的JQL条件。在这个案例里是“摘要”和“自定义字段”，然后再编辑“组件”/ “问题类型”。

这种类型的自动化是非常适合那些不仅仅用于Service Desk自动化，而是希望用到更高级的自动化方法。它不是Jira标配，是一个插件，但它能带来很多新的功能和可能性。

探索

“基本搜索”解答关键开发问题

在Jira Software Server 7.9 中，Jira Issue Navigator默认视图中增加了一列：“开发”（“Development”），可以查看Bitbucket Server指定信息，而无需点击进入单个问题。

提示：如果您在Jira Issue Navigator中使用自定义布局，可以在“列”下拉菜单中打开添加“开发”（“Development”）列。

查看过滤分组问题的高级快照（而不仅限于单个问题的信息）有助于发现趋势或问题。如果能在源头发现并它们，将会给DevOps中的开发流程带来真正的改变。

例如，我们可以问这样的问题：有多少开发问题正在审核？
搜索：开发>审核中
结果发现有一两名开发人员因大量合并请求而不堪重负，在整个开发流程中遇到瓶颈。此时，您可以立即评估是否需要重新分配工作。

使用JQL过滤开发信息

如果您需要知道更复杂或开放式问题的答案，该怎么办？您可能不知道该怎么做，但是，您可以使用JQL查询语言（JQL Query Language）根据开发信息创建搜索查询，发现关键信息，从而避免出现未解决问题。在Jira Software Server 7.9 中，我们更新了语法，以便和大家已经熟悉并喜欢的JQL 查询格式保持一致。
Jira Software高级用户已经有多年使用JQL的经验了，他们使用它来查看问题子集，生成报告，查看Scrum和看板面。现在，通过交叉引用开发工具中的数据，JQL变得更加强大。

以下是JQL的几个示例：
内部反馈和客户反馈对部署DevOps的团队至关重要。他们使用反馈信息来规划新产品特性，提高质量，对于最终用户来说也更有价值。但是，在决定首个版本是否可以发布时，这种对反馈的关注往往会造成紧张的气氛。

提问：有多少问题已完成但尚未部署，具体是哪些问题？
project = ABC AND statusCategory = Done AND development[deployments].all = 0
通过拉取已完成但尚未部署的问题及其数量，您可以确定是否可以发布，开始收集反馈，或者在发布之前是否存在需要解决的阻塞问题。
在上传部署之前，团队通常在本地测试构建。如果您的团队也属于这种情况，最好定期检查构建的状态。

提问：有多少问题构建失败，具体是哪些问题？
project = ABC AND development[builds].failing > 0
如果您看到很多失败的构建，这可能表示开发者的环境与构建和部署的环境不一致。这是一个您需要立即发现并修复的问题。而那些通过构建的问题集可能是因为测试人员可以检查验收标准并开始进行探索性测试。
避免产生不必要的孤岛的方法之一是，在目前拖慢团队的手动流程中增加自动化流程。

提问：有多少问题已完成但尚未合并的拉请求，具体是哪些问题？
project = ABC AND statusCategory = Done AND development[pullrequests].open > 0
如果您看到许多拉请求已完成但尚未合并，可能表示Jira中的问题未按开发工作进度在工作流程中进行迁移。这样情况会让团队对Jira中的信息产生怀疑，管理人员会不断询问“Jira中的信息是最新的吗？”。幸运的是，有一个简单的解决方法：您可以执行新的工作流程条件并在Jira Software中添加自动问题转换，无需开发者手动迁移问题。这对于管理者和开发者来说是双赢局面。