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  
When does it need doing?
Installing builds Creating new builds Monitoring the Release Management process Making decisions

Go back to Operations Guide
Installing builds
You need to install builds when:
  • a user requests a new item of hardware or software
  • a new infrastructure item is to be introduced.

Scenario 1
An individual user requests a single piece of software for use on their computer. 
A technician follows the build procedure and build install checklist for the application in question and installs it as requested.
Scenario 2
A new file server is required to increase capacity. 
A technician follows the build procedure and build install checklist to install the file server operating system.

Build procedures should be used always to ensure consistent installations and to help eliminate recurring incidents.
Creating new builds
You need to create new builds when:
  • you receive a request for an installation that has not yet been through the process of testing and documenting.
  • a request is received for a new type of hardware or software not previously installed.

Scenario 1
A new model of desktop computer is launched and models previously purchased by the school become obsolete. 
When the first new one arrives, a new build procedure must be created to test the computer with software and other hardware already in use and to establish a standard procedure for installing subsequent deliveries.
Scenario 2
The ICT co-ordinator decides to implement a new Spanish language software product in the school's language laboratory. 
The technician(s) involved in the project create a new build procedure for the software to ensure that it works as expected and doesn't cause problems with other applications. 
The new procedure is later used in conjunction with the install build checklist to roll out the product to all of the language lab computers.

Ad hoc effort should be minimised where possible, by planning to create build procedures for all existing services.
Monitoring the Release Management process
The Release Management process should be monitored regularly as soon as possible after introducing it.  The initial period will focus on developing and documenting builds and it is important to see how much progress is being made.

Because developing and documenting builds is a proactive activity time must be set aside to achieve it, although it is easy to let these types of activity go undone in favour of reactive work.  It is the release manager's responsibility to ensure that sufficient time is devoted to the Release Management process.

We recommend that, once the release management activities have begun, our report be completed every week or month.  The right frequency for your school will depend on the volume and frequency of your release management work.  You may decide to start slowly and produce reports monthly but then ramp up to a higher turnover, at which point weekly reports may be more appropriate. 

Match your reporting frequency to your work throughput and adjust the frequency in a planned way.  Don't chop and change, as this will distort the measurements and make it difficult to see trends.
Making decisions
All reports should be reviewed as soon as they are produced.  It is important to identify issues as soon as possible so that corrective action can be taken.

If investigative work is required to identify the cause of issues, this will be harder if the trail is cold.
Top