Using Jira to build a Release Management Framework at Simplilearn — Part II
[This is the 2nd blog in a series of 3 short blogs. Part I can be accessed here. Once published, the link to part III will be made available here]
In part I we discussed the need for a Release Management framework and emphasised how it’s a must have both for accountability and ensuring the integrity of the overall release process. We also discussed the Jira ‘releases’ feature, its limitations in the Simplilearn context and the custom ‘release’ records that we created to enable effective tracking of the releases. Armed with the release record and the release version, we now march ahead.
“So, when can we do a release?”
When we did a pilot on the release management framework, the onus to create a release schedule lay with a release management team. Our existing teams had a release frequency that varied based on the type of product being worked upon as well as the nature of the change whether it was a major, a minor or something urgent in reaction to an outage.
One thing was clear, we were not keen on doing releases on Fridays given that we wanted to save the weekend of our team mates in case things went down. Secondly, we were inclined to do releases during the first half of the day to ensure any fallout could be addressed on the same day without burning the proverbial midnight oil. What allows us some flexibility is the fact our releases 19 out of 20 times do not cause a disruption on the platform and the learner experience is seamless even during an ongoing release.
Based on these, we believed that the release frequency should be optimal — we didn’t want to release too often so that we end up more productive time on performing release preparation, deployments and release verification; and yet not too infrequently affecting our velocity of getting features into production. Thus we agreed that we’ll do our planned releases on Tuesdays and Thursdays only, and that too during a specific window between 11 am and 1 pm. We also earmarked the second and the fourth Tuesday of the month to do our major releases when all the architects and support teams would be on call in case any major issues arose from the release.
“And, how exactly do we do a release?”
The above diagram illustrates the flow of the activities related to a release right from the time the releases are planned for a given month until the verification of the actual release. Release management team creates the release record on the RM project and also creates a corresponding release version on the deliverable project. A link to the release version is added on release record (fig. 2). The Release Management team also updates the release deployment window. The release record is in ‘Issue Open’ status at this stage.
Scrum teams then tag their work items (stories, tasks) to the release version we just created, based on the date that their release plans align to. They also update the release record with the teams involved in the release and the affected product details. Once tagging of items is done, the release is moved to the ‘In progress’ stage.
Once the testing of all the deliverable features is complete, the QA lead(s) move the release record to the status ‘In RM’. They also ensure that all the tickets tagged to the given release version are in the ‘Done’ state.
“It’s time to approve the release”
Once the release is moved to IN RM, we’ve set up a Jira automation that creates sub-tasks under the release record and assigns it to the designated stakeholders for approval.
We mandate the approval from the Head of QA and Head of Infrastructure for all of our releases irrespective of their type. For releases that are major, we mandate the approvals of both our Heads of Pre-Sales and Post-Sales to confirm there are no missed impacts that they foresee across products. Lastly, for any emergency release to be cleared, the Head of Technology must provide their approval. Emergency releases specifically undergo additional scrutiny and the count of emergency releases each month is a metric we’re focused on minimising.
While this may sound like a lot of approvals, all these stakeholders are always involved in or at least aware of what is expected from the release, and hence the approvals are usually prompt post the due diligence. Another important aspect is the presence of an approval checklist that each of these stakeholders has, and they run the release past this checklist. Once convinced that the release conforms to all the points in the checklists, these stakeholders provide the approval.
Once the approvals are all in place, the release record is moved to the status of ‘Ready to Deploy’. When the designated time arrives, the feature branches can be released. In addition, any coordinated actions that teams need to take or any scripts or jobs that need to be run can be done as a part of the deployment activities. The field ‘Deployment Instructions’ on the release record already has these instructions listed and reviewed before the release.
Once all the deployment activities in scope (across teams) are completed, Release Management team updates the status of the release record as ‘Released’. All the communications happen through comments on the release ticket for transparency and future reference.
To summarize, we touched upon the frequency of the releases and our focus on making it as optimal as possible. In addition, we discussed the workflow of a typical release. Thereafter, we walked through the approval workflows and how jira sub-tasks enable us to capture the the approvals and create the audit trail. In the upcoming blog, we’ll explore our release retrospectives and more importantly evaluate the extent to which we have met the original objectives that we started with.
Stay tuned for part III.
