Release Management


Release Management aims to provide new or to update services and CIs defined by a Service Portfolio Management and/or Change Management for the production environment. It also aims to assure their integrity and functionality as defined by the Service Description. Release Management is only triggered by the Change Management Process


  • release a new software product
  • release a new hardware model
  • release a new version of existing software product
  • release a new version of existing hardware model
  • release a service with new functionality

Roles & Functions

Release Management Specific Roles

Static Process Roles

Release Process Owner
  • Accountable for:
    • the process design
    • the process goals
    • the process resources (including human resources)
    • continual improvement of the Release Management Process
Release Process Manager (Release Manager)
  • Responsible for:
    • the success of the process
    • control over all releases
    • further development of the process
    • definition of the roles in the process
    • planning and implementation of the Definitive Media Libery (DML)
    • planning and establishing the general release policies
Release Management Staff
Staff that supports the Release Manager. Acts as release owner and/or release agents

Dynamic Process Roles

Release Owner
accountable for one release.
Release Agent
responsible for one or more tasks during a release

Service Specific Roles

Roles depending on the affected service are found in the Service Description. The Service Description, including the service specific roles, is delivered from the Service Portfolio Management.

Service Expert/Service Specialist
They can consult and/or act as

  • Release Builder
  • Release Tester
  • Release Roll-Out Manager
Service Owner

Information artifacts

Release Record

  • UID
  • Change
  • Service
  • CI
  • Release owner
  • Release agent
  • Emergency release
  • Release Unit
  • Release Version

General Release Policy

A set of documents and policies describing:

  • General Release planning framework
  • General Release definition and testing procedures
  • General Release documentation and package definition

These documents are not service related but are based on general IT and company policies and governance.

Service Specific Release Policy

These policies are service oriented and depend on the Service Design Package. They provide service related:

  • Release building and testing descriptions
  • Release documentation specifications

Release Package Documentation

This is a basic outcome of the Release Management process, and contains:

  • Release description:
    • What is the objective of a release? What are the main topics addressed?
    • What are the major functionalities?
    • What are the new functionalities/ features of the release (when compared to the old release)?
    • What are main issues/ problems/ incidents solved by a release?
    • Technical specification/ codes etc.
    • Manuals/ User documentations
  • Release testing description:
    • Description of tested functions and testing procedure
    • Description of testing environments
    • Description of other testing prerequisites
  • Release fallback description
  • Release implementation procedures

Key Concepts

Release, Release Types, Release Storage

  • Release: implements an authorized Change by providing new CIs
    • Release by Importance:
      • Major Release – roll out of new hardware and software, generally with significantly increased functionality – including workarounds and quick fixes
      • Minor Release – releases with minor updates and quick fixes
      • Emergency Release – quick fix for a problem or known error
    • Release by Range:
      • Delta Release – includes only changed hardware and/or software components/ sub systems
      • Full Release – will include changed/ upgraded parts and unchanged parts/ components
      • Package Release – combines diverse releases into a bundle
  • Release Storage
    • DML Definitive Media Library – repository for released software and hardware items (spare parts)

Release Unit

Describes the portion of service or IT infrastructure that is released. This unit may vary depending on the specific situation, service and other relevant factors. Each unit can be identified by a unique identifier.

Release Approach

Different release approaches are possible and can be used. Basic approaches can be separated by deployment method, distribution method or automation level:

Deployment method – Big bang versus phased approach

Big bang method stands for the deployment of a designed service to all relevant users, locations and service takers at the same time. In a phased approach, the implementation is done step-by-step e.g. addressing region by region.

Distribution method – Push versus pull

Push approach stands for the forced deployment of a new service to all relevant machines, users or regions. In the pull approach, the new service is implemented „on request“ i.e. the request comes from the person asking for the service implementation

Automation level – Automation versus manual

Implementation can be provided automatically (e.g. in case of software distribution models, where the user is not asked to initiate the process) or manually.

Test Strategy

One of the main duties of release management is to monitor the testing of services and applications. Prior to release, testing is performed by release management. After release, change management undertakes the actual implementation. The tests must be carried out in the staging environment and not in the live environment. All test results must be documented within the corresponding release record, which is then made available for change management. Depending on the test results, change management will either authorise implementation in the live environment or refuse authorisation.

The release test strategy for a new service should contain the following test types:

  • Functional Test

This tests that the functions of services and applications are executed correctly. This applies to both the functions of old and new releases. In the case that functions are deleted with the change of a release, then the deletion of the corresponding tests must also be noted in the test plan. If it is appropriate, the future users of services and applications should be involved in the functional tests. This is to ensure the usability of the new services. If it is not necessary to involve users in a functional test for a release, then this must be agreed by the release manager and the justification must be entered into the corresponding release record. It is important that functional test not only tests the functions of the service itself, but also tests all interfaces to other necessary sub-services. It is important that the data transmission is complete, accurate and valid.

  • Implementation Test

This tests the implementation plan, which states how the new service or application is to be implemented in the live environment.

  • Fallback Test

This test ensures that if a complication should occur during implementation in the live environment, then a fallback is possible from the new release version to the old release version. Furthermore, the fallback test describes possible complications and the measures which can be taken to counter these.

NB: The tests in the live environment depend upon the functional test. It is not reasonable to test the implementation plan and the fallback plan in the live environment. During change management’s post implementation review, it may become obvious that the functional tests in the live environment failed. If this is the case, then the fall back plan has to be be executed.


High Level Process Flow Chart

Critical Success Factors

  • The process is to be carried out in every case (e.g. there are no exceptions, even in case of emergency situations)
  • Balance of the time to market versus the time for testing
  • Integration with Change and Configuration Management
  • Communication with Application Management

Key Performance Indicators (KPI)

  • Details from audit
    • on schedule?
    • in line with the budget?
  • Ratio of Fallback/total numbers of releases
  • Statistical information about DML
  • Growth rate of DML
  • Total numbers of Known Errors in the approved software

All KPIs can measured per service, per user, per customer, per location, per category etc.

Process Trigger

Event Trigger

Process is triggered by

  • In case of regular releases: a request from Change Management Classification activity
  • In case of emergency releases: a request from Change Management Emergency handling activity

Time Trigger

  • Release Management is not time triggered

Process Specific Rules

  • every Release must be documented in a release record
  • the Release Agent is responsible for documenting the activity
  • the Release Owner must control the Release Agent
  • the Change Owner, who is responsible for the change which triggered the release, must be informed
  • the subsequent Release Owner or Release Agents must then be recorded in the appropriate attribute in the Change Record.
  • the Release Owner and Release Agent should preferably be a person rather than a group.
  • refer to the Service Design Package for service specific release rules

Note: for the different types of rules see Rules.

Process Activities

Release Planning

Release Planning is part of and linked to the overall Service Implementation Plan.

Its objective is to define guidelines which translate specific service and component releases into production; and to define and manage an overall consolidated release plan of all components during a particular time period.

Specific service related release planning needs to be defined in cooperation with the Change Management and should contain:

  • Release description, objective, scope and plan
  • Risk assessment for the release
  • Resources affected by the release and resources needed for the release
  • Other services affected by the release
  • Criteria for release approval and fallback scenarios
  • Release Roll-Out plan

Activity Specific Rules

  • set Release Owner & Release Agent to a member of the Release Management Staff
  • check if release is nessecary according to the Release Strategy
  • if not, go to control activity „canceled“
  • otherwise
    • set Change according to the Change ID triggering the release
    • set affected CI and Service in the release record
    • select the right Release Unit
    • define the Release Version.
  • if it is an emergency release set „emergency release“ to „true“ and go to control activity „accepted – emergency“
  • otherwise
    • create release plan
    • go to control activity „accepted – planned“

Release Emergency Handling

In the case of emergency changes which have to be dealt with by Release Planning, this general rule should never be violated: „No matter how urgent a release is, it has to to pass through Release Management„.

The main activities in Emergency Handling are:

  • Description of the function and content of the emergency release
  • At least basic testing of the release (including component and integration testing)
  • Documentation of the emergency release
  • Storage of the release in DLM

Compared to regular Release Management, the main difference of an Emergency Release is that it is not planned before and needs to be implemented urgently. Therefore it requires reduced testing efforts. Often the necessary testing, documentation and monitoring agents can not be assigned. Finally an emergency release is not planned within overall Release Planning, therefore it forces a change in the overall planning. An Emergency Release is managed in line with the Emergency Change activities.

Activity Specific Rules

  • set Release Owner to the Release Manager
  • verify Emergency Release status
  • if Emergency Status is confirmed
    • set Release Builder, Tester and Relase Roll-Out-Manager to a Service Expert/Specialist
    • create Emergeny Release Plan
    • execute Emergeny Release Plan
    • document Emergeny Release
    • go to control activity „released“
  • else go to control activity „new“

Release Building

This sub-process defines, tests and implements an approach to build, test and implement a service defined in SDP.

Activities are:

  • Definition of build plan and approach, including scheduling and organizational design – based on the SDP, SLAs and additional commercial agreements with the customer
  • Build the release according to the defined plan
  • Define testing procedures, environments and policies (especially the „go“/ „no go“ criteria for testing)
  • Define resource needs, request resources and implement the necessary organization (including financial resources)

Standard Building Approaches in IT-Development:

  • Waterfall model: Stage oriented building model with „go“/ „no go“ decision gates between the stages. Service is developed step-by-step. Classical IT development model.
  • Pilot implementation: Service is developed by more and more improved pilots of the service. Pilots of a pre-phase are NOT re-used as a basis for the next stage.
  • Rapid Application Development: The service is improved later stage by stage. This model focuses on short development time.

Standard Environments for IT-Development:

  • Build environment: Isolated technical environment for development only.
  • Testing environment: Isolated testing environment for testing only. This may be different from development and production environment.
  • Production environment: Environment where the final developed service is deployed and used by the end user.

Activity Specific Rules

  • set Release Builder according to the Release Plan
  • set Release Agent to Release Builder
  • build Release
  • go to control activity „built“

Release Testing

The Release Testing takes place after the release has been implemented in the test environment. The Release Tester should be different from the Release Builder

  • Create, test and implement the build in the testing environments (including assessment of the specific development and building tools, as well as the basic tools to run the services developed)
  • execute the testing according to the defined plan

Activity Specific Rules

  • set Release Tester according to the Release Plan
  • set Release Agent to Release Tester
  • Release Tester and Release Builder must not be the same person
  • test the Release
  • if test is successful go to control activity „tested – successful“


  • go to control activity „tested – unsuccessful“ or „canceled“ for a final abortion of the process instance

Release Validation

After the Release Testing, the result must be validated. If the results fail, Release Building and Testing will be triggered again. The Change Management must also be informed about the test result. The appropriated Configuration Items must be updated in the CMDB.

Activity Specific Rules

  • set Release Agent to Release Owner
  • Verify Release according to the Release Plan
  • verify and Release & Test documentation
  • manage DML
  • inform Change Management
  • go to control activity „released“ if verification is positive
  • otherwise go to control activity „canceled“ for a final abortion of the process instance
+49 89 - 44 44 31 88 0