release management policy rev 1.1

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

IT Department

Release Management Policy

R e v i s i o n 1 . 1 of 13


Table of Contents

1 Purpose....................................................................................................................................32 Application..............................................................................................................................33 Scope........................................................................................................................................34 ITIL..........................................................................................................................................3

4.1 Related processes..............................................................................................................34.1.1 Change Management.................................................................................................44.1.2 Configuration Management.......................................................................................44.1.3 Service Request (V3).................................................................................................4

5 Release Management Definition..............................................................................................55.1 Release Management Flow...............................................................................................55.2 Quality Assurance and the COR.......................................................................................6

6 Components of Release Management.....................................................................................66.1 Release Management Roles and Responsibilities.............................................................6

6.1.1 Release Manager........................................................................................................66.1.2 Build Developer.........................................................................................................76.1.3 Acceptance Tester......................................................................................................76.1.4 Installer......................................................................................................................86.1.5 Release Mangement Committee................................................................................8

6.2 Tools..................................................................................................................................86.3 Difinitive Media Library (DML)......................................................................................86.4 Release Categories............................................................................................................86.5 Release Types...................................................................................................................96.6 Data Requirements............................................................................................................9

7 Release Management Process Flow.......................................................................................107.1 Stage Definitions.............................................................................................................107.2 Process Flow...................................................................................................................10

8 Release Management Process Metrics...................................................................................128.1 Success characteristics....................................................................................................128.2 Resulting expectations....................................................................................................128.3 Notable achievements.....................................................................................................128.4 Lasting benefits...............................................................................................................13

9 Release Metrics......................................................................................................................1310 Modifications.........................................................................................................................13

R e v i s i o n 1 . 1 of 13


1

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

3 ApplicationThis 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.

4 ScopeThe 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.

5 ITIL Release ManagementThe 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.

5.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.

R e v i s i o n 1 . 1 of 13


Figure 1

5.1.1 Change ManagementThe Release Management process interfaces with the Change Managementprocess throughout its lifecycle. Release Management provides the inputs to therequest for change at the various stages of planning and preparation. ChangeManagement final approval should be received before the new service is releasedinto the live environment.

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

5.1.3 Service Request (V3)The Release Management process interfaces with the Service Requestprocess throughout its lifecycle. Release Management can receive inputs from the

R e v i s i o n 1 . 1 of 13


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

6 Release Management DefinitionRelease 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 timeKey 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

7 Release Management FlowFigure 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.

R e v i s i o n 1 . 1 of 13


Figure 2

7.1 Quality Assurance and the CORThe 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.

8 Components of Release Management

8.1 Roles

8.1.1 Release Manager– Responsible for Release Management and ensuring that the process is followed

R e v i s i o n 1 . 1 of 13


– Is the process owner– 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.

8.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)

R e v i s i o n 1 . 1 of 13


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 CommitteeThe 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.

8.2 Tools

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

8.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.

8.4 Release Categories

This process may be adjusted for different Release levels.MajorA 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.

MinorA 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

R e v i s i o n 1 . 1 of 13


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.

8.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 ReleaseA 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 ReleaseIn a Full Release, all components of the Release unit that are built tested, distributed and implemented together.

Package ReleaseA 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.

8.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

R e v i s i o n 1 . 1 of 13


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.

9 Release Management Process FlowThis 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

9.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

9.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

R e v i s i o n 1 . 1 of 13


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

Figure 3

R e v i s i o n 1 . 1 of 13


10 Release Management Process Metrics

10.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

10.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

10.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

R e v i s i o n 1 . 1 of 13


10.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

11 Release Management MetricsThe 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)

12 ModificationsThis 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 DateRev 1.0 Matthew Lewis First release 01/05/2009REV 1.1 M. Lewis &

Allen Chavis2nd Release 06/01/2010

R e v i s i o n 1 . 1 of 13

release management policy rev 1.1

Documents