Release management is an important process in the ITIL Service Transition stage of the ITIL lifecycle. ITIL foundation training discusses this process in detail. To fully understand why it is so important, it is necessary to understand what a release unit is. Furthermore, as one would learn in an ITIL course, the release management process is dependent on a thoroughly defined release policy. This article discusses release units and release policies.
Release management: What is a release unit?
A release unit is a bundle of components of an IT Service that are normally released together. Services, components, applications etc. are useful only if they serve together for the benefit of end customers. Otherwise, the success of a service itself will not be creating value to the customer as long as the other parts of the release unit are not successful. A release unit provides a function and value for the customers with all its services, components, assets etc.
Release Management: Examples of release units
For instance, one release unit could be a desktop PC, including hardware, software, licenses, documentation etc. A desktop PC itself will not be used without an operating system for the end users. Or a PC will not serve for writing text without a text editor software. Or a PC will be vulnerable to threats without an antivirus software. Therefore, software, hardware, licenses, and documentation of a PC together form a release unit and delivers value to the customers. Release management ensures that all the necessary components of a release unit are accounted for. Furthermore, Release management ensures that the correct release units are rolled out.
Release Management: Complexity of release units
Release management sometimes deals with a complex roll out of release units. This table shows two examples of release units in release management. First, the IT service example is Homepage. The scope and complexity of changes of this service can be the replacement of some pages i.e. only changes in the text and the adding of links. Since this will be a low complexity change, low resources and only a little time are needed for testing this change after the implementation. If you consider a changed homepage, it is useful with its texts, pictures, content, navigation links etc. therefore it qualifies a release unit according to the release management process. Similarly, the second IT service is Geographical Information System which is a high complexity change according to the release management. The possible release unit for this can be the whole application including manuals.
Release management: criteria of a release policy
We have seen that policies define the rules and to-dos in a process. Release policies are part of the release management process. The release policy in an IT service provider aims to help transition planning and support. There are several criteria that a release policy must meet.
Unique identification, numbering and, naming conventions
The release policy should include a unique identification, numbering and, naming conventions. There will be several services, components, applications etc in an IT service provider. In order to refer each asset, and version of each asset, proper identification, numbering and naming conventions must be used. For instance, services starting with one digit belongs to core banking, services starting with two belongs to internet banking, services starting with three belongs to ATM channel etc is a very simple example of a convention for identifying services in a bank with their first digits.
Roles and responsibilities
In any process such as release management, roles and responsibilities must be clearly defined. Roles and responsibilities for each phase must be clearly documented in the release policy. For instance, release management roles and responsibilities can include: the person who will build the release, test it, and the department will do the deployment. These kinds of roles and responsibilities must be clear in the release policy.
Expected frequency of release types
Release management requires that the expected frequency of release types is included in the release policy as well. For instance, a release to the production can be done monthly in a corporate organization and each change that will be deployed on production must be planned in that release. And in the case of an urgent problem, daily releases can be deployed onto production for fixing the issue. These kinds of planned releases and frequency are defined in the release policy as part of release management.
The approach for accepting and grouping changes into releases
For instance, an IT service provider can say that only tested services can be planned for production if more than 5 days passed after the tests finished. Or an urgent fix can be planned only if the senior IT director approves it. These kinds of approaches for planning changes are defined in the release policy.
The mechanism for the building, installation and release deployment processes
For instance, some organizations use automatic deployment tools, especially for the development environments. At a predetermined time, services, components, and assets are built automatically by the tool. These kinds of mechanisms are defined and described in the release policy.
Defining a configuration baseline for releases
Configuration baseline records a state for the configuration items, services, components, and assets in an IT service provider. In the case of a failure during deployment, the last working state of the services can be restored from the configuration baseline. Therefore, release management requires that the method with which the configuration baseline can be used is defined in the release policy.
Exit and entry criteria and authority for acceptance of the release into each Service Transition stage
According to the release management process, a decision authority, a department, a responsible or a manager in the IT service provider can have the rights to reject releases. These kinds of authorities and decision-takers are defined in the release policy.
Criteria to exit from early life support is defined in the release policy
After a release is implemented in production, a predetermined period is assigned as early life support. For instance, 2 weeks, 1 month or 2 months. And during this period, the IT service provider monitors the services to see whether the agreed service level targets will be met. In the case of necessity, revisions in the service level targets are done, problems occurring in the production are fixed by the IT service provider in order to leave a healthy release to the operation.
Release management relies heavily on comprehensive release policies. Release policies assist service managers in ensuring that services can pass through the ITIL service transition stage to the ITIL Service Operation stage. The release management process defines release units as all the components of a service that are released together as a single unit. Release management ensures that the components of release units function properly so that the unit can be released for public use.
