Home 
 1. Overview  
 What is Release Management?  
 How Release Management works  
 What does Release Management cost?  
 2. Implementation guide  
 Define what needs to be done  
 Prepare to implement  
 Implement (TT5293) 
 Review the implementation  
 Implementation resources  
 3. Operations guide  
 What needs to be done?  
 When does it need doing?  
 Who does it?  
 Operational resources  
 4. Toolkit  
 Examples  
 Templates  
 5. Roles and responsibilities  
 Release manager  
 Build developer  
 Acceptance tester  
 Installer  
 6. Review of Release Management (F070207) 
 Recap of Release Management  
 Checklist  
How Release Management works
Release Management Process Flowchart Release policy Definitive software library Release planning Release rollout Relationships with other processes
The Release Management process works by providing a consistent framework for defining and creating new services, and ensuring that the correct versions of tested and approved software are implemented on a day-to-day basis (that is, after initial rollout).  

It interfaces with the Change Management process to enable implementation and to the Configuration Management process to maintain configuration records.

The Release Management Process.ppt flowchart illustrates this.

For further details see the sections below:


Go back to Overview
Release Management Process Flowchart
graphic
Release policy
Release policy is the strategy adopted for implementing new services.  It can be complex or simple.

At a simple level, release policy may be the conscious decision to implement new computers only twice a year, for example, or to upgrade software in phases in a certain order such as by department.  It is a high level plan that is agreed and published in advance to set expectation.

At a complex level, release policy can relate to the actual development of software and determine frequency of new versions, version-numbering convention, types of release such as full or partial, and so on.  This applies more specifically to organisations with their own software development function.
Definitive software library
The definitive software library is a repository for storing released software and serves as the central point for obtaining versions of software for installation.  Its purpose is to distinguish between old and new released versions and any development software.

The definitive software library links to the configuration management database.
Release planning
Release planning is proactive technical support to ensure that software or hardware being deployed to users does what it is required to do when they receive it. Release planning includes design, build, test and acceptance.

Design
Design relates to the architecture of a new ICT service.  That is the configuration of the pieces of hardware and software involved. 
Build
Build is the compilation of components to form the service, such as the installation and set up of a new computer or the integration of a new piece of software with existing applications on the desktop.
Test
Test is the internal technical support testing that should be carried out to ensure that the service is stable and that other services have not been affected by its introduction.
Acceptance testing
Acceptance testing is functionality testing carried out by nominated users who are responsible for ensuring that the service does what is required.
Release rollout
Release rollout is the actual deployment of the new hardware or software.  The term 'rollout' implies the introduction of a new service to all or many computers or users, but release management techniques can and should be applied to individual installations.  Release rollout includes scheduling, training, communication, updating the definitive software library and checklists.

Scheduling
Scheduling is required for both the actual deployment of the service and any training that is required. Scheduling is particularly important for rollouts to more than one computer or user, but even one installation should be scheduled in accordance with the user's preference.
Training
Training should always be considered prior to a rollout of new hardware or software.  It may not always be necessary - for example if the rollout is of new computers to existing computer users, but it is good practice to take the potential need for training into account.
Communication
Communication is very important.  Users need to be made aware that changes are being planned and how the schedule affects them.
Update definitive software library
The correct version of software to be installed must be available and marked clearly in the definitive software library in time for rollout.
Checklists
The actual deployment should also be structured to ensure that all activities are completed and the rollout is consistent.  Checklists should be available for the installers to follow.
Relationships with other processes
Relationship with Change Management
The Release Management process interfaces with the Change Management process throughout its lifecycle.  Release management provides the inputs to the request for change at the various stages of planning and preparation.  Change management final approval should be received before the new service is deployed into the live environment.
Relationship with Configuration Management
The Release Management process links closely to Configuration Management.  The final step in the release of a new service or an upgrade to an existing service is to record the changes in the configuration management database.  This is facilitated by the Change Management process or the incident/request process as appropriate.
The definitive software library is also considered to be part of the configuration management database.
Top