[RELEASE & DEPLOYMENT MANAGEMENT

PROCESS GUIDE] Sanmar Group

Release and Deployment

Management
Process Guide

Version 1.0
November 2013

2012

This is a controlled document. Unauthorised access, copying and replication are prohibited.

This document must not be copied in whole or in parts by any means, without the written
authorisation of the Head, Quality Management, WI.
[RELEASE & DEPLOYMENT MANAGEMENT PROCESS
GUIDE] Sanmar Group

DOCUMENT RELEASE NOTICE

This Release and Deployment Management Process Guide, Version 1.0, is released for
use in Sanmar, Wipro Infotech (WI) with effect from 11 th Nov 2013.

This manual is subject to WI Document Control Procedure.

Softcopy of the latest version of the document is available in the Process Document
Repository.

Comments, suggestions or queries on this document should be addressed to the Quality

manager.

Approved By: _________________________ Date:

(Program Delivery Head )

Authorised By: ________________________ Date:

(Quality Manager)

Wipro Infotech Page II

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

DOCUMENT REVISION LIST

Document Name: Release and Deployment Management Process Guide

Document No. WI-Sanmar-XXX

Version No: 1.0

Owner Release & Deployment Manager

Revision Revision Revision Page Rationale Change Type Update Reviewed

No. Date Description Number for (Add/Modify/Delete) by by
change

Wipro Infotech Page 1

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Abbreviations

The following abbreviations have been used in this document.

CAB Change Advisory Board

CAB/EC Change Advisory Board / Emergency
Committee
CI Configuration Item
CMDB Configuration Management Database
CMS Configuration Management System
CSF Critical Success Factor
DML Definitive Media Library
DHS Definitive Hardware Store
IT Information Technology
ITIL Information Technology Infrastructure Library
ITSM Information Technology Service Management
KEDB Known Error Data Base
KPI Key Performance Indicators
RFC Request For Change
SLA Service Level Agreement
SOP Standard Operating Procedures

Wipro Infotech Page 2

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Table of Contents
ABBREVIATIONS................................................................................................................................. 5

ABOUT THE DOCUMENT.................................................................................................................... 4

PURPOSE............................................................................................................................................ 4
TARGET AUDIENCE.............................................................................................................................. 4
ORGANISATION OF THE DOCUMENT....................................................................................................... 4
SECTION 1 – HIGH LEVEL PROCESS DESCRIPTION......................................................................6
PROCESS OBJECTIVES......................................................................................................................... 6
POLICY................................................................................................................................................ 6
ENTRY CRITERIA.................................................................................................................................. 7
PROCESS FLOW DESCRIPTION............................................................................................................. 9
EXIT CRITERIA................................................................................................................................... 12
SECTION 2 - ROLES AND RESPONSIBILITIES...............................................................................12
RELEASE & DEPLOYMENT MANAGER.................................................................................................. 12
RELEASE PACKAGING AND BUILD MANAGER.......................................................................................12
RACI CHART..................................................................................................................................... 13
SECTION 3 - LEVEL 2 PROCESS DESCRIPTION............................................................................14
(1.0) RECORD & CLASSIFY RELEASE REQUEST...................................................................................14
(2.0) DEPLOYMENT PLANNING............................................................................................................ 14
(3.0) RELEASE PACKAGING AND BUILD............................................................................................... 18
(4.0) DEPLOYMENT AND EARLY LIFE SUPPORT....................................................................................21
(5.0) CONFIRMATION AND CLOSURE.................................................................................................... 21
SECTION 4 - METRICS & EFFECTIVENESS GUIDELINES.............................................................25
PROCESS METRICS............................................................................................................................ 25
GUIDELINES FOR PROCESS EFFECTIVENESS.......................................................................................25
APPENDIX A – RELEASE RECORD TEMPLATE.............................................................................27

APPENDIX B - RELEASE PLAN TEMPLATE....................................................................................28

Appendix c - Relationship with other Processes..................................................................................29

Wipro Infotech Page 3

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

ABOUT THE DOCUMENT

Purpose
This document describes the Release and Deployment Management process. It may be used as
reference for the implementation and use of Release Management Process on an ongoing basis. This
process guide is based on the best practices described in the Information Technology Infrastructure
Library (ITIL) framework version 3.

Target Audience

The target audience for this document includes all Change & Release Management process roles,
Change Advisory Board (CAB) members, other service delivery roles like Service Desk Manager,
Incident Manager, Problem Manager, Capacity Manager, Availability Manager, Infrastructure
Architects, Application Development and Maintenance staff and Customer’s IT representatives.

Organisation of the Document

The document has been organised as follows:

Section 1: This section provides a high-level description of Release and Deployment

Management process. It describes the process objective, policies, and process flow
of Release Management process. It also clarifies and defines how the process
interrelates with other Information Technology Service Management (ITSM)
processes.

Section 2: This section describes the key responsibilities of various user roles. It represents the
roles and responsibilities of Release Management process roles in a RACI matrix.

Section 3: This section provides Level 2-process description of Release Management process.
It includes process flows, their inputs, activity, outputs and measures for each of
these detailed flows.

Section 4: This section describes the high-level process metrics and the guidelines to ensure
process effectiveness and efficiency.

Appendix A Release Record Template

Appendix B Release Plan Template

Appendix C Relationship with other processes

Wipro Infotech Page 4

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

LIST OF FIGURES

FIGURE 1 RELEASE MANAGEMENT PROCESS OVERVIEW

FIGURE 2 CLASSIFY RELEASE AND DEPLOYMENT PLANNING SUB-PROCESSES

FIGURE 3 RELEASE PACKAGING AND BUILD SUB-PROCESS

FIGURE 4 DEPLOYMENT & EARLY LIFE SUPPORT AND CONFIRMATION & CLOSURE SUB-
PROCESSES

Wipro Infotech Page 5

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

LIST OF TABLES

TABLE 1 HIGH-LEVEL DESCRIPTION OF RELEASE MANAGEMENT PROCESS

TABLE 2 RACI CHART

TABLE 3 DESCRIPTION OF CLASSIFY AND DEPLOYMENT PLANNING SUB-PROCESSES

TABLE 4 DESCRIPTION OF RELEASE PACKAGING AND BUILD SUB-PROCESS

TABLE 5 DESCRIPTION OF DEPLOYMENT & EARLY LIFE SUPPORT AND CONFIRMATION &
CLOSURE SUB-PROCESSES

Wipro Infotech Page 6

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

SECTION 1 – HIGH LEVEL PROCESS DESCRIPTION

Process Objectives

The purpose of Release Management is to plan and distribute authorised releases in production
environment without any adverse business impact. Release Management process acts as an agent of
Change Management to roll out changes into live environment.

Release Management has following major benefits:

 Roll out changes in the IT environment more effectively and efficiently.
 Comprehends Change Management Process as a roll out agent.
 Manage IT environment with authorised releases.

Release Management process can be activated by:

 Change Management process approves the new rollout of software / hardware.

Policy

The policies defined for Release Management process are listed as follows:

 Changes authorized by Change Management are released through Release Management

 Releases are built, tested and released as per Release Policy.
 Definitive Media Library (DML) is used to store all software components logically as well as
physically.
 Only authorized software and its components stored in DML are used for Release Build and
deployment.

High Level Process Overview

Release Management Process consists of the following major sub-processes.

1. Release Management Process - Overview

2. Record & Classify Release request
3. Deployment Planning
4. Release Packaging and Build
5. Deployment and Early Life Support
6. Confirmation and Closure

Entry Criteria

The release process commences with receipt of an approved RFC to deploy a production-ready
release package. Deployment commences with receipt of an approved RFC to deploy a release
package to a target deployment group or environment, e.g. business unit, customer group and/or
service unit.

Wipro Infotech Page 7

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Figure 1 - Release Management Process Overview

Wipro Infotech Page 8

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Process Flow Description

The high-level Release Management process and its sub-processes are described below.
Table 1 - High level description of Release Management Process
No. Procedure Description Input Output
1.0 Record and A Release is identified when a change  Release  Release
Classify request is authorised by CAB and a request from identified,
release release request is raised by Change Change recorded and
request Owner Management classified in
the system
Once a Release case is identified, the
Release case is recorded in the Release
Record form.

On recording the release request

following steps are performed –

 The change request is examined to

verify if it satisfies the criteria set forth
in the release policy.
 The constraints and dependencies are
identified for the change request.
 The release record is updated with the
classification based on the type of the
change request.
 The possibility of associating the
change request with any planned or
scheduled release based on the type is
evaluated.
 The priority for the release is assigned
based on the type of the release and
the time required for deployment.

2.0 Deployment The following activities are performed as  Release  Release

Planning a part of this procedural step: request planned and
recorded and approval from
 Resource levels and staff schedules classified stakeholders
required for the release are planned. received
 The entities and configuration items
(CIs) affected by the release are
examined to assess the extent of
changes.
 Tools required to implement the release
are identified and documented.
 The activities to be conducted for the
release are scheduled and
documented.
 The release plan with the schedule of
activities and the roles and
responsibilities is circulated to
stakeholders and received approval

Wipro Infotech Page 9

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

3.0 Release Design and Build release:  Approved  Release

Packaging The following activities are performed as release plan designed and
and Build a part of this procedural step: built

 The release is designed as per the  Release

requirements and the live environment tested
in which it has to be introduced.
 The development environment is  Release
prepared for building the release. approved for
 The release is built and configured in roll out
the development environment.
 The components of the release are  Release
bundled into a package for installation. cancelled for
roll out
Prepare rollout and roll back plan:
The following activities are performed as
a part of this procedural step:

 A schedule is prepared and a list of

tasks and required human resources is
prepared.
 Actions to be taken to restore the
service should the rollout of a release
fail, either partially or totally, is
documented in the rollback plan.
 The contingency measures that have to
be adopted to restore the service on a
failed release are documented in the
rollback plan.

Test the release package:

The following activities are performed as
part of this procedural step:

 A test environment is set up based on

the environment specifications of the
release.
 Tests are performed on the release
package to verify whether it meets
requirements as per the release plan.
 The results of the test are recorded and
analysed to verify the success of the
build.
 The release record is updated with the
test results, the expected behaviour
and the actual behaviour of the release
package.

Assess test results:

If the release test is successful, release is
authorised for rollout.

If the release test is not successful, the

Wipro Infotech Page 10

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

stake holders are informed accordingly.

4.0 Deployment Release Deployment:  Release  Release rolled

and Early Life The following activities are performed as approved for out
Support part of this procedural step: rollout
 Live
 Distribute and install the release into environment
production environment. monitored
 The installation procedures described in
the release notes are followed during  Release
the release installation. record
 Details of the deployed release are updated
communicated to relevant parties and
User/Service Beneficiary.

Early Life Support:

The following activities are performed as
part of this procedural step:

 Upon installation of the release, the

functioning of the release is monitored
by the Release Deployment Manager.
 During this period, the functional
aspects of the release are verified and
examined for different scenarios.
 Resources are deployed to provide
Early Life Support and transition the
knowledge from release deployment
team to operations team.
 The behaviour of the release is
recorded to identify the success or
failure of the release in the live
environment.

5.0 Confirmation Assess success of release:  Release  Successful

& Closure  The success or failure of the release is rolled out release
measure by the Release Manager.
 The success of a release can also be  Failed release
measured by the customer and/or
stakeholders. In such a scenario, the  Rollback
Release Manager receives the success release
or failure details of the release from the
customer.  Communicatio
n to stake
Implement rollback procedures: holders
 If the release is failed, the procedures
described in the rollback plan are  Release
implemented by the Release record update
Coordinator.
 The release is rolled back to the last  Close release
stable version in the live environment. record

Communicate release details to

Wipro Infotech Page 11

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

stakeholders:

Close release record:

Exit Criteria
Deployment is completed with a handover of the new or changed service to operations on successful
completion of the post implementation review of the deployment conducted within Change
Management.

SECTION 2 - ROLES AND RESPONSIBILITIES

Roles defined below do not represent individuals. An individual may play multiple roles at any given
time.

Release Deployment Manager

The role of a Release Manager is to ensure the development of a release policy to define the
frequency and type of releases. The Release Manager must define the identification mechanism for
releases in the release policy.

The Release Deployment Manager is responsible for:

 Design, deploy and improve Release and Deployment Management Process

 Ensuring interfaces of Release Management process with all other relevant processes;
 Developing and maintaining a release policy;
 Recording and reviewing the Release request;
 Selecting the release mechanism for distribution and deployment;
 Preparing release deployment and roll-back plan.
 Facilitation of adequate resources required for the Release Management process;
 Providing updated release details to Service Asset and Configuration Management
 Overseeing the release deployment activities
 Monitoring the release subsequent to deployment and provide Early Life Support;
 Communication to stakeholders
 Assessing the success of the release; and
 Closing of the release record.
 Preparing ,management reports

Release Packaging and Build Manager

 Establish final Release Configuration

Wipro Infotech Page 12

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

 Design and build the final release;

 Testing the comprehensiveness of the test plan and test cases;
 Verifying and approving the acceptance test results;
 Providing inputs to final implementation sign-off
 Establish and reports Known Errors and Workarounds

RACI Chart
Legend: R = Responsible for a particular action, but not necessarily authority

A = Accountable for the action. There is only one person accountable for any given
action.
C = Consulted before the action (but not necessarily agree with it)

I = Informed after the action (need to know basis)

Note: This RACI table does not include the communication and information that has to be made within
a team when a change is decided regarding the process or the procedures. E.g.: If a Change is
decided on the IM Process, RACI only mentions that the Team Lead has to be informed, even if the
Team Lead has to inform his team(s) as required.
Table 2 - RACI Chart
Release Release
Support
Function Deployment Packaging and
Groups
Manager Build Manager
Record and Review the Release Request AR I -

Plan the release deployment AR I -

Design and build the release A R -

Test the release package A R -

Perform acceptance testing A I -

Verify and review acceptance test results A I -

Prepare distribution and deployment schedule AR I I

Deploy the release A I R

Provide Early Life Support A I R

Monitor the release AR I I

Rollback of release A I R

Closure of release record AR I I

Wipro Infotech Page 13

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

SECTION 3 - LEVEL 2 PROCESS DESCRIPTION

This section explains the sub-processes and corresponding tasks, inputs and outputs in detail.

(1.0) Record & Classify Release Request

(2.0) Deployment Planning

The steps involved in Classify Release Request and Deployment Planning sub-process are illustrated
in the following figure.

Figure 2 - Classify Release and Deployment Planning Sub-processes

Table 3 - Description of Classify Release and Deployment Planning Sub-proceeses

No. Procedure Description Input Output

1.1 Record  Receive the approved change request from  App  Relea
release the Change Management procedure. roved se request

Wipro Infotech Page 14

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

request  Record the details of the change request and Change registered
create a release record. Request with details
Refer Appendix A – Release Record Template
 Enter a release identification number to relate
with the change request.
 Identify and record the type of the release
request. The type can be:
 Hardware
 Software
 Documentation
 Network
 Installation and/or Deployment
 Relocation
 Set the status of the release to ‘Registered’.

1.3 Review and  Evaluate the release request and verify the  Rel  Relea
classify type of change request. ease se request
release  Search available release plans for scheduled request reviewed
request releases in the CMDB. The search can be registered and
performed based on: with classified
 Type of request details
 Release identification number
 Keyword search
 Verify whether this release request has been
addressed in any of the planned releases.
 Evaluate whether this release request can be
addressed by any scheduled release.
 Examine whether multiple change requests of
the same type can be packaged as a single
release. If the change requests perform
changes to the same IT components or
services, the change requests can be
combined into a single release.
 Define the scope of the release and update
the release record with the details.
 Set the priority of the release based on the
type of the change request and the time for
the change request to be introduced into the
live environment.
 Update the release record with the details of
the priority.
 Provide the updated release record to the
Release Manager.
2.1 Prepare  Based on the details of the change request  Rel  Relea
release plan provided in the release record, perform an ease se plan
initial investigation on: request prepared
 Components affected registered with other
 Scope of the release and auxiliary
 Complexity of the release classified plans
 Service levels associated with the
release
 Business need for the release
 Constraints and dependencies

Wipro Infotech Page 15

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

 Infrastructure or service lifecycle

 Identify the tools required for the release.
Document the details in the release record.
 Examine the staff skill set and identify roles
and responsibilities for the release.
 If required, identify the training needs within
the team and prepare a training schedule.
 Identify and document the external subject
matter expertise required (if any) for the
release.
 List the activities required for the release.
Update the release record with the details of
activities.
 Identify the locations at which the release is
to be deployed and record the details.
 If required, conduct site surveys to assess
existing infrastructure and update the release
plan.
 Based on the complexity of the activities and
the skills required for these activities,
schedule the activities and allocate timelines.
 Record the timelines and the activities in the
release plan.
 For each identified activity, assign an owner
for the task. This can be performed once a
consensus has been obtained on the activity
list.
 For small releases, define the activities in
detail for deploying the releases. The small
releases can be:
 Installation of patches
 Scheduled updates
 Pre-defined tasks (if release)
 Detail all activities with tasks and sub-tasks
for large or complex releases.
 Record all activities, tasks and sub-tasks in
the release plan.
 If feasible and deemed necessary (for large
releases), schedule a meeting with the
Change Advisory Board (CAB) to finalize the
release plan.
 Compile a communication mechanism for
communicating to relevant stakeholders,
users, service provider management and
service beneficiaries of the releases.
 Based on the above details, arrive at a
timeline for completion of the release build,
acceptance testing and deployment for
release.
 Evaluate and record the documentation
requirements and documentation deliverables
for the release.
 Update the release plan with the details of

Wipro Infotech Page 16

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

any additional support if required from

Service Desk.
Refer Appendix B – Release Plan Template
 Prepare cost and effort estimates for the
release and update the release plan.
 Set the status of the release to ‘Planned’ and
update the release record.
2.2 Stakeholder  Obtain feedback for the release plan from the  Rel  Stake
approval customers, users, relevant stakeholders and ease plan holders
the Change Management. prepared approval
 Document the feedback provided and update with other received
the release plan accordingly. auxiliary
 Identify and document in detail the reasons plans
for revision in the release plan.
 Circulate the release plan to the release
testing coordinator and the release
coordinator.

Wipro Infotech Page 17

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

(3.0) Release Packaging and Build

The steps involved in Release Packaging and Build sub-process are illustrated in the following figure.

Figure 3 - Release Packaging and Build Sub-process

Table 4 - Description of the steps involved in Release Packaging and Build Sub-process
No. Procedure Description Input Output

3.1 Design and  Identify the requirements for the release  Appr  Rele
build release based on the nature and type of the release. oved ase
 Identify installation and un-installation release designed
mechanisms for the release. plan
 Record any tools or configuration
mechanisms for designing the release.
 Document detailed procedures for the
build, installation and un-installation of the
release.
 Identify the components of a release
that can be developed or are available in-
house and those that need to be procured.
 Document the exact sequence of
operations and the step-by-step instructions
to assemble the release.
 Evaluate whether the installation
procedures can be automated for quicker
installation if the installation has to be

Wipro Infotech Page 18

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

performed at multiple locations or on multiple

recipient systems.
 If automated, detail the sequence for
installation and un-installation. Record
expected behaviour to aid in the development
of the roll-out plan.
 In addition to installation and un-
installation procedures, document the
procedures for introducing the release into the
live environment.
 Record dependencies and constraints
for each task in the procedures.
 Set up a development environment for
the release. The development environment
should simulate the live environment as
closely as possible.
 Identify and document all CIs that are to
be modified for the release build.
 Perform quality control and security
feature checks after the completion of the
build.
 Prepare and record automated
installation scripts if feasible.
 Record the build instructions and the
build results to be placed in the CMDB.
 Evaluate the current status of the CIs
that have been modified for the release.
 Prepare the release package for testing
by recording the details such as:
Type
Deployment date
CIs modified
Version Details
 Provide the release package for testing
and communicate to the Release Testing
Coordinator.
3.2 Test the  Based on the contents of the release  Rele  Testi
release package and the change request details, ase plan ng result
package and prepare a detailed test plan for verifying the
procedures functionality of the release package.  Rele  Upd
 The test plan must include tests for ase for ated
installation and un-installation of the package. testing release
 For testing the installation, the record
installation scripts must undergo thorough
testing in simulated environment.
 Evaluate whether the release package
meets functional requirements as set out by
the change request.
 As part of the functional testing,
perform load and stress testing on the
package to identify flaws due to increased
use of the package.
 Test the rollback and rollout procedures

Wipro Infotech Page 19

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

to verify the functionality of the procedures.

 Identify the entry and exit criteria for the
package and same for the rollout and rollback
procedures
 Update the release record with the
details of the test results.
 Communicate the test results along
with the updated release record to the
Release Coordinator.
 If the test results are successful
proceed for the next step or return to the
release build step.
3.3 Verify and  Verify the criteria for acceptance of the  Test  Upd
review test release and the test results corresponding to results ate release
results the criteria. record
 Provide the acceptance criteria and the  Acc
test results to the service beneficiary, eptance
customer or user for review. criteria
 Based on the test results and the actual
behaviour of the release, arrive at a decision
to approve or reject the deployment of the
release.
 If the release test is successful proceed
for deployment or else update the release
record and return to the Change Management
Process.
3.4 Update  Update the KEDB with Known Errors  Test  Upd
KEDB and Workarounds found during testing. results ate release
record
 Upd
ate KEDB

Wipro Infotech Page 20

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

(4.0) Deployment and Early Life Support

(5.0) Confirmation and Closure
The steps involved in Deployment & Early Life Support and Confirmation & Closure sub-process are
illustrated in the following figure.

Figure 4 - Deployment & Early Life Support and Confirmation & Closure Sub-processes

Table 5 - Description of Deployment & Early Life Support and Confirmation & Closure Sub-
processes
No. Procedure Description Input Output

4.1 Prepare final  Prepare a list of the Configuration  Rel  Final

distribution Items (CI) to be installed and record in the ease distribution
and roll-out plan. Build and
deployment  Identify the environment requirements deployment
Schedule for the release package installation and schedule
record in the roll-out plan.
 Identify and document all constraints
and dependencies for the successful roll-out
of the release.
 Identify interfaces between critical
components of the release package and
document the entry and exit criteria for the

Wipro Infotech Page 21

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

roll-out of the release.

 Prepare a comprehensive timetable of
the activities related to the roll-out of the
release
 The timelines must also contain the
ownership and responsibility information for
each of the activity.
 The schedule for the roll-out must
consider the deployment date as specified
in the release plan.
 Develop procedures to rollback the
release in case of any unexpected or
unwarranted behaviour.
 The contingency measures must
cover each activity indicated in the roll-out
plan. This enables successful rollback at
any stage of the roll-out.
 Identify staff members responsible for
each activity and communicate the rollback
procedures to them.
 Attach relevant support
documentation including the system
overview, updated support procedures, and
diagnostic aids.
 Update the release record with the
details of the rollback plan.

 Decide a specific downtime based on
the installation requirements for the service.
The downtime must be outside normal
working hours to reduce the affect on
service usage.
4.2 Communicate  Inform the relevant stakeholders  Fin  Commu
to about the scheduled distribution and al nication to
stakeholders deployment. distributio stakeholders
 Inform, well in advance of the n and
downtime, the users and others affected by deployme
the downtime the date and time for the nt
scheduled deployment. schedule
 Communicate training material to
users and technical staff.
4.3 Distribute and  Distribute the Release Package to the  Fin  Release
Install required locations. al deployed
Release  Install the release from distributed distributio
locations on determined schedule. n and
 Activate the installed release. deployme
nt
schedule
4.4 Provide Early  Assign dedicated resources to  Rel  Early
Life Support provide Early Life support. This may include ease Life support
providing technical support to Service Desk deployed provide
and other support teams, transferring  Knowled
knowledge to support staff etc. ge transferred

Wipro Infotech Page 22

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

4.5 Monitor  Monitor the performance of the  Rel  Post

Release service subsequent to the release ease implementatio
behaviour deployment. deployed n monitoring
 Examine data feeds; perform input,
output validations to measure the success
of the release.
 Document all observations pertaining
to the behaviour of the release.
 Compare actual behaviour of the
release with the expected behaviour and
document all discrepancies.
 Verify if a significant number of
incidents have been reported subsequent to
the deployment.
 Examine the incidents and determine
if the incidents are due to:
 Lack of awareness
 Improper installation
 Affected services
 Significantly large number of affected
users
 Record all data from the monitoring
tool (if any).
 Determine the success of the release
and document the reasons for success or
failure of the release.
4.6 Implement  Rel  Release
Receive feedback from customer (if any) for
Rollback ease rolled back
the success of the release and/or examine the
rolled out
observations from the release monitoring
exercise. If the release has been successfully
deployed, proceed for the closure.
 Upon measurement that the release has
failed in production, implement the rollback
procedures developed.
 Notify the Release Manager of the failed
release and the decision to implement the
rollback procedures.
 Inform users and service beneficiary of
rollback and execute the steps prescribed
for the rollback.
 Revert back to the last stable version of the
release in production.
 Set the status of the release record to
‘Backed Out’.
 Provide the above details along with the
release package details to the Release
Manager
5.1 Communicate  Upon receipt of failed release  Rel  Stakehol
to the notification, raise an incident record to ease der
stakeholders indicate that the release has failed in rolled communicatio
production. back n
 Provide the details of the release and
the failure details to the procedure for

Wipro Infotech Page 23

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Incident Management. If possible, provide

the likely incidents that might be reported
due to this failure.
 Schedule meetings with the CAB,
Release Coordinator and Release Testing
Coordinator to identify the reasons for
failure.
 Document all discussions and record
the actions to be taken.
5.2 Close the  Upon successful implementation of  Suc  Release
release the release, set the status of the release cessful or record closed
record record to ‘Closed’. failed
 For failed releases, verify if an release
incident record has been raised and if so,
set the status of the release record to
‘Closed’.
 Once the release record has been
closed, ensure that the complete release
data has been updated in the Release
Record or tool.
 Prepare the periodic service reports
based on the data collected for the recorded
releases.
 Analyze the release records to
identify :
 Successful releases
 Emerging trends in releases.
 Record the results and conclusion
drawn from this analysis and provide to the
Service Reporting procedure.
 Provide the service report to the
Service Reporting procedure.

Wipro Infotech Page 24

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

SECTION 4 - METRICS & EFFECTIVENESS GUIDELINES

Process Metrics

Listed below is the process metrics that can be used to determine efficiency and effectiveness of the
Release Management process.

 The number of emergency and non-emergency releases per reporting period;

 The number of releases completed in the agreed timescales;
 The number of incidents in the live environment that can be attributed to new releases as a
result of release monitoring;
 Number of deployed releases;
 Number of backed out releases.
 User satisfaction

Guidelines for Process Effectiveness

Documentation

Ensure that the process documentation is owned, is identified as a unique CI in the CMDB, and is
accessible by all delivery staff.

Ensure that all changes to the process documentation are managed through the Change
Management process (e.g. Document control system).

Adherence to Policies
Ensure the adherence to all process policies. For example:

 All releases will be recorded in a management system

 All release are planned for rollout and back out
 All releases will be tested and approved by stakeholders before rollout

Understanding of Roles and Responsibilities

Ensure that all delivery staff understands and performs their roles and responsibilities within the
Release Management process.

Planning
Ensure that all releases are planned for efficient and effective use of resources. The roll out plan must
be adequately supported with information like schedule, resource requirement and back out plan.

Wipro Infotech Page 25

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

Testing
Ensure that all releases are tested in the test environment resembling the live environment. Ensure
that the test results are to documented and assessed before approval for rollout.

Wipro Infotech Page 26

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

APPENDIX A – RELEASE RECORD TEMPLATE

Release ID*
Release Received on (Date and Time)*
Release related to - Project/Product/Service Details*
Release Received by*
Name*
Contact Details*
Location

Release Initiator Details Related Change Request ID*

Release Category*
Release Type*
Release Summary*
Release Priority*
Hardware or Software Changes
Related Services*
Configuration Item Details CIs to be updated*
Release Status*
SLA Breached*
System Requirements*
Release Coordinator details*
Porting Environment Details* Change Request Details*
Related Incidents (if any)
Resolution Time*
Downtime Details*
Start and End Date for Testing*
Release Testing Coordinator Details
Acceptance Testing Details* Test Results Approved?*
Deployment Date and Time*
Deployment approved by*
Deployment Responsibility*
Monitoring Responsibility*
Post Deployment Behaviour
Deployment Details* Description*
Release Successful?*
Reasons for Release Failure*
Last Stable Version Information for Rollback*

Wipro Infotech Page 27

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

APPENDIX B - RELEASE PLAN TEMPLATE

RELEASE DETAILS
Release Version: Scheduled deployment Change ID: Change Details: Release
date: Description:

IMPACT ANALYSIS
Complexity of Components Affected: CIs to be updated:
implementation:
High/Medium/Low

EFFORTS REQUIRED (IN PERSON-HOURS)

Planning: Design: Development: Testing:

Documentation: Implementation: Monitoring: Rollback on failure:

Constraints (if any): Dependencies (if any):

Service Levels:

RESOURCES REQUIRED
Hardware: Software: Tools: Documentation:

IDENTIFIED TEAM MEMBERS

Planning: Development: Testing: Monitoring:

ROLLOUT INFORMATION (Dates to be confirmed upon approval from customer)

Development Start Unit Testing Start Date: Acceptance Deployment on Production:
Date: Testing Start Date:

Development End Date: Unit Testing End Date: Acceptance

Testing End Date:

ROLLBACK PLAN
Release failed? Y/N Release Type: List of RFCs in the release:
Full/Delta/Package

Backup information: Location in DSL/DHS: DSL/DHS Information:

Service disrupted for: (in Rollback start date/time: Configuration Items affected:
minutes)
Reason for rollback:

Wipro Infotech Page 28

 [RELEASE & DEPLOYMENT MANAGEMENT
PROCESS GUIDE] Sanmar Group

APPENDIX C - RELATIONSHIP WITH OTHER PROCESSES

Below is a summarized view of the data flow relationships between Release Management and other
Reference Model processes.

Output from Release

ITSM Procedure Input to Release Management
Management
 The details of the change  The release plan for the
request. release to be deployed.
Change Management
 The details of the emergency  Details of release that has
change request. been rejected for deployment.

 Details on Known Errors from

 Incidents caused due to recent development environment
Incident Management
release  The details of the failed
release after deployment.

 Configuration Item details and  Details of the release upon

the relationship between completion of the build.
Configuration various Configuration Items.
Management  Details of release upon
 Information on DSL & DHS successful deployment.
components

  RM process identified the

Known Errors in the Devl.
Problem Management
environment and cascade
them to Prod environment

Wipro Infotech Page 29