Release Management

What it is

Objectives

Promised Performance

Client Obligations

Version 2.0

1. Description

The process of coordinating and managing releases to a live environment. The process includes planning, testing, and implementing. This process ensures that releases are implemented in the live environment as quickly as possible in order to meet business requirements. It also ensures that releases are implemented in a controlled and systematic way that limits negative impacts to the IT environment.

2. Objectives

to design and implement efficient procedures for the distribution and installation of Changes to IT systems
to ensure that hardware and software being changed is traceable, secure and that only correct, authorized and tested versions are installed
to reach agreement on the exact content and roll-out plan for a Release, through liaison with Change Management
to implement new software Releases and/or hardware into the operational environment using the controlling processes of Configuration Management and Change Management - a Release should be under Change Management and may consist of any combination of hardware, software, firmware and document
to ensure that master copies of all software are secured in the Definitive Software Library (DSL) and that the Configuration Management Database (CMDB) is updated
to ensure that any hardware being placed into production or changed is secure and traceable, using the services of Configuration Management.

The focus of Release Management is the protection of the live environment and its services through the use of formal procedures and checks.

3. Service Commitments

??? Releases per quarter
average of 2 problems per release in the live environment that can be attributed to new releases, - which need only be measured during the first few months of a new Release's life, classified by root cause, (e.g.'wrong version of file' or 'missing files')
2 new, changed and deleted objects introduced by the new release - e.g. how many modules and programs
95% of releases completed in agreed timescales

How are we doing ?

4. Client Obligations

business unit participation in product releases
Users to report all incident and problems encountered following a release

5. Client Costs

Costs are paid through an annual appropriation to the ebcIT Division through the Ministry of Labour as negotiated during the annual government-wide fiscal budgeting process.

6. Dependencies

95% of releases completed in agreed timescales - this requires the central Release Management function to publish predefined targets (service levels or SLAs) for software distributions and other common tasks
Whenever new versions of software are added to the DSL, its details should be simultaneously included in the CMDB. Similarly, whenever new or changed hardware is rolled out, the CMDB should be updated. The CMDB should always contain the current status information on all authorized software and hardware and is used to ensure that only the correct components are included in a Release,
ebcCAB, with advice from Release Management, is responsible for recommending the content and scheduling of Releases. Release Management is then responsible for implementing the agreed Releases. Release Management is normally represented on the CAB and is involved in establishing the organization's release policy,
When software is accepted from developers or suppliers, it is placed into the DSL and registered in the CMDB. Release Management is responsible for building Releases from the DSL into the controlled test environment. When testing has successfully concluded, Release Management should distribute the Release into the live environment,
At the end of the successful distribution and installation of a new Release, various records in the Problem Management system need updating as follows:
- any related Problems or enhancement requests should be closed
- any known Problems introduced the new Release should be added to the database to allow Service Desk staff to support the new Release
- Problem Management and Service Desk staff should be informed of the new Release so that they can support its use in the live environment. Such staff should receive training in any new or revised support procedures.
Problem Management staff are also often involved in identifying faults that will lead to Requests for Change (RFCs) and so eventually lead to new Releases

7. Activities

Release Planning - planning a Release involves:
- gaining consensus on the Release contents
- agreeing to the phasing over time and by geographical location, business unit and Customers
- producing a high-level Release schedule
- conducting site surveys to assess existing hardware and software in use
- planning resource levels (including staff overtime)
- agreeing on roles and responsibilities
- obtaining detailed quotes and negotiating with suppliers for new hardware, software or installation services
- producing back-out plans
- developing a quality plan for the Release
- planning acceptance of support groups and the Customer. Release planning inputs include:
- project life-cycle
- service-related deliverables
- authorized RFCs
- Release policy
- an overview of business needs
- constraints and dependencies
- CAB output
- templates.
Designing, building and configuring a release - Procedures should be planned and documented for building software Releases, reusing standard procedures where possible. A configuration of a particular Release of software and hardware maybe based upon a set of available components, some of which may be developed in-house and others bought in. The instructions to assemble a Release in this manner should be considered part of the definition of the Release and treated as a controlled CI.
Release acceptance - testing of the Release should be performed by independent business staff and involve IT staff to verify any changed support procedures. Any back-out procedures should be tested as part of this activity, which should prove that the built Release can be installed and run as required. This includes testing both the installation procedures and the function of the final system,
Communications, preparation and training - Customer liaison staff, Customers and support staff need to know what is planned and how it might affect them. This is normally accomplished through training sessions, periods of parallel working, and involvement in the Release acceptance stage. Problems and Changes that need to be made during rollout should be communicated to all parties to keep them informed and to set their expectations. This activity normally includes running a series of rollout planning meetings with all of the interested parties to ensure that the plans are properly reviewed, checkpoints are established and all parties agree their responsibilities,
Distribution and installations - distribution of the software Releases from the build environment into the controlled test environment and then into the live environment should be accomplished with any associated hardware or co-requisite changes,

8. More Information

Responsible for Service Management, delivery and accuracy of this Catalogue item: Sheila Sullivan, Release Manager