Jira Automated Release Tagging Process

Allison Lacker -

Communication is a critical part of coding, from initial product requirements, to discussing alternatives and ideas around better solutions, but keeping everyone invested in a project up to date can be time consuming.

Wherever possible, automating this process to keep everyone in the loop with minimal effort is ideal.

As part of this automation process, we recently set up webhooks with Jira to automate keeping tickets up to date with the latest status.This process helps us streamline communication without needing any manual involvement.

This is using two Jira Features:

Jira Releases

Releases in Jira allow you to tag tickets as part of a "version", and keep track of when those versions go out.
You can access these releases from the left hand side of your project menu

Jira Automation

Jira automation is a powerful tool that allows you to automatically set up rules and behaviors. Like many of Jira's features though, it can be hard to find.

Note: We are using Jira Cloud and Classic Projects, which impacts screenshots and potentially functionality.

To set up automation, go to a project, "project settings" on the left, and then click on "automation".

Deploy Process


As part of our weekly deploy process, we cut a new version on Wednesdays, run a thorough QA process on it, and then deploy on Thursdays. We wanted an easy way to see

  • which tickets would be going out in the release
  • whether the tasks had been released

To accomplish this, we set up two webhooks:

First Automation

We run the first automation as part of our version cutting script that we run on Wednesdays.

The first automation creates a release and tags the relevant Jira issues.
The setup was accomplished with the following steps:

1. A webhook was used as the trigger for the automation


2. We then set up a "new action" in order to create a new Jira release version with the date of the release cut


3. After saving the action, add a new "Branch rule" to the automation. This will query for any tickets in Jira that are in the engineering project, have not been released before, and are either in the QA process or passed QA.

JQL:

fixVersion is EMPTY AND status in ("Passed QA", Done, "Ready for QA") AND project = Engineering AND issuetype not in ("Product Research", EPIC, "Deploy Checklist")

4. Add another action to "edit issue". The goal of this is to add a new fix version to each ticket (fix version is the field in Jira that specifies which Jira release the ticket is part of)


5. Back in our release cutting script, it was then as simple as adding 

curl -X POST -H 'Content-type: application/json' \
https://automation.atlassian.com/pro/hooks/<hook hash>

Our release cutting script overall:

  • puts a copy of our main branch onto the production branch in github
  • tags the branch in git with a tag with the date on it
  • stops automatically syncing new code updates to our staging environment so we have a stable testing site until the deploy
  • triggers this automation in Jira that tags all the tickets passed code review as part of the upcoming release


Second Automation

The second automation releases the next open version in Jira and moves the related tickets to the status "Deployed"

The setup looks like this:
1. Same as the previous automation, it is setup to be triggered by a webhook

2. We then set up a branch rule to query for any issues that have a fix version but haven't been marked as deployed or done.


This intentionally doesn't look for only our most recent deploy in case we missed a ticket in another deploy, or had lingering followup that we needed to complete.

3. Then set up an action in order to change the status to deployed for each of these issues



4. Finally we release the version. The default behavior here to release the next open version is the one we want

5. And then, same as before, we add a curl call to the webhook as the final action of our deploy process. 

curl -X POST -H 'Content-type: application/json' \
https://automation.atlassian.com/pro/hooks/<hash of the second hook>

And now our Jira process is automatically kept up to date with our deploy process with no manual intervention needed!