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  
What needs to be done?
Installing builds Creating new builds Monitoring the Release Management process Making decisions
The day-to-day operational tasks in Release Management are:


Go back to Operations Guide
Installing builds
Build installation requests should eventually, through the implementation of FITS, be generated in two ways:

Process
Type of request
Further details
Incident/request process
Individual user requests
Incident Management
Request for Change process
Infrastructure requirements
Change Management

Before a build can be installed, you must create build and release build .  If the build has already been created and released, you can install it in accordance with the install build steps.
Creating new builds
New builds must be created as hardware and software is identified that has not yet had a build procedure created for it or if new types of hardware or software are introduced.

In either case the create build steps should be followed first and then the release build steps .
Monitoring the Release Management process
It is important to monitor the Release Management process to ensure that it is working.  For example, the release manager needs to know that progress is being made on the number of standard build procedures being created and it is a good idea to get an overall view of the volume of installs being carried out on a regular basis, such as monthly.

The following measurements should be easy to gather and report on:
  • number of builds installed in period
  • number of builds created in period
  • total number of builds documented
  • total number of services in school
  • number of services remaining to document.

To get started on some simple measurements and reporting, download our Release Management report template  with graphs produced in Excel. Follow the instructions to fill in the volumes and check that the print range is set before printing.

You can also view an example Release Management report  with dummy figures can be viewed by clicking on the link below.
Making decisions
The purpose of the reports is to help you to make decisions.  They must be interpreted to identify any areas for concern that need to be addressed. Remember that they are just statistics and should not be taken at face value.  See them as the basis for asking questions, not as outright answers.  Also, don't look at them in isolation: consider the bigger picture when reviewing reports and look at the reports from other processes, such as Incident Management. 
  • A reduction in the number of build procedures created from one month to the next may be a result of a higher-than-usual volume of incidents keeping ICT staff busy, or it may be due to ICT staff absence, or it may be because there are no builds left to document.
  • A reduction in the number of builds installed from one month to the next may be the result of a reduced number of requests or because there is a backlog of more urgent work.
  • An indication that there are no services left to document may be true or it may mean that the total number hasn't been updated with new services introduced since the beginning of the Release Management implementation.

These are just examples to illustrate that statistics should not be taken at face value.  Talk to the process participants and consider other related factors such as incident activity to understand the reality of the situation.
Top