$ Originally from UCM Central[This template was based on the IEEE template IEEE 828.1:1990] :
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 authorization. Below an example paper release request form is provided. Note we would strongly recommend larger sites look for an automated equivalent.
RELEASE REQUEST FORM1. PROJECT DETAILSApplicationEnter the application/product nameProject Stream NameEnter the project/steam namePackage/Baseline DetailsEnter Package/Baseline Details.
Activity NumberAs 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 EnvironmentEnter destination life cycle environment i.e. System, Acceptance Test or Production.For clarity also include specific system domain names.Project LeaderEnter project Leader NameTest ManagerEnter Test Manager NameDate Release Raised/RequestedEnter date that this request was first raised.Planned Release DateEnter planned Release Date (& time if applicable)Technical ContactsIdentify main support engineersAuthorisationThe 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 SUMMARYRelease OverviewThis section should outline primary reason for release.Business ChangesThis section should outline changes form a business (user perspective)Technical ChangesThis section should outline changes from a technical level.Other Approval CommentsThis section should outline any comments that will support release approval and improve configuration management.3. RISK ASSESSMENTBusiness RiskThis section should be used to overview perceived business risks.Known ProblemsThis section should be used to declare known problems with release.4. BUILD & RELEASE INFORMATIONBuild/Kitting DetailsThis section should outline how building and kitting should be achieved.Release InstructionsThis 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 SUMMARYAcceptance DetailsThis section should highlight how release came to be accepted for release into official space. This section should summarise all testing details.** End of Document **