In this article the author discusses the time-tested Hub-N-Spoke Release Management process that ensures a holistic view of the code (new or modified) is considered before releasing it into the production environments. This process was used successfully by data management groups of a large financial company. Subsequently the use of this Release Management process resulted in improvements in the code release process.
The Viscious Problem of Bad Code Releases into Production Environment
How many times have we come across situation where the code is developed, passed the QA but somehow doesn't seem to get into the Production Environment, only to realize it was a minor documentation glitch or a missing QA report or an ill-coordinated code release schedule. We end up cutting a sorry figure in front of the Change Control Board which eventually brands us as not so production reliable.
Hence we end up in the viscious cycle of painstaking scrutiny by the Change Control Board which results in lot of re-work effort by the development, QA and Release Management teams.
In this article we discuss a unique Hub-N-Spoke Release Management Process which is not only time tested but also ensures that a holistic view of the code (new or modified) is considered before releasing it into the production environments. This process was used successfully in one of the Data Management groups of a large financial company. This company was struggling with frequent Change Request rejects and large number of Trouble Tickets being raised due to poor quality Software Code releases into Production resulting in increased re-work effort. Subsequently the use of this Release Management process resulted in improvements in the code release process.
The Hub-N-Spoke Release Management Process
The Hub-N-Spoke Release Management Process is explained in detail in this section. The scope of this Hub-N-Spoke Release Management (RM) process is limited to the release of the software code from the development team into the Production Environment, post the approval of the QA team. Further the scope is restricted to the Data Management environment.
This RM process ensures that the Software Code released is consistent, cost-effective and a delightful experience to the software community in general.
Creation of a Separate Release Management Team
This process suggests the creation of a separate team for performing the RM function. The RM team is mainly focused on effective job releases into Production and is not very much focused on the internal details of the software code to be released. The RM team is supported in it's operations by various pre-defined checklists and dashboards.
In order to have a holistic view of the code to be released the RM team coordinates with various other teams like the development team, QA team, Production Support team, DBA team, Change Control Board, Operations team.
Let us now discuss the sequence in which the RM team coordinates with these various teams in eight stages to ensure that the release process moves from one stage to the next stage seamlessly, accurately and consistently.
In Stage 1, Once the software code is given the approval by the QA team , the Development team passes this code to the RM team along with the associated release documents and artifacts (as per the defined standards).This is followed by a Knowledge Transition (KT) session between the Development team member and the RM team member to understand the basic details about the software code to be released.
In Stage 2, The RM team gets an approval from the QA team about the software code to be released. This approval focuses on the quality/defect aspects of the software code.
In Stage 3, The RM team gets the approval of the Production Support team w.r.t the impact of the release of the software code into the Production Job Streams, of the applications that the Production Support team is responsible for. This approval focuses on how this software code is going to be positioned in the Job Dependency diagram and also how it is going to behave in