The release management system is an important component of the service-transition process, which is described in the itSMF ITIL v3 framework. Release management plays a critical role in promoting software modules from development into the production environments. The IT organization's goal of implementing the ITIL v3 framework is to ensure reliable services in support of the business. This article highlights the importance of implementing a monolithic release management system, which encompasses all of the functions and processes necessary to support application build, package, and deployment. The monolithic release management is holistic, comprehensive, and based upon industry best practices. These guidelines are applicable for any type of organization or projects of any size.
Release management systems are similar to automobiles that consists of many interconnected parts, such as the engine, wheels, gear box, etc. If any part fails or is misaligned, the automobile will fail to work or may not perform as expected. In release management, we often refer to these components as configuration items (CIs), which are managed by the release management system. A typical release management system consists of many functions, as shown in Figure 1.
Figure 1. Depiction of Release Management System Functions
All of the release management functions are interconnected in one way or the other.
The first step in implementing a monolithic release management system is to construct a comprehensive and consistent naming convention. For example, release numbers are referred to across all the components and throughout the release process. Similarly, code branches and streams in source control tools are designed as per the release packaging requirements—which in turn is documented in the release notes—and the environmental requirements to support test environments, including system integration, User Acceptance Testing (UAT), and preproduction. Proper environment management helps to support and maintain the infrastructure assets. Source control tools are also tightly integrated with the build scripts that extract code and package them into easily deployable release units.
A typical release process consists of the stages illustrated in Figure 2.
Figure 2. Release Management Phases
When creating the monolithic release management system, I focus on the following industry best practices that are essential for your success.
Release plans are created by project or development managers and based upon the needs of the business. Release plans communicate the work and deliverables that are planned for completion for each milestone and usually include release timelines, cycles, release numbering, release notes template, configuration item (CI) identification, and configuration baselines.
The release management system itself must be installed and configured to build and package configuration items, which in turn contain records on each CI, including the exact configuration and required testing.
Release coordination helps to handle all of the requirements for the release in this stage. Release coordinators play an important role and help to plan and communicate all of the tasks required to build and packages the release. This includes code check-ins, build process execution, and release package generation.
In release deployment, release packages contain all of the configuration items and are deployed in the target environments, followed by release testing. In release testing, post deployment testing is performed by the QA teams to ensure that the baselines and business needs are complied. Release testing helps to verify that the deployed code behaves as expected and desired.
Throughout the release process, multiple teams and stakeholders are kept in the loop and any changes are monitored. The change management team is consulted for change buy-ins or to report any incidents, either proactive or reactive.
If releases are mission critical and have to go smoothly, then all the components of a release management system must blend harmoniously. Given this complex system of interconnected components, a few issues should always be addressed. For example, release notes must be accurate and include information on how configuration items are identified. Changes should be identified coordinated with each stakeholder kept fully updated.
Below is a list of good practices that can be implemented to ensure that the release management system is comprehensive and holistic (or what is referred to as being “monolithic”).
The CI versioning will have to be determined by the build engineer before the start of the project (release planning stage). It must be standardized in such a way that the conventions are less ambiguous and uniquely identifiable across projects. Senior members of the team must openly discuss their versioning requirements and get a buy-in from the Change Advisory Board (CAB), which is comprised of the subject matter experts (SMEs) who know the downstream impact of a change.
Release numbering and packaging should be standardized as per the business needs; this should also be done during the release planning stage. Any major or emergency releases must be requested through the CAB and Emergency CAB (ECAB) respectively.
It’s beneficial for you to understand the list of components and the specific design of the release management system during the release planning stage itself. This should be based on a combination of the business requirements and future forecasts of the project. To maintain the CI metadata information, you might find it helpful to access the CM database (CMDB). If CMDB’s aren’t mature or available, you should use a secure spreadsheet for noting the information.
Release packaging must be standardized as per the business needs. You should take care in ensuring that the deployment packaging is compatible with the components of the release management system. For instance, some application servers may not support the deployment of multiple hierarchical folders; deployments may fail if a release package contains that kind of folder structure.
The configuration of CI's—including components—must be standardized across the project and environments by establishing baselines. Additionally, you need to tightly integrate the CI's with the release packaging and versioning conventions. For example, a build script must ensure that the version of the release is imprinted from the release notes. Any subsequent execution of unchanged code and script must result in multiple versions with subsets (v.1, v.2, v.3, etc.) indicating that these are multiple executions of the same version. Source control tool administrators can also utilize the stream versioning feature to name the releases while deploying new releases. Controls must be in place to ensure that build scripts aren't executed if there isn’t any release.
CI's must be controlled with password security or source-control branch locking, and they must be regularly monitored by the network operations center (NOC) or NOC team for the status of their health. The NOC team can monitor the CI’s health and ensure that the systems are operating as expected.
Any major changes to the components—either proactive or reactive—must be controlled through the CAB, and any out-of-schedule release requirements must be passed through the board for buy-in.
If any components fail like application server deployments, build failures, and others, automated notifications must be sent to the administrators or the release managers. Backup and recovery plans must be in place if something fails.
Most importantly, effective communication is the key aspect for successful release execution. Stakeholders must be kept in loop throughout the release process, and any changes to CI's or release plans must be communicated in advance. Any failures must be notified to the higher authorities or the ECAB in order for them to develop a quick action plan.
It is always beneficial to have a centralized CAB that can cater to the needs of all the business units, rather than having multiple CABs per business unit or organizational function. The change management function works with all stakeholders to determine how the CABs should be structured. This not only simplifies the governance aspects, but also reduces any potential confusion.
Depending on the organizational process maturity, it may not be possible to comply with all the above guidelines. But, release managers can tailor these guidelines, if necessary, to achieve optimal results. For example, there are times when emergency changes must be made to bring a production back online without calling a full change management meeting.
Conclusion
The monolithic release management system needs to address all of the items I’ve discussed in this article. This is a lot of work, but taking a comprehensive approach will help you and your organization quickly manage your release process efficiently. Taking a holistic approach by considering all of the necessary functions and processes will help you achieve success. This includes taking account of industry best practices as well as establishing a monolithic release management system.
