Release and Deployment Management Process Guide

[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 11th 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

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
No.
Revision
Date
Wipro Infotech
Revision
Description
Page
Number
Rationale
for
change
Change Type
(Add/Modify/Delete)
Update
by
Reviewed
by
Page 1

Abbreviations
The following abbreviations have been used in this document.
CAB
CAB/EC
CI
CMDB
CMS
CSF
DML
DHS
IT
ITIL
ITSM
KEDB
KPI
RFC
SLA
SOP
Change Advisory Board

Change Advisory Board / Emergency
Committee
Configuration Item
Configuration Management Database
Configuration Management System
Critical Success Factor
Definitive Media Library
Definitive Hardware Store
Information Technology
Information Technology Infrastructure Library
Information Technology Service Management
Known Error Data Base
Key Performance Indicators
Request For Change
Service Level Agreement
Standard Operating Procedures
Wipro Infotech
Page 2

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

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 Customers 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

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 SUBPROCESSES
Wipro Infotech
Page 5

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

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

Figure 1 - Release Management Process Overview
Wipro Infotech
Page 8

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
A Release is identified when a change

request is authorised by CAB and a
release request is raised by Change
Owner
Release
request from
Change
Management
Release
identified,
recorded and
classified in
the system
Release
request
recorded and
classified
Release
planned and
approval from
stakeholders
received
Record and
Classify
release
request
Once a Release case is identified, the

Release case is recorded in the Release
Record form.
On recording the release
following steps are performed
request
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
Planning
The following activities are performed as

a part of this procedural step:
Resource levels and staff schedules
required for the release are planned.
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

3.0
Release
Packaging
and Build
Design and Build release:

The release is designed as per the
requirements and the live environment
in which it has to be introduced.
The development environment is
prepared for building the release.
The release is built and configured in
the development environment.
The components of the release are
bundled into a package for installation.
Approved
release plan
Release
designed and
built
Release
tested
Release
approved for
roll out
Release
cancelled for
roll out
Prepare rollout and roll back plan:

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:
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.
Wipro Infotech
Page 10

If the release test is not successful, the
stake holders are informed accordingly.
4.0
Deployment
and Early Life
Support
Release Deployment:
Release
approved for
rollout
Distribute and install the release into

production environment.
The installation procedures described in
the release notes are followed during
the release installation.
Details of the deployed release are
communicated to relevant parties and
User/Service Beneficiary.
Release rolled
out
Live
environment
monitored
Release
record
updated
Early Life Support:

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
& Closure
Assess success of release:

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

Communicate
stakeholders:
release
details
to
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
Wipro Infotech
Page 12

Release Packaging and Build Manager
Establish final Release Configuration
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:
= Responsible for a particular action, but not necessarily authority
= Accountable for the action. There is only one person accountable for any given
action.
= Consulted before the action (but not necessarily agree with it)
= 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
Function
Release
Deployment
Manager
Release
Packaging and
Build Manager
Support
Groups
Record and Review the Release Request
AR
Plan the release deployment
AR
Design and build the release
Test the release package
Perform acceptance testing
Verify and review acceptance test results
AR
Deploy the release
Provide Early Life Support
Monitor the release
AR
Rollback of release
Prepare distribution and deployment schedule
Wipro Infotech
Page 13

Function
Closure of release record
Release
Deployment
Manager
Release
Packaging and
Build Manager
AR
Support
Groups
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

Wipro Infotech
Page 14

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

No.
Procedure
Description
Input
Output
1.1
Record
release
request
Receive the approved change request from

the Change Management procedure.
Record the details of the change request and
create a release record.
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.
App
roved
Change
Request
Relea
se request
registered
with details
1.3
Review and
classify
release
request
Evaluate the release request and verify the

type of change request.
Search available release plans for scheduled
releases in the CMDB. The search can be
performed based on:
Type of request
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.
Rel
ease
request
registered
with
details
Relea
se request
reviewed
and
classified
Wipro Infotech
Page 15

2.1
Prepare
release plan
Wipro Infotech
Based on the details of the change request

provided in the release record, perform an
initial investigation on:
Components affected
Scope of the release
Complexity of the release
Service levels associated with the
release
Business need for the release
Constraints and dependencies
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.
Rel
ease
request
registered
and
classified
Relea
se plan
prepared
with other
auxiliary
plans
Page 16

2.2
Stakeholder
approval
Wipro Infotech
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
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.
Obtain feedback for the release plan from the
customers, users, relevant stakeholders and
the Change Management.
Document the feedback provided and update
the release plan accordingly.
Identify and document in detail the reasons
for revision in the release plan.
Circulate the release plan to the release
testing coordinator and the
release
coordinator.
Rel
ease plan
prepared
with other
auxiliary
plans
Stake
holders
approval
received
Page 17

(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
build release
Wipro Infotech
Identify the requirements for the release

based on the nature and type of the release.
Identify installation and un-installation
mechanisms for the release.
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 inhouse 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
Appr
oved
release
plan
Rele
ase
designed
Page 18

3.2
Test the
release
package and
procedures
Wipro Infotech
installation if the installation has to be

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 uninstallation
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.
Based on the contents of the release
package and the change request details,
prepare a detailed test plan for verifying the
functionality of the release package.
The test plan must include tests for
installation and un-installation of the package.
For testing the installation, the
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
Rele
ase plan
Testi
ng result
Rele
ase for
testing
Upd
ated
release
record
Page 19

3.3
Verify and
review test
results
3.4
Update
KEDB
Wipro Infotech
use of the package.

Test the rollback and rollout procedures
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.
Verify the criteria for acceptance of the
release and the test results corresponding to
the criteria.
Provide the acceptance criteria and the
test results to the service beneficiary,
customer or user for review.
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.
Update the KEDB with Known Errors
and Workarounds found during testing.
Test
results
Acc
eptance
criteria
Test
results
Upd
ate release
record
Upd
ate release
record
Upd
ate KEDB
Page 20

(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 Subprocesses
No.
Procedure
Description
Input
4.1
Prepare final
distribution
and
deployment
Schedule
Wipro Infotech
Prepare a list of the Configuration

Items (CI) to be installed and record in the
roll-out plan.
Identify the environment requirements

for the release package installation and
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
Output
Rel
ease
Build
Final
distribution
and
deployment
schedule
Page 21

4.2
Communicate
to
stakeholders
4.3
Distribute and
Install
Release
4.4
Provide Early
Life Support
Wipro Infotech
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.
Inform the relevant stakeholders
about the scheduled distribution and
deployment.
Inform, well in advance of the
downtime, the users and others affected by
the downtime the date and time for the
scheduled deployment.
Communicate training material to
users and technical staff.
Distribute the Release Package to the
required locations.
Install the release from distributed
locations on determined schedule.
Activate the installed release.
Assign dedicated resources to
provide Early Life support. This may include
providing technical support to Service Desk
and other support teams, transferring
knowledge to support staff etc.
Fin
al
distributio
n and
deployme
nt
schedule
Commu
nication to
stakeholders
Fin
al
distributio
n and
deployme
nt
schedule
Rel
ease
deployed
Release
deployed
Early
Life support
provide
Knowled
Page 22

4.5
Monitor
Release
behaviour
4.6
5.1
Implement
Rollback
Communicate
to the
stakeholders
Wipro Infotech
Monitor the performance of the

service subsequent to the release
deployment.
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.
Receive feedback from customer (if any) for

the success of the release and/or examine the
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
Upon receipt of failed release

notification, raise an incident record to
indicate that the release has failed in
Rel
ease
deployed
ge transferred
Post
implementatio
n monitoring
Rel
ease
rolled out
Release
rolled back
Rel
Stakehol
der
communicatio
ease
rolled
Page 23

5.2
Close the
release
record
Wipro Infotech
production.
Provide the details of the release and
the failure details to the procedure for
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.
Upon successful implementation of
the release, set the status of the release
record to Closed.
For failed releases, verify if an
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.
back
Suc
cessful or
failed
release
Release
record closed
Page 24

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.
Wipro Infotech
Page 25

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

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
Release Category*
Release Type*
Release Summary*
Release Priority*
Configuration Item Details

Release Status*
SLA Breached*
Porting Environment Details*

Related Incidents (if any)
Resolution Time*
Downtime Details*
Acceptance Testing Details*
Related Change Request ID*
Hardware or Software Changes

Related Services*
CIs to be updated*
System Requirements*
Release Coordinator details*
Change Request Details*
Start and End Date for Testing*

Release Testing Coordinator Details
Test Results Approved?*
Deployment Date and Time*
Deployment approved by*
Deployment Responsibility*
Monitoring Responsibility*
Post Deployment Behaviour
Description*
Deployment Details*
Release Successful?*
Reasons for Release Failure*
Last Stable Version Information for Rollback*
Wipro Infotech
Page 27

APPENDIX B - RELEASE PLAN TEMPLATE

RELEASE DETAILS
Release Version:
IMPACT ANALYSIS
Complexity
implementation:
High/Medium/Low
Scheduled
date:
of
deployment
Change ID:
Components Affected:
Change Details:
Release
Description:
CIs to be updated:
EFFORTS REQUIRED (IN PERSON-HOURS)

Planning:
Design:
Development:
Testing:
Documentation:
Monitoring:
Rollback on failure:
Implementation:
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:
Release
Type:
Full/Delta/Package
List of RFCs in the release:
Backup information:
Location in DSL/DHS:
DSL/DHS Information:
Service disrupted for: (in

minutes)
Rollback start date/time:
Configuration Items affected:
ROLLBACK PLAN
Release failed? Y/N
Reason for rollback:

Wipro Infotech
Page 28

APPENDIX C - RELATIONSHIP WITH OTHER PROCESSES

Below is a summarized view of the data flow relationships between Release Management and other
Reference Model processes.
ITSM Procedure
Change Management
Incident Management
Configuration
Management
Input to Release Management

The details of the change
request.
The release plan for

release to be deployed.
The details of the emergency

change request.
Details of release that has

been rejected for deployment.
Incidents caused due to recent

release
Configuration Item details and

the
relationship
between
various Configuration Items.
Information on DSL & DHS
components
Problem Management
Wipro Infotech
Output from Release

Management
the
Details on Known Errors from

development environment
The details of the failed
release after deployment.
Details of the release upon
completion of the build.
Details of release
successful deployment.
upon
RM process identified the

Known Errors in the Devl.
environment and cascade
them to Prod environment
Page 29

Release and Deployment Management Process Guide

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Release and Deployment Management Process Guide

Загружено:

Авторское право:

Доступные форматы

[RELEASE & DEPLOYMENT MANAGEMENT

PROCESS GUIDE] Sanmar Group