|
|
||
| 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:
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. 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.
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 PlanDescribe how a failed release could be rolled back i.e. system recovery steps. Post Release Test PlanDescribe
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). |