Meet the new gold standard in workflow automation
I’ve been called many things by many people, and “borderline OCD” is one that pops up more frequently than I should probably admit. It’s just so satisfying when my own records match those of my bank… when I know the next three turns I need to make when driving to someplace new… when the issues on my agile board perfectly reflect the state of my project. Ahh, bliss.
Now, “lazy” is a moniker I’ve assigned myself on occasion, but always with a wink. I love making computers perform simple tasks for me, so I can think about more interesting things, or have time for another coffee–hence, my fondness for automating regression tests.
So, you can imagine this obsessive efficiency-junkie’s excitement over Jira Software’s workflow automation triggers.
Workflow automation triggers. They solve for laziness, forgetfulness, OCD-ness, and probably cure the common cold to boot (still testing that).
Issue statuses can self-update based on activity in your code base. This means developers can remain focused on their coding task, knowing that Jira Software is automatically keeping their teammates and stakeholders up to date. And because these updates happen in real time, project leaders get hyper-accurate burndown charts to help them forecast release readiness, and identify bottlenecks in their team’s processes.
You can still drag issues between columns on the agile board, or update their status using the workflow buttons across the top of this issue. Workflow automation triggers simply provide more options for how issues move from one status to the next, as well as provide assurance that the current status reflects the actual state of development.
Let’s take a simple set of workflow states–Open, In Progress, In Review, and Done–and look at how the transitions between them can be automated with the new triggers.
Open to In Progress
There are two triggers that work great for this transition: “commit created” and “branch created”. The commit trigger listens for commits in your Bitbucket Cloud-, Bitbucket Server-, Fisheye-, or GitHub-connected repository that include a Jira Software issue key in the commit message. (And yes: that means all Fisheye repos, regardless of version control system.) Jira Software then looks at the state of that issue, and if it’s still Open, moves it into In Progress–because, clearly, progress has indeed started. Similarly, the branch trigger listens for new branches that contain an issue key in their name, and updates the status to In Progress (if someone hasn’t already done so manually).
The branch trigger is perfect for teams using a branch-per-issue model, in which issues are scoped, such that a single developer can complete them in one sprint or less. The commit trigger is great for teams who use a less prolific branching model, such as trunk-based development. These triggers can even be used in combination so that either event will update the issue status.
A word about global transitions: Use caution when combining triggers and global transitions. For example, using the commit trigger with a global transition that moves issues (from whatever state they’re currently in) to In Progress is fraught with peril. Commits are often made during the code review phase in order to incorporate the feedback from your reviewers–in which case, you’d want the issue to remain in an In Review state.
In Progress to In Review
Whether your team does code reviews by way of pull requests or more traditional reviews, the related issue can move into In Review automatically. Crucible users can take advantage of the “Review started” trigger, which listens for reviews that include commits in which a Jira issue key was included in the commit message, and–are you picking up on the pattern?–moves them to In Review. Git and Mercurial teams use the “Pull request created” trigger to accomplish this. If an issue key has been included in the pull request’s title, the name of the branch being merged, or the commit messages of the commits included in the pull requests–you guessed it–Jira Software will update the issue’s status as the pull request is opened, declined, or merged.
Here again, the two triggers can be combined. Let’s say you have Git repos in Bitbucket and you do pull requests for small changes like bug fixes, but prefer to track feature- or epic-level reviews in Crucible. No problem. With both triggers in place, you’re covered either way.
In Review to In Progress
We don’t always get things right the first time, and going back to the drawing board when your changes didn’t pass muster is practically a rite of passage for developers. Your head is swimming with all the rewrites you’re about to make, but at least you don’t have to worry about updating the status of the issue you’re working on. The “pull request declined”, and “review rejected” triggers take care of that.
Interested (and observant) parties don’t need to wonder why the issue is back in In Progress–Jira Software puts a note in the issue’s history letting them know what’s up.
In Review to Done
Moving an issue to Done is always satisfying. And we wouldn’t want to take that away from you, but… the “Pull request merged” and “Review closed” triggers are very handy here. In fact, this is one of the few situations where I’d add a workflow trigger to a global transition. Regardless of whether an issue is Open or In Review, if the associated review is signed off on, it’s safe to say the issue is Done. And speaking of sign-offs…
A word about permissions. When workflow transitions are automated with triggers, permissions around who can move the issue between states are ignored. Same with conditions and validators. But don’t fret: conditions, validators, and permissions will still apply for that transition when it’s executed manually.
More workflow automation awaits you
Workflow automation triggers can be applied to transitions between any two states, not just the ones mentioned in my simple example. They don’t prevent you from dragging issues to a new column on the agile board, or hitting the oh-so-satisfying Done button inside the issue itself–they just eliminate the need to do this manually every time. And with triggers in place, an issue’s status becomes the source of truth that project stakeholders can rely on.
We’re really excited about workflow automation triggers, and so are our intrepid beta program participants, like Trulia. But this is just a starting point. There are more triggers than the ones I’ve mentioned available now, and we’re looking forward to expanding the collection, based on your feedback. So send us your suggestions!
Sign up for the Jira Insiders monthly newsletter, full of tips and tricks to help you get more out Jira.
Ready for more Jira tips and tricks? Sign up for our monthly Jira Insiders newsletter, and click below for more tips and best practices blogs.
Did you find this post useful? Share it on your social network of choice so your fellow Jira users can get the most out of Jira Software’s workflow automation triggers, too!
Originally published at Atlassian Blog.