Overview
At Ginkgo, we use Jira to do ticket/issue tracking to facilitate agile software development and Gitlab as our version control system to manage our extensive software codebase. As software engineers, you usually create tickets on Jira and then create branches and open merge requests (MRs) on Gitlab to work on these tickets. We use the integration that Gitlab and Jira offers to track the association between the tickets in Jira and the merge requests in Gitlab. Gitlab has extensive documentation and videos about how to set up this integration. I’m not going to repeat their instructions here; instead, I’m going to highlight how we are using it at Ginkgo and what benefits we get from using it.
The Flow
This diagram gives a quick overview of the user flow for this automation feature.
- Product manager or software engineer creates a ticket on Jira to track the work
- Software engineer creates a branch and open an MR on Gitlab
- Software engineer mentions the Jira ticket in the MR by the Jira ticket shorthand, e.g. SUP-584, where the SUP is the shorthand for the Jira project name and 584 is the ticket number, in the MR description or the branch name.
- Gitlab Jira integration automatically converts the shorthand ticket number in the MR as a hyperlink to the Jira ticket, adds a link of the MR in the Jira ticket and posts a comment in the Jira ticket about the MR.
- As software engineers work on the MR, it posts updates to the Jira ticket whenever there is an update on the MR. For example, new code commits on the MR will result in a new comment on the Jira ticket.
Benefits
We’ve been using this Jira/Gitlab automation feature for more than 2 years at Ginkgo and it provides some strong benefits for product managers, software engineers, and engineering managers. Before the integration, we had to manually add the Jira link in the Gitlab MR and manually add the MR link in the Jira ticket and it was quite time consuming and not everyone followed the steps. Since the integration was implemented, way more engineers used this feature because it is super easy to just write a ticket number in the MR and let the automation handle the rest. As a result, it has been:
- easier to figure out the context of an MR by easily going to the Jira ticket.
- easier to figure out the coding work done on a Jira ticket.
For example, a product manager or engineering manager who wants to figure out what the coding work done on the Jira ticket was can go directly from the Jira ticket to Gitlab without needing to ask the software engineers who did the work. Software engineers who review the MR can easily get to the Jira ticket to understand the context about the ticket, who created it, which epic it is under, how urgent it is, etc. Even software engineers who created the ticket and coded the solution can also look at a ticket or an MR years later and quickly get up to speed with the historical context around it. I cannot stress enough how important this is as I often look at the code I wrote years ago and wonder why I did it. There were more than several times that the Jira/Gitlab automation helped me recover my memory.
Summary
We highly recommend this Jira/Gitlab automation if we use Jira and Gitlab in your organization as well! It saves time and provides context by connecting two pieces of software coherently. If you have any questions on this or if you have similar automation practices in your organization, feel free to tweet us @ginkgobits and we love to discuss with you!
(Feature photo by Drew Dizzy Graham on Unsplash)
