City of Release Management Policy

Raleigh Rev. 1.0, 01/05/2009

IT Department

Release Management Policy

Revision 1.1 Page 1 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

Table of Contents

1 Purpose ...............................................................................................................................................3
2 Application....................................................................................................................................................3
3 Scope.............................................................................................................................................................3
4 ITIL Release Management...........................................................................................................................3
4.1 Related processes...................................................................................................................................3
4.1.1 Change Management.......................................................................................................................4
4.1.2 Configuration Management............................................................................................................4
4.1.3 Service Request (V3)......................................................................................................................4
5 Release Management Definition...................................................................................................................5
6 Release Management Flow...........................................................................................................................5
6.1 Quality Assurance and the COR............................................................................................................6
7 Components of Release Management...........................................................................................................6
7.1 Roles.......................................................................................................................................................6
7.1.1 Release Manager.............................................................................................................................6
7.1.2 Build Developer..............................................................................................................................7
6.1.3 Acceptance Tester...........................................................................................................................7
6.1.4 Installer............................................................................................................................................8
6.1.5 Release Management Committee....................................................................................................8
7.2 Tools.......................................................................................................................................................8
7.3 Definitive Media Library (DML)...........................................................................................................8
7.4 Release Categories.................................................................................................................................8
7.5 Release Types.......................................................................................................................................9
7.6 Data Requirements................................................................................................................................9
8 Release Management Process Flow............................................................................................................10
8.1 Stage Definitions..................................................................................................................................10
8.2 Process Flow........................................................................................................................................10
9 Release Management Process Metrics........................................................................................................12
9.1 Success Characteristics........................................................................................................................12
9.2 Resulting Expectations.........................................................................................................................12
9.3 Notable Achievements.........................................................................................................................12
9.4 Lasting Benefits...................................................................................................................................13
10 Release Management Metrics...................................................................................................................13
11 Modifications...........................................................................................................................................13

Revision 1.1 Page 2 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

1 Purpose
This document provides a policy to manage releases within the service environment for the City of Raleigh
Information Technology department (COR IT).

2 Application
This policy applies to all City employees, part-time and temporary workers, independent contractors and
those employed by others to work on COR information systems.

This process supersedes previous processes we have used.

We will review the definition of the Release Management processes and categories according to ITIL and
define what categories we need to utilize. Although we need not use all the pieces of ITIL defined in the
framework, wherever we do use a component, we will use the same terminology used in the ITIL
documentation.

This process will be continuously reviewed and modified as we gain experience and learn lessons. This
policy may be modified or amended through a formal review and approval process. The Release
Management Committee will hold lessons learned sessions to improve this process and to update this
document.

3 Scope
The primary goal of Release Management is to protect the production environment and its services using
formal procedures and checks to package and distribute releases successfully to the Customer.

4 ITIL Release Management

The Release Management policy is based on recommendations of the Information Technology
Infrastructure Library (ITIL) Foundations program. The City of Raleigh Information Technology (IT)
department has decided to use ITIL as the basis of our processes. Release Management is one of the
processes in ITIL.

4.1 Related processes

According to ITIL, Release Management interfaces with many other processes, for example, Problem
Management, Service Desk, Configuration Management and Change Management. This document will be
updated to reflect these interfaces as these other processes are developed.

Revision 1.1 Page 3 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

Figure 1

4.1.1 Change Management

The Release Management process interfaces with the Change Management
process throughout its lifecycle. Release Management provides the inputs to the
request for change at the various stages of planning and preparation. Change
Management final approval should be received before the new service is released
into the live environment.

4.1.2 Configuration Management

The Release Management process links closely to Configuration Management. The
final step in the release of a new service or an upgrade to an existing service is to
record the changes in the Configuration Management Database (CMDB). This is facilitated by
the Change Management process or the incident/request process as appropriate.
The definitive software library is also considered to be part of the Configuration
Management Database.

4.1.3 Service Request (V3)

The Release Management process interfaces with the Service Request
process throughout its lifecycle. Release Management can receive inputs from the

Revision 1.1 Page 4 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

request for service at the various stages of planning and preparation.

5 Release Management Definition

Release Management is the process of planning, building, testing and deploying hardware and software
including the version control and storage of software.
Objectives
– To protect the production environment(s) and its services through use of formal procedures and
checks to package and distribute releases to the Customer
– To ensure that a consistent method of deployment is followed
– Reduction of the likelihood of incidents because of rollouts and ensure that only tested and
accepted versions of hardware and software are installed at any time
Key Concepts
– Covers both hardware and software releases
– Changes to software are ‘bundled’ together for one release, which minimizes the impact of changes
on users
– Ensures that the execution of approved changes is coordinated and safe
– A structured approach to rolling out all new software or hardware, which is efficient and effective
– Version control and central storage of software, ensuring that correct versions are installed at all
times, which minimizes incidents and the need for reinstallation
– Covers both technical and non-technical sides of a release

6 Release Management Flow

Figure 2 outlines the basic “Release Management” process. In this diagram, the process steps and
relationship for Service Request, Change Management and Release Management are detailed. It is
important to note that Figure 2 does not reflect certain environments (e.g. Sandbox and Pre-Production)
which are outside the formal release management process.

Revision 1.1 Page 5 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

Figure 2

6.1 Quality Assurance and the COR

The Software Development Lifecycle (SDLC) and Release Management are interdependent activities that
are required by most Quality Assurance (QA) processes – irrespective of whether hardware or software
modifications are being delivered. A significant component of the Release Management activity is
performed during the formal QA discipline. A significant portion of QA work will reside in Release
Management and be managed accordingly.

The COR IT department is in the process of formalizing its QA organization and strategy. The relationship
of this QA organization with Release Management will continue to be refined.

7 Components of Release Management

7.1 Roles

7.1.1 Release Manager

– Responsible for Release Management and ensuring that the process is followed
– Is the process owner

Revision 1.1 Page 6 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

– Should have some understanding of the hardware and software being deployed
– Does not need to be very technical
– May be the person responsible for incident tracking and/or technical support
– Some activities may be delegated to a technician
Additional responsibilities include:
– Plans and schedules
– Software/hardware Defects
– Issues
– Risks
– Change Requests
– New Development Requests (additional features and functions)
– Deployment and Packaging

The Release Manager has two types of roles and responsibilities:

A. Individual Release Manager - a Release Manager shall be appointed for each release. This person is
responsible for packaging the release and coordinating disparate components, projects and teams
for timely delivery of software and hardware.
B. Enterprise Release Manager - this role may be created to own the Release Management process and
to maintain procedural integrity across all Releases. This role may help to identify, create and/or
implement processes or products to efficiently manage the Release process.

7.1.2 Build Developer

– Creates new builds
– Tests the stability of new builds and resolves any issues
– Tests the impact of new services on existing components of the build and resolves any issues
– Creates build procedures for all new hardware and software installation
– Stores software in the Definitive Media Library (DML) (Quest STAT)
– Stores technical and user documentation appropriately
– Liaises with acceptance testers to ensure service functionality
– Ensures that installers are aware of new build procedures
– Supports installers in the event of difficulties installing a product
– Must be a technical person

6.1.3 Acceptance Tester

– Tests the functionality of new hardware and software
– Takes the user perspective on whether the product does what it was intended to do
– Liaises with the build developer to identify test criteria and perform tests
– Should be familiar with subject matter but does not need to be technical
– Must be familiar with the requirements of the product being tested
– Is likely to be an end-user or member of the Q/A team
– Signs off before moving to production in the Definitive Media Library (DML) (Quest STAT)

Revision 1.1 Page 7 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

6.1.4 Installer
– Installs new release packages
– Must use the install build checklist and the appropriate build procedure to execute all installations
– Liaises with build developer for assistance if necessary
– Refers any issues with build procedures to Build Developer or Release Manager
– Is a technical person
– Will probably be involved in Incident Management
– Signs off before moving to test or production in the Definitive Media Library (DML) (Quest
STAT)

6.1.5 Release Management Committee

The Release Management Committee (RMC) will perform the following roles:
– Approve functional and technical code changes to be added to a release
– Approve functional and technical patches for application and technology stack updates
RMC may consist of representatives from the functional areas of IT, the Business Team, and
functional super users.

7.2 Tools
– Quest STAT will be used to automate portions of the release management process and function as
the Definitive Media Library (DML)

7.3 Definitive Media Library (DML)

The Definitive Media Library (DML) is a repository for storing released software and serves as the central
point for obtaining versions of software for installation. Its purpose is to distinguish between old and new
released versions and any development software. Similarly, it also contains hardware release information.
The DML will maintain within the Quest STAT tool purchased by the City.

7.4 Release Categories

This process may be adjusted for different Release levels.
Major
A Major Release usually introduces new capabilities or functions. Major releases may accumulate all the
changes from previous minor releases. Major releases advance the version number by a full increment, for
example, from version 5.70 to version 6.

Minor
A Minor Releases incorporate a number of fixes for known problems into the baseline, or trusted state, of
an item. Minor releases usually increment the version number at the first decimal place. For example,
version 6.10 would change to version 6.20.

Emergency

Revision 1.1 Page 8 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

Emergency Releases are quick fixes to repair unexpected problems or temporary measures to prevent the
interruption of critical services. Emergency releases increment the version number at the second decimal
place, for example from 3.1 to 3.1.1.

7.5 Release Types

Some releases of new versions of hardware or software introduce incremental changes, while other releases
include completely new versions. There are three types of releases to reflect different ways of bundling and
deploying changes to hardware or software configuration items together. These types are:
Delta Release
A Delta, or partial, Release is one that includes only those configuration items within the Release unit
that have actually changed or are new since the last full or Delta Release. For example, if the Release
unit is the program, a Delta Release contains only those modules that have changed, or are new, since
the last full release of the program or the last Delta Release of certain modules.

Full Release
In a Full Release, all components of the Release unit that are built tested, distributed and implemented
together.

Package Release
A Package Release rolls the changes to different configuration items into a single Release. This Release
may include changes to hardware and software configuration items and can contain delta and full
Releases. Package Releases minimize disruptions in the IT environment.

7.6 Data Requirements

Data requirements for Release Management are listed below. This data will be used to compile metrics for
measurement against the service level objectives. Each released object shall include the following
information and documentation:
• Unique reference number

• Release classification
• Date/time recorded
• Name/id of the person and/or group requesting the release
• Name/department/phone/location of User/Customers
• Release Manager
• Related Configuration item(s)
• New and Old item versions
• Support group/person
• Related Problem/known error
• Individual Rollback Plan

Revision 1.1 Page 9 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

• Resolution date and time

• Closure date and time
• Authorization by RMC
• QA data
• Post release audits
Multiple tools are under evaluation for implementing the Release Management process. As we configure
this tool, forms and reports may be created as needed to capture the release data.

8 Release Management Process Flow

This process flow assumes the following:
• There is a three stage environment in place
– DEVELOPMENT
– TEST
– PRODUCTION
• The following items are dedicated for each stage listed above
– Desktop/End-User devices
– Network
– Servers
– DMZ
– Applications

8.1 Stage Definitions

– DEVELOPMENT: Open to developers for coding, building, unit testing, functional testing and
configuration
– TEST: Secure environment for testing the release bundle deploy, integration testing, and
performance testing
– PRODUCITON: Secure environment for production processing

8.2 Process Flow

See the corresponding diagram, Figure 3.
– Code will be developed on the DEVELOPMENT environment and integrated
– The Build Developer will check the code into the Definitive Media Library (Quest STAT)
– The Installer will add all code from all of the Build Developers into a release
– The Installer will use Quest STAT to migrate the release from the DEVELOPMENT to the TEST
environment
– The Acceptance Tester will verify the changes in the TEST environment, validate all test cases,
validate the performance test, and approve the install for the release
– The Installer will migrate the release from the TEST to PRODUCTION based on the schedule
outlined by the Release Manager

Revision 1.1 Page 10 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

– The Acceptance Tester will verify the changes in the production environment and sign off with the
Release Management tool Quest STAT.

Code complete ?
Functional test complete ?
Unit test complete ?

DEVELOPMENT Yes
No

Individual Objects
and Code
Release is moved
TEST migrated to Quest STAT
to TEST
release object

Code move complete ?

Integration Test complete ?
Performance Test complete ?

Release is moved
No Yes PROD
to PROD

Code move complete ?

Repair object ? Roll back object ? Business verify complete ?

Yes No No Yes

No Yes

Release Complete

Figure 3

Revision 1.1 Page 11 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

9 Release Management Process Metrics

9.1 Success Characteristics
– Roles and responsibilities are assigned for the process
– All Release Management participants understand the process
– The Definitive Media Library is up to date
– Build procedures are created for all builds/objects
– All software and hardware installations are carried out in accordance with a checklist
– All software and hardware installation requirements are identified through the appropriate
processes
– Identification of any new build procedures as they are required
– Release Management reports are generated after each release
– Release Management reports are used to understand the use of the process, identify issues and make
decisions

9.2 Resulting Expectations

– Technical support staff document all software and hardware installations
– Technical support staff use build procedures and install checklists to install new equipment
– End-users do not install their own hardware or software
– Software is not installed if no license(s) are available
– The correct versions of software are always installed
– Software and hardware services are stable
– All new types of hardware and software are put through the Release Management process before
they are deployed

9.3 Notable Achievements

– A release policy describing the frequency and nature of upgrades
– Fewer ad hoc requests for new hardware or software
– All hardware and software installations have been tested and documented
– Hardware and software is installed consistently each time
– Less time is spent resolving incidents and problems caused by poorly installed hardware and
software
– All software is stored centrally
– Versions of software are the correct and current version
– All software licenses are consolidated
– Each software license is assigned to an owner

Revision 1.1 Page 12 of 13

 City of Release Management Policy
Raleigh Rev. 1.0, 01/05/2009

9.4 Lasting Benefits

– Planning for future releases is more efficient as a result of having a release policy
– Changes to software are handled more efficiently by bundling them together
– End-users suffer less frequent disruption caused by changes
– A repeatable process for installations that is quicker and less error prone
– Installing equipment in the same way each time makes support easier
– Software version control ensures that problems are not introduced through installing the wrong
version
– New technical staff can follow documented instructions created by predecessors so continuity of
skills is preserved
– Technical staff unfamiliar with particular software or hardware has documented guidance which
can help their personal development
– Resolution of incidents is quicker through fast reinstallation of builds
– Quicker resolution of problems is possible through comparison with standard build instructions
– Less time spent on incidents and problems means more time available for proactive support

10 Release Management Metrics

The following information will be collected for each Release:
– Number of test cases executed per stage and success rate
– Success rate meets acceptable parameters
– Number of objects changed/created
– Number of incidents reported for the release
– Number of objects rolled back for the release
– Timeline of release (On-Schedule, Delta)

11 Modifications
This Policy may be modified or amended through a formal review and approval process. The RMC
will hold Lessons Learned sessions to improve this process and to update this document.

Version Author Change/Update Date

Rev 1.0 Matthew Lewis First release 01/05/2009
REV 1.1 M. Lewis & 2nd Release 06/01/2010
Allen Chavis

Revision 1.1 Page 13 of 13