Our team is growing! Wait a second, when did we switch to Jira?

You will hear things like the above great quote from time to time. Other versions all software projects die or live long enough to end up using Jira. While a funny joke, there is some truth… That while developers notoriously hate Jira projects eventually end up using it as project management, teams, squads, QA, and simultaneous projects scale. Jira and by association the larger Atlassian ecosystem has many appealing features to help understand complexity across bigger projects and cross team and project dependancies. Related to all that which is really a topic for another post, we moved to Jira awhile ago, but we still want to reduce unnecessary extra complexity. Let’s see what we can automate.

Jira Supports Git Integration

The support comes in the form of Development tools integration.

Jira has some support easy developer tools support. If you use git like we do turn it on to make all your developers lives easier. When enabled out of the box you will get:

properly tagged commits are associated with tasks in Jira

properly tagged commits associate Pull Requests (PRs) in Jira

The ability to transition and comment on a task, based on commit message (pay attention to this one as it can be powerful).

To get the basics going, there is nothing special follow the Jira documentation to:

While initial support is nice, we can go further than that. Let’s see what we can do to further automate some of the Jira process.

Beyond the basics with Jira and Git integration

Jira the tool we love to hate

Our team practices continuous deployment, which offers a lot of advantages, but does have some drawbacks. One drawback is that it increases the complexity to answer a simple question. When was feature X deployed? Developers can normally figure this out by looking at git logs and deploy timestamps, etc. It can be a bit of a manual process, but it doesn’t have to be.

Why should Project Managers or Stakeholders have to ask developers when a story was released?

Why should developers have to manually go update the status of a story to deployed?

Why would we need to look at other tools to figure out what is in a release?

Our team doesn’t need to put up with that. That is what we are here to improve with Jira automation. Improving our release process and understanding by leveraging Jira smart commits.

Automatically Tagged and Transitioned Tasks

In the end what we want is to make sure the state of our Jira tasks always reflects what has been released to production. We can hook into our deploy process to automatically update update tasks and associate it back to a tagged release that everyone can lookup and see. As our app is deployed to production

Every deployed release is uniqued tagged in git

Every Jira task in the release are moved from whatever state they were in to the Deployed state (which is a Completed status in our Jira workflow )

state (which is a status in our Jira workflow Every Jira task in the release have a comment added, which specifics they were released with the uniq release tag

Our projects releases.txt is updated with the uniq release tag with the list of Jira stories included in that tag for easy cross reference from our dev tools to Jira tools.

updated with the uniq release tag with the list of Jira stories included in that tag for easy cross reference from our dev tools to Jira tools. The story transition and comment with notify all people (or slack channels) that are following that Jira task, making it clear that it has gone live)

This fixes a comment problem where developers would forget to update the Jira task after deploying, leading to situations where project managers and stakeholders weren’t aware that a story went live. Which can be particularly confusing if bug reports start to come in, related to a feature that “isn’t live yet.”

Do It Yourself Jira Automation

If the above sounds good, here is how we achieved our goal. There are a number ways one could approach this to get the same result. If you don’t use Ruby don’t worry it should be pretty easy to port these deploy tasks to the language of your choice.

Taking it even further?

So let’s automate away the hate ;)

This is only one piece of the puzzle. While Jira is a pain to configure, it is extremely flexible and powerful. You can take it much further with full workflow automation, based on triggers.

Jira Git Workflow Automation: ( To Do → In Progress ) Branch/Commit created (Bitbucket Server), ( In Progress → In Review ) Pull request created / Pull request reopened, etc…

→ ) Branch/Commit created (Bitbucket Server), ( → ) Pull request created / Pull request reopened, etc… More details on workflow automation including integrating review processes

At some point this might be overkill, but the point is the integration can be powerful and adjusted to your needs. If you feel a pain point for your team or stakeholders related to the Jira workflow, consider if you can automate it with tighter code and release integration. Let us know if you have found any great Jira process automations.