RELEASE MANAGEMENT IMPROVED
Using Slack and JIRA to make releases seamless but safe in a world of microservices
How The Telegraph built a smoother release management solution that keeps pace with a busier schedule of changes, while ensuring accountability every step of the way
Overview
Introduction
How it works
The user journey in Slack
Automated record-keeping in JIRA
Adding Github Action functionality
The results
Useful links
Microservices sit at the heart of what and how we build software at The Telegraph. This has made for improvements to performance, resilience and the maintenance of our applications. But as the volume of services swells over time, so too does the number of releases we need to make. Every month we perform dozens of releases to our systems. Our dilemma? Ensuring that these changes are properly reviewed, approved and documented, whilst removing any unnecessary friction.
The right solution for us laid in tools that were already at our disposal. The Telegraph has been using Slack for several years and its Bolt SDKs make it relatively easy to write custom applications. Likewise, JIRA has long been our primary means of accounting for work, including change requests.
We found that, by building an API to handle the flow of information and requests between users, Slack and JIRA, we could seek and co-ordinate releases in a more convenient and more visible manner. In addition, we were able to take advantage of Github Actions to add further improvements to the process when making changes to project repositories.
What follows is truly a joint effort; this project’s creation and continual improvement has been the work of the whole team coming together and contributing ideas, to forge a system that meets our needs brilliantly.
How it works
This diagram tries to convey the lifecycle of a change request using our system. I have numbered the steps to help lay out the basic chronology.
The user journey in Slack
One of the key functions of our API is to return json strings to Slack that it uses to populate the modal screens for our request process, as well as parse the data being sent over Slack and use it to create and update tickets in Jira. This being the case, I will illustrate just what a release request looks like in Slack from start to finish. Some fields have been obscured because they bear no relevance to our setup.
1. The process is initiated either by a Slack user entering a slash-command to bring up the release-request form, or triggered by a Github Action.
2. After this is executed, Slack will post a message in a channel that specifically handles this process. The message will prompt them to Review their request or Cancel.
3. On clicking Review, Slack will contact our API and request the json for the modal screen to create a release request. This will include all the details we need to progress the request and create a ticket in Jira. The image below contains some example text.
4. On clicking submit, the request will be posted to the channel with an @here, to alert all members of the channel so someone can tech review and approve it.
5. Once this has been completed the request will appear in a separate channel where management can perform a final review and approval of the change.
6. The management approver can click on More Details, which will result in Slack hitting our API to request the modal screen json that displays the request’s details.
7. Once management has approved or denied the request it will then send the decision back to the tech approval channel.
8. However, even after approving the request, management can still cancel it later if a scheduling conflict or other reason occurs. They just do this by clicking on the Cancel Release button, as seen below.
9. After clicking the Cancel Release button, it sends a request to our API for a simple one field screen.
10. This cancellation will then update the initial channel with the cancellation and reason.
Automated record-keeping in JIRA
Thanks to our API, the actions being committed in Slack are also being recorded in JIRA without any manual interaction required. I will now illustrate the tickets we create as part of the process.
1. Once the requester has submitted their release request, a ticket in Jira is created with its status kept accurate to its place in the workflow.
2. Once the ticket has been tech approved, the ticket status is updated.
3. Finally, when it has been approved by management, we record it as approved and mark the request status as resolved.
4. If the release is later cancelled, we also update its status and record the reason for cancellation in the ticket.
Adding Github Action functionality
As The Telegraph uses Github, we have added a Github Action that means you can initiate the release request process from a pull request.
By using this method, we can transpose the release description and other fields directly from the pull request into the release request.
We even have another Github Action that we use to template the pull request description, which is also triggered by adding a label to the PR.
This makes life just a little bit easier and ensures consistent data about changes across our platforms.
JIRA calendar that puts changes in context
Finally, we use a calendar-based dashboard in JIRA that is populated using a filter for all the changes we want to track. This gives crucial, at-a-glance context to what changes are happening and when, an important step in approving any new requests that may appear.
The results
Our system has made it simpler for different teams to raise release requests in one place and get them reviewed, even from the comfort of the Slack mobile app. This convenience has made the release process far smoother for us and meant that we can keep pace with the high volume of releases we need to keep maintaining and improving our catalogue of services.
Useful links
Here are some links that will help you if you’re interested in replicating this kind of setup.
Adam Gaudry is a Platforms Engineer at The Telegraph.
