Article: AN0001985Updated: 26.01.2019
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 Releae 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 particpate 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 |
Release description |
Type of change it can contain |
| Major release |
Planned in advance. Release frequency once a quarter. |
Type A, B, C |
| Minor release |
Planned in advance. Release frequency once every two weeks. |
Type B, C |
| Emergency release |
Not planned. It is determined for deployment of emergency corrections. |
Emergency (Hot fix) |
S typem release pak souvisí typ změny, která v něm může být nasazena.
| 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. |
There are several roles acting in the process. Process activities are captured in the below scheme.
