Are you Still Moving Jira Cards Manually ?

A robot arm moving a task card on a board

Okay, maybe there is room for some manual actions from time to time. But wouldn’t it be nice to keep only the relevant ones and to automate all the transitions where possible?

It surely would but the question is: why do that?

Let me illustrate my point with an example. When was the last time someone forgot to update the Jira board after doing a pull/merge request, a review or a check on the test environment?

You see, automation eliminates the risk of forgetting. Thus, your team won’t need to update an extensive list of tools.

So, let’s automate EVERY aspect of your work.

Jira automation with webhooks

Jira provides a powerful tool for automation. If you are an administrator on your project, you can find it in “Project settings” -> “Automation”.

Here, you will find a list of “rules”. They are the ones that will allow you to create automation rules. Don’t forget to explore the “templates” tab, which contains interesting examples of what you can achieve with automation.

But to give you an extremely useful example, you can create a rule that sends you an email to congratulate you when your card is transitioned to “Done”. Something that goes like that:

An awesome Jira automation rule

Tip of the day — If people don’t congratulate you, do it yourself

There are four components in a rule:

• TRIGGER : When to run the rule. It could be a card transition, a field change, a new comment. Or even, a webhook *wink*
• IF : A condition. When you want to do something but only on a certain transition status, like “Done”. You can also use more complex conditions like JQL queries.
• THEN : An action. That’s the fun part. You can edit every aspect of a card, send notifications through emails or slack, etc. And you can also call a webhook to do anything.
• FOR EACH : You can create branches in your rule, to make various actions on various conditions. For instance, you might want to perform one action for story issues and another for bugs.

For each component, there are more possibilities than the one I mentioned. Take some time to look into it, you can do a lot of things.

Practical examples

Congratulatory emails are nice, but what can you do that’s really useful?

We will use this simple Jira workflow as a reference:

Jira workflow

Precision : ToReview refers to a code review on pull/merge request, and ToCheck corresponds to a step where a QA verifies the feature on a test environment.

Let’s examine each transition in the workflow to identify potential automation opportunities.

ToDo -> In Progress

Not the easiest one. On this transition, someone takes a card to work on it. It’s usually a human decision that starts on Jira.

You can imagine an automation that is triggered when someone puts a card in Done and which then assigns the person the first free card in order of priority. But this could cause more problems than it solves. So, let’s skip this one.

In Progress -> To Review

In our team, when developers finish their code, they create a merge request. You can detect it in Jira with the DevOps triggers, but you will need an integration between Jira and your BitBucket, Azure, Gitlab or Github.

If not possible, you can always use a webhook trigger and find a way to call it when a merge request is created. For example, you can call the webhook in your merge request pipeline. It will probably be called multiple times, on each push on the merge request, but it’s not necessarily an issue, depending on your jira workflow.

When creating a webhook trigger, you will have multiple choices for issues selection. You can specify the outcomes in the query, select them via a JQL query, or select none at all. The first choice is the best for this use-case.

Automation to move an issue in review state

And just with that, you have a webhook that you can call where you want to transition an issue.

To use it, you just have to make a http call on the webhook url, with the issues you want to edit in the body. With curl, it looks like this:

curl \
--location 'https://automation.atlassian.com/pro/hooks/<token>' \
--request POST \
--header 'Content-Type: application/json' \
--data '{
  "issues": [
    "TEST-123",
    "TEST-124"
  ]
}'

To Review -> To Check

When a merge request gets all the approvals required, the next step is to merge it and let the pipeline deploy it on a dev/preprod/whatever environment. Also, you have to move your Jira issue to the next status.

Or you can create another automation with a webhook trigger to move it for you. Calling a script in a gitlab CI is pretty easy, it’s even the first example in their documentation.

Stay aware of the moment you call it in your pipeline. It depends on which is the next status in your workflow and what it means. For us, it’s a quality check by a QA on a deployed environment. So the webhook is called after the deployment — you don’t want your QA to look for something that is not deployed yet.

job:
  script:
    - echo "Deploying some awesome features"
  after_script:
    - curl \
      --location "$JIRA_WEBHOOK_URL" \
      --request POST \
      --header 'Content-Type: application/json' \
      --data "{ \"issues\": [\"$JIRA_ISSUE\"] }"

Of course, avoid putting the webhook url in your CI configuration and use an environment variable.

Finally, the automation needs to know which Jira issue it’s dealing with. In our case, we put the issue ID in our merge request title, and we extract it with a regex in the CI. For that, you have the predefined variable CI_MERGE_REQUEST_TITLE.

To Check -> Done

Like for the first transition, I’m not sure there should be an automation for this step. If you don’t have any manual validation — only automated tests — you probably can move an issue to Done with an automation.

But if it’s manual, the transition to the Done status may not be a part of the process, but the trigger itself for other automations.

Conclusion

On this simple workflow, we are able to automate 2 out of 4 steps. It’s not fully automated, but it doesn’t have to be. The important part is the fact that 2 of these transitions could be done by a robot, not a human.

So, there is less risk of an issue status being not up-to-date on the board, and you reduce the number of tools you have to remember to update at each step in your work.

As tech people, we have to stay aware of things we can simplify and automate to ease our workflow. It’s part of the Third Ideal: Improvement of Daily Work

Take some time to explore the Jira automation possibilities. By having a vague idea of what is feasible, it is easier to have ideas to improve things.

To end this article, here are some examples of automation:

• For some time, we used to do effort estimations using t-shirt sizes, with a correspondence in points. We used S, M, L labels, which were transcribed into points by an automated system.
• When a release is published, you can automate a transition for all issues from a status to another, like from “Done” to “Deployed”. The release action can also be linked to your deployment tools with a webhook, if you have one.
• On our projects, each change and each commit are tagged with a version. The commit message contains the Jira issue ID and an automation sends the tag to Jira. This way you can know the version number of any issue.

Thanks to Elodie and Baptiste for their proofreading.