CM Coffee Break Site - Add it to your Bookmarks

 
  Unified Configuration Management  
Home | CM Survival | The CM Portal  | CM About Us | Email
 

 Release Request Form   

 

Surprisingly, an often neglected activity of Configuration Management is deployment control i.e. ensuring changes are authorized, have been sufficiently controlled and sufficiently tested. Typical symptoms of environments without such controls include:

  • Instability
  • Frequent Re-Releases
  • Production Down Time
  • Cost to business

To help resolve these problems it is recommended that release request forms are implemented to enhance communication and ensure authorisation. Below an example paper release request form is provided. Note we would strongly recommend larger sites look for an automated equivalent.

 

 
 

RELEASE REQUEST FORM

1. PROJECT DETAILS

Application

Enter the application/product name

Project Stream Name

Enter the project/steam name

Package/Baseline Details

Enter Package/Baseline Details

Activity Number

As part of UCM, an activity number should be related to releasable artefacts. Typically a single activity number (Work Activity Request) may be made up of a number of Change Requests and Defects. Often companies baseline code with activity number to ease association.

Destination Environment

Enter destination life cycle environment i.e. System, Acceptance Test or Production. For clarity also include specific system domain names.

Project Leader

Enter project Leader Name

Test Manager

Enter Test Manager Name

Date Release Raised/Requested

Enter date that this request was first raised.

Planned Release Date

Enter planned Release Date (& time if applicable)

Technical Contacts

Identify main support engineers

Authorisation

The section below should be used to authorise the release. The configuration board should agree on who should be empowered to authorise releases into official space.

A full signature set is required before a release can be progressed.

Project Representative: 

 

Signature:

 

Business Representative: 

 

Signature:

 

Configuration Manager: 

 

Signature:

 

Test Manager: 

 

Signature:

 

 


2. CHANGE RELEASE SUMMARY

Release Overview

This section should outline primary reason for release.

Business Changes

This section should outline changes form a business (user perspective)

Technical Changes

This section should outline changes from a technical level.

Other Approval Comments

This section should outline any comments that will support release approval and improve configuration management.


3. RISK ASSESSMENT

Business Risk

This section should be used to overview perceived business risks.

Known Problems

This section should be used to declare known problems with release.

4. BUILD & RELEASE INFORMATION

Build/Kitting Details

This section should outline how building and kitting should be achieved.

Release Instructions

This section should detail special pre-release steps, primary release steps and special post release steps.

Release Roll Back Plan

Describe how a failed release could be rolled back i.e. system recovery steps.

Post Release Test Plan

Describe how we test whether the change was successful.   

5. ACCEPTANCE SUMMARY

Acceptance Details

This section should highlight how release came to be accepted for release into official space. This section should summarise all testing details.  

** End of Document **


Copyright © 2002 SnuffyBear Company (Sydney Australia).