Using Jira to build a Release Management Framework at Simplilearn — Part I

Peace of Mind — Wish releases always came with it

[This is the 1st blog in a series of 3 short blogs. Once published, the links to part II and part III will be made available here]

The fact that you’ve chanced upon this blog indicates that you’re either familiar with release management as a process or possibly have an issue at hand with releases that you’re trying to solve using Jira. If you’re one of those 180,000 customers across the globe who have a Jira installation at your organisation, here’s an easy and step by step guide to setting up a rudimentary yet effective release management framework for your teams that will bring in sanity and help you cope with the growth pangs in your teams.

“A little more accountability, please”

Before we dive in, here’s some background into our challenges. We have multiple engineering teams at Simplilearn with each team working on a specific aspect of our product offering across the Simplilearn website or the learner platform. With a growth in our offerings to the learners as well as an increase in the capabilities of our platforms, the releases have grown in frequency as well as complexity. The following challenges plagued our existing release process directly or indirectly:

• Need for better cross-team coordination to manage increased number of teams and releases
• Lack of centralised communication with stakeholders/support teams
• Absence of Release success measurement and lessons learned
• No straightforward reports for external audits/governance

It was clear that we needed a Release Management Framework. The below figure illustrates our objectives behind building this framework.

Fig 1: Objectives of the Release Management Framework

Zeroing in on Jira

Simplilearn uses Jira not only across our multiple technology teams, but a lot of our vital functions such as Content, Product and Marketing teams use Jira for some very specific purposes. Within technology, we leverage the offered issue types — Epic, Story, Bug, Task and Sub-task extensively in line with the industry best practices and we also follow the agile scrum methodology for all our development. Given our current size and scale, it was only logical that we leverage the existing capability (and certainly the flexibility) of Jira to manage our releases better.

Jira “Releases” but with a twist

Jira already has a fairly effective ‘releases’ feature that can be leveraged to tag items to a given release version. These release versions capture the below attributes:

• Version (Name of the release)
• Status (Unreleased/Released/Archived)
• Progress (It’s a status bar that reflects the progress of the items tagged to the release version)
• Start Date and Release Date
• Description

Fig 2: A sample release version in Jira. Note the progress bar being green indicates that all the items tagged to the release are in a Done state and can be released

Fig 3: Upon clicking on the release version, we see the work items tagged to the release version split by their status

The release notes are automatically generated for all the items tagged to the release (by updating the fix version on the individual items to the given release version).

Fig 4: Auto-generated release notes (essentially the list of items tagged to the release). We’ll use these to populate our release record later

We were keen to use this feature, but we also wanted to capture additional attributes for a release that did not get covered as a part of the list of attributes above in the out of the box release feature. Further, there are limitations on our ability to query (using JQL) these release ‘versions’ as an entity given that these are not a valid issue type.

As a workaround, we created a new project in Jira and named it Release Management (RM). Under this project, we created a custom issue type called Release which was allowed to have sub-tasks.

Release: This issue type has a one to one mapping with a “release version” above. For clarity, we’ll refer to this as a release record for the rest of the blog. This release record captures the key attributes of a release, which include:

• Release notes (in the existing field description using the content from release version from fig 4)
• Deployment Instructions (custom field akin to description)

Fig 5: Release record attributes. Note that the description field is used to populate the release notes. Also, note the other editable field Deployment instructions.

• Release type (custom drop down to select a major, a minor or an emergency release)
• Release priority (High, Medium and Low mapping to Emergency, Major and Minor respectively, this serves a key purpose in our release calendar)
• Teams Involved (multi team selector)
• Release Date-Time
• Impacted Products (multiple products selector)
• Vital flags — rollback status (none/partial/full), delayed release (yes/no), late scope change (yes/no)?
• Release Status Link (a custom field that has a hyperlink to the Jira ‘release’ version. This hyperlink enables quick navigation from the release record to the release version)

Fig 6: Additional release record attributes. Note the highlighted field Release status link

The summary field on the release record must have the same name as the release version for integrity.

Sub-task: These are sub-tasks under the issue type release, and capture the essential approvals needed for each release(and this varies based on the type of the release). We’ll discuss this in detail.

To sum up, given the limitations of the ‘releases’ feature in Jira, we created this custom issue type to handle our releases better. The next aspect we’ll cover is what our release workflow is and how the release record we created helps in tying the entire framework together.

Stay tuned for part II.