In the first half of 2020, Atlassian launched a very nice new feature on Jira Cloud, Jira Automation, which brings powerful code-free Automation to Jira Cloud native features without installing additional plug-ins, You can easily implement the following capabilities:

  • Help the team automate many repetitive and tedious tasks without coding, and help the team focus on higher-value work;

  • In a multi-team, multi-tool situation, the process can get messy because everyone has a different understanding of the execution details and tool usage. Jira Automation provides an efficient and low-cost way for teams to standardize organizing and organizing activities.

  • Jira Automation can easily integrate the IM tools used in the work, greatly reduce the cost of information synchronization, improve efficiency;

  • Jira Automation helps teams more systematically code into productive Devops practices.

As users of Jira Cloud, we have tried to gradually introduce Jira Automation into our work and conducted some explorations and practices. This article summarizes and summarizes some experiences and experiences in this process to share with you.

Function is introduced

Manage page and entry

The management interface of Jira Automation is relatively simple. The rule page of the management interface classiifies all Automation rules according to rule types: all rules, global rules and project rules. Users can customize labels for rule filtering. Each entry in the list shows the rule name, owner, item name, and on/off status switch. A single rule can be copied, removed, or exported.

Its entrance has two points:

  1. The project management sidebar for each project has a portal to Jira Automation, which leads directly to the project’s administration interface and a list of rules that belong to that project and are owned by the current user.

  2. In the “System” sidebar of the System Settings page, there is another entry, which requires System administrator permission to access and after entering, you can see all the rules.

In the upper right corner of the management page, the Create Rule button is displayed next to… In the menu, performance Insights allows you to see the number of times each rule was executed, the total and average duration, and the execution results. Other functions of the menu are basically routine operations and will not be described here.

The Audit Log and Template Library are also provided on the admin page. The audit log shows detailed information about each rule execution, and the template library provides some general rule templates.

Rule creation

The rules for details

The rule creation function allows you to configure the rule details and the process definition of the rule. In addition to the general rule name and description, you can also define the following rules:

  • The scope of application of the rule: is it applicable to a single project or shared by multiple projects;

  • Allow other rules to fire;

  • Method of error notification;

  • The owner of the rule;

  • An enforcer of rules.

Rule procedure definition

After the above rule details are defined, the process definition of the key rule of Jira Automation function is defined. Jira Automation abstracts rules into four categories of components:

  • Trigger component

  • Condition judgment Component (Condition)

  • Execution Component (Action)

  • Branch Component (Branch)

Trigger

Each time you create an automation rule, the first thing you need to define is the trigger component, which serves as the input to the rule and is used to trigger subsequent judgments and executions within the rule. Jira Automation divides trigger components into four categories:

  • Transaction trigger:

This type of trigger is one of the most frequently used triggers in Jira today. This type of trigger can define various changes to a Project, an iteration, a Sprint, a Version, or a transaction as the trigger condition. Triggers are the richest type of trigger, covering virtually all transaction-related usage scenarios on Jira.

  • The conversation trigger

These types of triggers are used for code, branch, build, and publish processes as trigger conditions, and need to be integrated with the Jira system for better use. The use of these triggers is currently being explored.

  • Integrations trigger

This is an interesting trigger type. When defining this type of trigger, Jira generates a Webhook URL to receive Webhook requests from other systems and can accept an issue key as a request parameter or request body, or trigger a JQL query. Or a request without any data that triggers subsequent rules.

  • Scheduled trigger

This is a custom and scheduled trigger that fires subsequent rules at specified times and intervals, and supports advanced definitions of CRON expressions.

Condition judgment Component (Condition)

Condition judgment is the component used to determine how the subsequent rule is executed after the trigger condition defined by the rule is triggered. Jira Automation’s condition judgment is relatively simple and can only be nested very simply. However, thanks to the powerful filtering capability of JQL and the flexibility of Smart Values (described below), Basic can group the vast majority of use scenarios, the following selected frequently used a few to introduce:

  • Advanced compare condition

It is used to compare two values. It supports basic logic such as equal, contain, and size. Regular expression matching can also be used to determine the value.

  • If / else block

Basic if else judgment, the following can be nested in a layer of if/else block in addition to the conditional judgment component, and can be multiple conditions and the relationship. If the branching condition is met, subsequent rules continue to be executed.

  • Issue fields condition

A component used to determine whether or not a field of a transaction meets a condition that supports equal or inclusion logic and compares the fields of the current transaction with those associated with triggering, parent, epic, target, and so on.

  • JQL condition

Jira traditional art JQL conditional filtering, filtered data will enter the implementation of subsequent rules. Unlike traditional JQL, smart-values can be used to combine strong forces.

Execution Component (Action)

There is nothing special about this class of components, which are basically Jira function operations, grouped into four categories:

  • Issue actions

The add, delete, change and check operations for Jira transactions are basically here.

  • Notifications

All the notification functions are here. Currently, we mainly use Send Email and Send Web Request.

This section focuses on the Send Web Request function. This feature allows you to customize an HTTP request, including header and body, and to save the response of the request to the samRt-values variable for subsequent rule execution. At present, we basically use this function to integrate office IM robots for information synchronization on Jira.

  • Jira Service Management

Some operations of the Service desk, which we do not use, will not be introduced.

  • Software

Versioning operations on Jira allow you to create, publish, and unpublish versions defined in Jira projects. Version names can be matched using regular expressions.

  • Advanced

This part is unique to Jira Automation. Look Issues can obtain transaction data filtered by JQL, and Create variable can define a name for Smart Value.

Branch Component (Branch)

The branch component allows you to separate part of a rule’s transaction data for processing without being affected by other rule parts.

  • Advanced branching

Process a smart Value object in transaction data separately. You can define aliases for the specified Smart Value object for subsequent rule processing.

  • Branch rule / related issues

Transactions are often associated in Jira, and this feature allows you to filter out transactions that are specifically associated for subsequent rule processing.

Smart Values

Smart Values is another powerful feature used with Jira Automation. Using Smart Values, you can easily access and manipulate the data of Jira transactions in Automation. You can even use Smart Values in the body of automation’s Web Request to send the data you want to third-party systems via web request for data synchronization.

  • You can access and manipulate almost all Jira transaction data, including: Issue, Changelog, Commit, User, Sprint, Version, etc., as well as some Jira Automation custom data, such as: LookupIssue, webhookResponse, etc. The following is an example provided in the official documentation. If you are familiar with jira restful apis, you should be familiar with these contents, which are basically consistent with restful definitions.

    • Returns the description field in the transaction

    {{issue.description}}

    • Returns the key of the transaction

    {{issue.key}}

    • Returns data about the current state of the transaction

    {{issue.status}}

  • Supports list operations, including traversal, index value, and sum average.

    • Returns the average story points of the subquest

    {{issue.subtasks.Story Points.average}}

    • Iterate over the fixed version of the transaction and connect with “-“

    {{issue.fixVersions.name.join(” – “)}}

    • Iterate over the fixed version of the transaction, printing the version name and release date, separated by commas (,)

    {{#issue.fixVersions}}{{name}} {{releaseDate}}, {{/}}

  • String operations, including: case and number conversion, splicing, regular expression matching, HTML, JSON, XML, URL encode operations.

    • String alignment

    {{shoots. The summary. The equals (” hello world!” )}} -> false

    • String regular expression matches

    {{issue.summary.match(“.(lo).“)}} -> lo {{issue.summary.match(“.(o).“)}} -> [o, o]

    • String substitution

    {{issue.summary.replace(“Hello”,”Goodbye”)}} -> Goodbye World!

Smart Values is very flexible. For more information, see the official Smart Values help document.

Practical cases

After a period of exploration, we have accumulated some practices in Jira Automation. Here, we will share the examples of scheduled tasks, task templates, cross-project synchronization and third-party tools for version information synchronization with you.

Jira and Confluence backup

Prior to Jira Automation, regular backups of Jira and Confluence had to be done manually by the administrator in the product. Backups could also be done automatically through the script call interface, but a server was required to execute the scripts steadily. Jira Automation offers a very convenient and low-cost solution.

  1. Set Scheduled triggers

Here we use the CRON expression to define the backup plan and trigger the backup every Wednesday at 12 o ‘clock (UTC time).

2. Set up the Action

In this rule, we set two actions. One calls Jira and Confluence backup interfaces through Send Web Request, and the other receives response from backup interfaces and records it in audit logs to check the execution results of tracking backup.

(1)Action 1: Send web request

Action 2: Wait for Response Action 2: Wait for Response The response is then stored in the Smart value of {{webhookResponse}} for subsequent steps.

(2)Action 2: Add value to the audit log

After setting up the previous step, just fill in {{webhookResponse}} in the log message.

After the rule is executed, you can view the execution status and the result returned by the interface in the audit log of the rule.

Subtasks are automatically created when Epic is created

Prior to Jira Automation, there was virtually no way to create a template for an epic task by creating a set of matching sub-tasks without installing additional plug-ins. Jira Automation solves this problem with a few simple steps.

1. Set the trigger

Use an Issue Created component as a trigger that does not require additional Settings and fires whenever a transaction is created.

2. Filter out the transaction types we need

After the trigger is triggered, we only need to filter out the transactions we need. The setting of condition judgment is also very simple, and the Issue Type is equal to Epic.

3. Create subtasks

The next step is to create the subtasks using the Create transaction component.

There are some special Settings for creating subtasks:

  • Epic Link needs to be set as Trigger Issue so that tasks will be associated with conditional judgment and filtered out under Epic.

  • Use the {{triggerIssue}} tag in the transaction summary to indicate which Epic subtask is involved, otherwise all tasks under Epic will have the same name and will not be easily distinguishable.

Synchronize development releases to implementation projects

In privatized deployment product development, iterations are not always deployed to customers. Simultaneous development and implementation tasks are managed separately in the two Jira projects, iterative releases are managed in the development project, and client side upgrade requirements are managed in the implementation project, so client side upgradable releases need to be synchronized from the development project to the implementation project. Jira Automation can avoid delays in version synchronization and errors that may occur during manual synchronization.

1. Set the trigger

Here we use Version released as a trigger, using regular expressions to filter out releases that do not conform to the Version naming conventions.

After setting the trigger, you want to record the released version name in the audit log for troubleshooting. Therefore, an action for adding audit logs is set to record the smart value {{version.name}}.

2. Set the condition check component

Since we only want to synchronize the release of the specified development project to the implementation project, we use {{version.project.key}} for regular matching filtering, and only accept the release data of PI and HZPI projects.

3. Perform subsequent versions creation and release

Now that we’ve filtered out the release data we need, we just need to go through the process of creating and releasing the release. In this example, the release version is used as an example. You only need to change the execution component from the release version to the create version.

Synchronize bugs fixed in the release to the IM workgroup

The project manager or customer success manager in the post-release implementation department wants to quickly see what bugs can be fixed in the current release. In the past, we used to synchronize information by releasing release Notes documents in Confluence, but the timing of document synchronization was not good, and it was not convenient for project managers or customer success managers to visit Confluence when they were at the customer site. Jira Automation solves this problem by synchronizing the information directly to the IM workgroup so that project managers or customer success managers can see the information in a timely and convenient manner, thus improving the message reach rate and communication efficiency.

1. Set the trigger

As in the previous example, we used the Version released component, using regular expressions to filter out the Version we wanted to send.

2. Filter out bugs that need to be synchronized

Then we need to filter out the bugs fixed in the corresponding version. Here we use the Looup Issues component. In this component we use JQL to filter out the bugs and save them in the smart value {{loopupIssues}} for subsequent rule execution.

3. Send Bug data to IM workgroup

Finally, we just need to send the data to the IM service interface in the format specified by IM.

There’s a very interesting capability here. In the Post body of a Web request, we can use the list capability provided by Smart Values to embed it in json data. When we send a request, Jira Automation will automatically render the data and send it, so that multiple bug data can be sent in one IM message, instead of sending multiple IM messages to pollute the group information.

{" msg_type ":" post ", "content" : {" post ": {" zh_cn" : {" title ":" {{version. The name}}, fix the bug list ", "content" : [ {{#lookupIssues}}{{^last}} [{ "tag": "a", "href": "{{url}}", "text": "{{key}}" }, { "tag": "text", "text": ": {{summary}}"}, {"tag": "text", "text": "@ {{reporter. DisplayName}}}, {{/}} {{/}} / / this is a rendering json data when the last record end no comma processing {{# lookupIssues}} {{# last}} [{" tag" : "A", "href" : "{{url}}", "text" : "" {{key}}}, {" tag", "text", "text" : ": {{the summary}}"}, {" tag ", "text", "text" : " @{{reporter.displayName}}" }] {{/}}{{/}} ] } } } }Copy the code

In the end, the effect of IM workgroup is as follows. If the project manager or customer success manager wants to know more about the specific situation of bug fixing, they can directly click the link to open it:

conclusion

To sum up, Jira Automation is a simple but powerful Automation tool, which can automate a lot of repetitive manual work on Jira by means of component drag configuration, greatly reducing the threshold of Automation. Of course, in addition to the product function is worthy of praise, the product design ideas and abstract logic is also worth learning.

The resources

Jira Automation Cloud Version official documentation

Smart-values Cloud Official document