Like many engineering teams, here at Traackr we like to streamline our workflow to spend as much time as possible building cool features. We also like to release early and often. And our product team likes being able to answer pesky questions like “has feature X been deployed?” or “there was a regression with feature Y, what release was that included in?”. At times, these requirements can be a give and take. Using an issue tracker helps answer questions about when things were released, but navigating an application like Jira is a context switch. Plus, it’s easy to click the wrong buttons. Releasing often means these context switches and mistakes happen frequently. Can we do better?
We think so, which led us to look at what we like about our tooling. One great thing about using Jira and Bitbucket is the way they seamlessly links commits to issues by including a ticket ID in your commit message. Because of this, we’ve standardized on a “<Ticket ID> <Message>” commit message format. We enforce this standard using a commit hook. This got us thinking… If we can link Jira tickets to commit messages, can we also map our git tags to Jira fix versions? It turns out the answer is yes!
There were two main problems to solve. How do you identify a range of commits associated with a release? How do you interact with Jira to tag the issues with a new fix version? Enter release_fix_versioner.py.
At Traackr, we use a git-flow tagging and branching strategy; this is very convenient because for every release we already have a tag to reference. By providing our script with a new git tag, we can grab all commits between this tag and the previous tag to represent all of the commits to create a new release. With startTag and endTag, git has a handy command “git log — format=%s startTag…endTag” to print a list of commit messages in an easy to parse format. From there, it’s a simple matter of parsing the commits to come up with a unique set of issue IDs. In order to support a variety of commit formats across different teams in our organization, the parsing is done using a regular expression with named groups to identify the key and message: “(?P<key>[\w]*-[\d]*)[ :-](?P<value>.*)”.
Interacting with Jira turns out to be simple as well; the interface is extensive and does anything you could ask for. To start with, we decided to add some validation to each ticket prior to dealing with tags. We check things like making sure the work is finished by verifying the state equals “Done”. This method is really all there is to it:
After creating two more similar methods to create a new fix version and add that fix version to each ticket, we’ve got ourselves a prototype:
Now that we have this script, we can start using it to simplify the manual issue management. If it works out, we’ll include it as an automated step in our one button deploy job, and we’ll never have to worry about Jira being out of date again. This could even be used to generate release notes for our public facing applications.
Originally published at Traackr Engineering.