Release management
The objective of Release management process is to define and agree with customer and all the stakeholders production deployment plan, ensure that each release contains all the necessary components that are compatible and secure user training and transfer of knowledge to teams that will support the new services.
Release management
The objective of Release management process is:
- To define and agree with customer and all the stakeholders deployment plans.
- To ensure that each release package consists of a set of related assets and service components that are compatible with each other.
- To ensure that all users are trained and knowledge is transfered to all the teams that will support new services in future.
The process of deployment is performed according to ITIL v3 in step Coordinate implementation of the process Change management. In this step Release management process follows the process Test management. ObjectGears offers following process meeting ITIL requirements and representing an efficient way of a managed deployment in model IT.
Every Change request is assigned to a particular Release, that defines Environment, which it relates to, is planned in the Work schedule and defines Release package that shall be deployed. The Release package defines which versions of which configuration items shall be deployed in order that Release integrity (completeness of configuration items and their compatibility) is ensured.
When designing change release plan we can meet following situations:
- A lot of changes included in a single release - it leads necessarily to many dependencies that are difficult to manage. If a problem occurs during release, it is difficult to assign to a particular change that caused it.
- Few changes in a single release - it results in a time-consuming activity (fewer changes are deployed within the given period of time) and wasting resources, that participate in releases.
Solution to this situation is split of releases in several types that differ in complexity and frequency. The table stated below represents an example. It will be adjusted to needs of each particular organization.
| Release type | Description | Changes included |
| Primary release | Planned in advance. Quarterly frequence. | Type A, B, C |
| Secondary release | Planned in advance. Bimonthly frequence. | Type B, C |
| Emergency release | Unplanned. Emergency fixes. | Emergency (Hot fix) |
Release type determines type of the change that can be deployed within the release.
| Change | Description |
| Type A | It affects the whole system of the given service. It has broad dependencies and impact on other systems. |
| Type B | It affects part of the given service system. It has limited relations to other systems. |
| Type C | It affects particular functions of the given service. It has no relation to other systems. |
| Emergency (Hot fix) | It solves service continuity after previous change that caused service deterioration. |
Examples of screens
Release
(Release management processes correspond to the size of organization and need to coordinate change releases probably more than others. Below stated screens represent a simple, effective concept. In case of need for a more complex solution workflow and formal approval process can be involved.)
Release contains information about who approved it, who takes care of its coordination, when it is deployed, what is the type of release and what changes the release introduces. In the bottom part of the screen there is a list of tasks issued within Release organization and an overview of configuration items it involves.
Configuration item in Release
Configuration item in Release contains information about person that will release it, version and time of release.