Introduction
The development of software applications is an evolutionary process, moving towards some predetermined end goals. These goals are usually in the form of a Release, either internal or external, to deliver a set of required functionality. Software Release Management is the process of ensuring releases can be reliably planned, scheduled and successfully transitioned (deployed) to Test and Live Environments. Software Release Management is not just about “automating the path to production” although that is certainly an important part. It also about adopting a holistic view of application changes, using the “Release” as the container to ensure that changes are packaged, released and tested in a repeatable and controlled manner. Release Management is often likened to the conductor of an orchestra, with the individual changes to be implemented the various instruments within it. Software Release Management is intrinsically linked with the more well understood and adopted Software Change and Configuration Management disciplines.
This article defines a set of good practices for helping in the successful adoption of Software Release Management. Although this article is about Software Release Management, many of the practices are generic and can also apply to Release Management in its wider sense as described in the IT Infrastructure Library (ITIL) whereby all aspects of hardware installation (e.g. do we need new PCs?), infrastructure upgrade (e.g. do we need to upgrade inter-site links?) and end-user training are considered. In some cases such a release might not include any software artefacts at all.
Defintions
In order to define some good practices it is first worth defining some terms which are used in Software Release Management. The following table lists of set of generic terms which are taken both from service management and application development.
|
Term |
Definition |
|
RFC (Request for Change) |
A high-level change request that captures the detail of a change that is to be made to a new or existing application. RFCs are usually decomposed down to lower level work requests or tasks for software development. |
|
CAB (Change Advisory Board) |
The collection of stakeholders who review all RFCs at specific intervals to assess whether they should be implemented, assign priorities and allocated them to a Release. |
|
Release |
A stable, executable version of a product intended for deployment to testing and production. |
|
Release Package |
A logical container that defines the set of RFCs and Deployment Units (sometimes called Release Units) that are to be included in a Release. It also includes metadata such as the type of release (see Release Type) and its planned dates (see Release Calendar). |
|
Release Type |
The type of release that is to be implemented, i.e. Major, Minor, Emergency. Each Release Type will usually have a different workflow. |
|
Release Policy |
An organizations published policy that determines under which circumstances different Release Types should be used as well as the standard set of milestones that selecting a particular Release Type implies in the Release Calendar. |
|
Release Calendar |
A set of published milestones that details when Releases are planned to transition through the different development, test and production phases. |
|
Baseline |
A snapshot of the exact versions of Configuration Items, including executables, libraries, configuration files and documentation that are to be deployed. |
|
Build |
An operational version of a product or part of a product. Not all builds are released but builds are typically carried to transform inputs (source code) into executed and installable Deployment Units. |
|
Deployment Unit |
A physical, self-contained, installable release of an application. |
An example of how these different definitions relate to one another is illustrated in the diagram below:
The Best Practices
The following good practices are based on many years implementing and observing Software Release Management. They are listed in no particular priority or order.
1. Define regular, targeted release dates
You should strictly plan and manage your releases and deliver releases regularly. Create a Release Calendar for each type Product’s Release Package to ensure that release progress is effectively communicated and planned. If a number of releases are being developed in parallel, create and communicate a high-level release milestone plan. The Release Calendar should communicate both internal (development, testing) and external (deployment to live) milestones. The Release Packages and Release Calendar are more easily managed and communicated if the details are kept within a database or workflow tool.
2. Always have a tested back-out plan
For releases that are being deployed to managed live environments you should always have a tested back-out plan. For example, if you deploy a new Internet Banking product release onto the live servers and subsequently find that there are problems with it, there should be a process in place for removing this release and rolling back to the previous one. In this scenario it is desirable that this process is as automatic as possible. The acceptance testing and rollout scenario should be part of the workflow defined for each Release Package.
3. Have a documented Release Policy
Your Software Release Management processes and policies should be clearly defined and documented. This should include the definition of the types of release you will manage, their workflows, the default calendars, as well as roles, responsibilities and artifacts. Usually this type of information is captured in a Release Management Plan. Make sure that this plan clearly states who is responsible for each part of the release process, i.e. who plans and manages the release, who builds and delivers the release internally and who packages and deploys the release externally. All the artefacts that are to be produced as part of the release process, i.e. Release Plan, Release Notes, Installation Instructions, should be clearly documented (and example templates given) along with who is responsible for generating them.
4. Construct Deployment Units as early as possible
Every time you build your application you should be constructing Deployment Units with the potential to be installed, for example a J2EE .EAR file or a Windows .MSI package. These Deployment Units might not be released beyond the development team but the point is that the build, packaging and installation process is proven early and at each phase.
5. Use an independent team to construct all external releases
If your team is very small then the developers might be able to carry out the build and construct the Deployment Unit. However, for any medium to large size product it is desirable to have a separate release team. This team usually manages the build process and packages up the results of the build into the Deployment Unit. They usually deploy internally (and sometimes externally) or pass the deployment unit to a separate deployment team. The release team is also responsible for creating the logical Release Package’s and communicating release dates.
6. All deployments should be performed by a team independent of the Development team
Developers should not be allowed to transition Deployment Units into a live environment. There is a potential conflict of interests in this situation. For audit ability and traceability it is better to have a separate team deploy the release to Live (and usually Acceptance Testing)
7. Test the deployment process at least once before deploying to Live
The deployment process should be tested at least once before any release is put into a live environment. This is normally carried out by having an Acceptance Test environment that mimics the live environment and is controlled in the same way.
8. Automate as much as possible â use integrated tools for Configuration, Change Management and Deployment Management
Software Release Management can be a repetitive and error prone manual process, therefore as much as possible should be automated. At the very least, the inputs and outputs of the release process (including the build components and release documentation) should be versioned using a Configuration Management tool (e.g Perforce,Subversion,Clearcase,TFS,etc) A Change Management tool can be used for controlling the content of the release and making Requests For Changes (RFCs) to it. A Deployment Management tool can be used to move the release to different environments or to install onto multiple desktop machines. Obviously, this all works best if these tools are integrated through to the Release Management process and its supporting tool(s).
9. Use a mature Software Configuration Management process and tool to support the development of multiple releases in parallel
When you are developing, building and deploying multiple releases in parallel it is critical that you have a Software Configuration Management tool that supports parallel development. Such tools are sometimes high-end, expensive toolsets (not open-source but they can significantly help to automate and reduce errors in the otherwise manual branching and merging process.
10. Link all release documentation and scripts to your Deployment Unit
When a release is deployed you should be able to identify from the Deployment Unit all the related hardware and software that is required to support the release. The Release Package is a good container for managing these relationships. The Release Package can either relate all this together in documentation form or better still reference entries in a database. Such a database should identify for each product that is built and released: the required hardware, supporting third-party software and the Installation and Configuration instructions. In the ITIL world such a database is often called the CMDB (Configuration Management Database).
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
- Best AI tools for Software Engineers - November 4, 2024
- Installing Jupyter: Get up and running on your computer - November 2, 2024
- An Introduction of SymOps by SymOps.com - October 30, 2024
