Release Management
Basic Concepts
A release is a group of new or modified CIs which have been validated for installation in the live environment. The functional and technical specifications of a version are defined in the corresponding RFC.
Releases may be classified, according to their impact on the IT infrastructure, as:
- Major releases: representing a significant roll-out of hardware and software and which introduce important modifications to the functionality, technical characteristics, etc.
- Minor releases: these usually entail the correction of one or more specific errors and are often modifications that implement documented emergency solutions correctly.
- Emergency releases: modifications repairing a known error quickly.
As there may be multiple versions it is worth defining a reference or code unambiguously identifying them. The universally accepted system is:
- Major releases: 1.0, 2.0, etc.
- Minor releases: 1.1, 1.2, 1.3, etc.
- Emergency releases: 1.1.1, 1.1.2, etc
Although in some cases this classification is further refined (see, for example, the help in the version of your browser).
During its life-cycle a release may go through various states: development, testing, live and archived.
The diagram below illustrates the progress of a release over time:
New versions can be rolled out in different ways and it is the responsibility of Change Management to decide the most appropriate way of proceeding. The most common options include:
- Delta release: only the modified components are tested and installed. This option has the advantage of greatest simplicity, but it entails the risk that problems or incompatibilities may arise in the live environment.
- Full release: All the affected components are distributed, whether they have been modified or not. Although this option obviously involves more work, provided the relevant tests have been done, it is less likely that incidents will occur after installation.
- Package of Releases: Change Management may opt to distribute different packages of releases in a synchronised way. This offers greater stability in the IT environment. In some cases this option is unavoidable due to incompatibilities between a new version and previously installed hardware or software. Consider, for example, a migration to a new operating system requiring more advanced hardware and/or new versions of office automation programs.
DSL
The Definitive Software Library (DSL) must hold a copy of all the software installed in the IT environment. This includes not just operating systems and applications, but also device drivers and any associated documentation.
The DSL should contain the complete release history of each piece of software in order to provide the necessary version in the event that back-out plans should be implemented.
The DSL should be stored in a secure environment and it is advisable to perform periodic back-ups.
DHS
The Definitive Hardware Storage (DHS) contains spare parts for the CIs in the production environment.
The assets stored must be included on the CMDB if the corresponding CIs are listed on it (this may depend on the scope and level of detail of the CMDB).
