Release Management — SDLC
As startups/enterprises begin to grow in size, it gets critical to track all the changes that goes in production for a variety of reasons. With multiple teams on a marathon, looking to rollout new features almost every other day, it becomes painful and time-taking coordinating/communicating the changes across the board, avoiding release conflicts; especially at times when the changes in production is least expected; and avoid damage control in production. Moreover, it becomes equally important for the changes to propagate through various stages and checks/approval (without fail). Failing to address this results either in poor quality/untested code reaching production and/or result in significant drop in development velocity.
Then there are such windows as well where releases in production needs to be restricted, for cases such as month-end/quarter-end or product/customer launch or an infrastructure change. It becomes risky & error-prone as the reliance is on group of people (leads/project managers/etc.) trying actively to ensure things don’t get to production during such moratoriums.
The problem doesn’t end there. If say, there is a bug introduced in production due to some change, how to quickly identify what could be the cause without looping in all individual stakeholders from every stream. Majority of the issues in production get attributed to the latest set of releases/changes that are pushed. This can be very annoying if simply determining which culprit change was pushed, takes time. Also, there are practical situations when there are disruptions due to partial releases, cases when releases to one or other project is missed.
Proper visibility into the changes going in production at single place would definitely help address some of the concerns highlighted above. Not just issue determination & comprehensive view of release mgmt, a unified visualisation will also help run analytics over the changes being pushed and analyse the areas which impacts production pushes such as prod launches, no-release time windows which could be later used to plan sprints/scrums and other initiatives accordingly.
Lastly, not to mention there are often cases where the software development is done in advance but that needs to be rolled out only at a later date in production, say a quarter due to operational/business reasons such as product launch, etc.
All the above cases needs heavy reliance on manual coordination across the board which is not only troublesome but also lead in slower development velocity & releases. Considering these in mind and the associated side-effects with manual validation at each step, there comes a strong need to manage releases (in-fact code propagation) more effectively.
Having said that, below is an attempt to setup a release management process (SDLC workflow in essence) across the board for better governance & control, visibility in one place, effective coordination between people/teams and better management — taking into consideration minimum time is involved in managing releases by developers, team leads, etc and not hampering development velocity. (Kindly note this piece is still a WIP and all suggestions are welcome to make this process better. :)
Choice of tools: Based on my past experience, there hasn’t been any one such tool which could meet all the objectives and the enterprises have had been coping up with the challenges mentioned. Of all the problems, the biggest of them is the connectivity between the tools: (project planning tool + SCM + workflow (or release) mgmt processes/tools)
The overall objective is to solutionize a process which could help orchestrate the desired workflow in the SDLC process, keeping in necessary checks, demand approvals, integrate seamlessly with tools and provide unified view for visibility and management.
The below approach is framed taking the below tools in consideration and the fact that we have already been using some of the Atlassian tools such as Confluence for PRDs, and JIRA to manage user tasks, run sprints and progress. There are a suite of tools within atlassian that can aid in SDLC, & help navigate down seamlessly to get accurate information about a release with it’s easy integrations with external systems.
- SCM: Github
- CICD: generic (could be anything)
- JIRA Release Hub: To manage releases/versions within a project.
- JIRA Calendar Gadget: for unified view of all releases across the board. [You can use Teams Calendar that comes with Confluence add-on at an additional cost if you want to.]
- JIRA Development panel: An integrated view to provide development status at unified place.
- JIRA Cloud Api: Helps consolidate all deployment statuses for a change.
- JIRA Workflows: To easily orchestrate the change with necessary steps/stages/checks and approval process.
Below covers some of the detailing/highlights across each areas:
- JIRA Release Hub to manage releases/versions for a project: Helps to organise all releases planned with timelines, track releases for future dates as well and a unified view to see all unreleased changes within a project. Each release can further drill down on the status of each issue associated, and provides consolidated view on their development and deployments statuses as well. (refer next image)
2. Tracking the status of a release at a team level — end to end
With proper integrations with the SCM, we can determine the statuses of each issue and the stage where they stand in the SDLC lifecycle. (How to integrate with SCM, github in this case — coming up later.)
TO DO: An extra column can be added within the release hub to visualise the deployment statuses such as DEPLOYED TO INT, DEPLOYED TO STAGING, DEPLOYED TO PROD, etc. against each issue.
3. Tracking the status of an issue with respect to deployments
Your CICD can be hooked with JIRA via integrations possible. Since we have our own CICD framework, we rely on JIRA Api to update the deployment status of an issue, as below:
4. Unified view of all the releases across the board, all projects
Below is a widget: Jira Issues Calendar (with version on) associated with my dashboard to give a consolidated view of all the releases across the board with timelines, this can be really useful to quickly visualise what are the scheduled releases/infra change/moratoriums and easily shared with all stakeholders.
You can also hook up all the JIRA releases with Atlassian Team Calendar (comes with additional cost)
5. Finally, Solving the real problem of orchestration of changes via Workflows
Since the development workflows varies from org to org, depending upon the existing infra/processes/SCM structures/development paradigms/compliance/others in place, I would recommend designing your own workflow pertaining to your needs, for your issue types.
Below could be one such instance, as described:
First we need to formalise which issue types (of all the ones available) will actually be leveraged for software development. Let’s say we freeze upon the Issue types — New Feature, Enhancement, Bug & HotFix (a custom type).
Second, while all the above issue types will follow same workflow (same SDLC process), HotFix Issue type would follow slightly a different workflow as it would need additional approval, and scrutiny from senior stakeholders.
Thus, we would create 2 workflows — one for feature, enhancement & bug and another for hotfixes. (refer images below) and associate them to one workflow scheme. This workflow scheme can then be associated to all the projects, post which these issue types under all the projects will follow the same SDLC process.
Note: We could very well add checks/steps in the workflow such as changes flow through all env (dev/staging/prod), a code review is filed, approved and merged, etc.
6. Approval process under the SDLC process
An issue in propagation often needs to be actioned upon by various individuals, things like QA sign-off or CAB approval which are only to be actioned upon by restricted set of people only. This can be achieved by adding the condition to the transition step in the workflow. below is an example for restricting who can move the issue from stage: Awaiting CAB approval to CAB Approved in the above workflow for hotfix
7. What’s next & more?
We could leverage the power of jira workflows, JQL & cloud apis to further strengthen the development & release process. Things such as avoiding releases in the evening or peak business hours or adding more relevant information on release dashboard.
Thank you!
