STANDARD OPERATING

PROCEDURES
Release and Deployment Management

1
Info-Tech Research Group
Table of Contents
PURPOSE............................................................................................................................................................ 3
SCOPE................................................................................................................................................................. 3
OBJECTIVES....................................................................................................................................................... 3
DEFINITIONS....................................................................................................................................................... 3
ROLES AND RESPONSIBILITIES...................................................................................................................... 4
RELEASE LIFECYCLE....................................................................................................................................... 5
RELEASE PLANNING......................................................................................................................................... 6
RELEASE TYPES................................................................................................................................................. 6
RELEASE AND DEPLOYMENT PLANNING WORKFLOW............................................................................................. 7
EMERGENCY RELEASES...................................................................................................................................... 7
EMERGENCY RELEASE WORKFLOW..................................................................................................................... 8
RELEASE CLASSIFICATION AND PRIORITY................................................................................................... 9
ASSESSING RISK................................................................................................................................................ 9
Release Vulnerability Matrix........................................................................................................................ 10
System Criticality Matrix.............................................................................................................................. 10
Release Severity Matrix.............................................................................................................................. 11
APPROVED CHANGE WINDOWS......................................................................................................................... 11
RELEASE DESIGN AND BUILD....................................................................................................................... 12
BUILD PROCEDURE........................................................................................................................................... 12
Design and Build Workflow......................................................................................................................... 12
Approved Build Support Tools..................................................................................................................... 13
RELEASE TESTING.......................................................................................................................................... 13
TEST PLANNING PROCEDURE............................................................................................................................ 13
APPROVED TEST PLANS.................................................................................................................................... 14
Release Testing Workflow........................................................................................................................... 14
RELEASE DEPLOYMENT................................................................................................................................. 15
DEPLOYMENT MODELS...................................................................................................................................... 16
POST-DEPLOYMENT VERIFICATION............................................................................................................. 16
POST-DEPLOYMENT WORKFLOW....................................................................................................................... 17
METRICS AND REPORTING............................................................................................................................ 18
OBJECTIVES..................................................................................................................................................... 18
HOW WE MEASURE SUCCESS........................................................................................................................... 18
Metrics........................................................................................................................................................ 18
Key Performance Indicators........................................................................................................................ 18
Critical Success Factors.............................................................................................................................. 19
CONTINUAL IMPROVEMENT INITIATIVES..................................................................................................... 19
REVISION HISTORY......................................................................................................................................... 20

2
Info-Tech Research Group
 3
Info-Tech Research Group
Introduction: How to Use This Template
To use this template, simply replace the text in dark grey with information customized to your organization. When
complete, delete introductory or example text and convert all remaining text to black prior to distribution.

Purpose
Describe the factors or circumstances that mandate the existence of the procedure. Also, state the procedure’s
basic objectives and what it is meant to achieve

This Release and Deployment Management (RDM) Standard Operating Procedure seeks to ensure a balanced
and logical approach to managing the lifecycle of IT service releases across the enterprise. Establishing a
standardized process approach to RDM will aid in managing the continuous delivery of IT services across the
enterprise.

Scope
Define to whom and to what systems this procedure applies. List the employees required to comply or simply
indicate “all” if all must comply. Also, indicate any exclusions or exceptions that are out of scope, i.e. those
people, elements, or situations that are not covered by this procedure or where special consideration may be
made.

This Standard Operating Procedure applies to all business processes and data, information systems, and
components of [Company Name].

This document covers the complete release and deployment management process, from the initial approval from
change management through to planning, testing, and deploying a release.

Objectives
Create a standardized release and deployment process that provides measurable value for the business by
achieving the following:
 Deliver IT releases faster and more efficiently with visibility into risk, impact levels, and resources.
 Commit to enabling internal customers to use the new or changed service in the way it was intended.
 Drive consistency in implementations across functional teams necessary in release management.
 Ensure auditable requirements are met during all service transition activities.

Definitions
Define any key terms, acronyms, or concepts that will be used in the procedure or accompanying policies. A
standard glossary approach is sufficient.

Release: A collection of authorized changes to an IT service. This includes hardware, software, documentation,
processes, or other components required when implementing one or more approved changes to IT services.

Release Unit: A portion of a service that is normally released together according to the organization’s release
policy.

Release Package: A release package may be a single release unit or a structured set of release units, including
the associated user or support documentation that is required.

Deployment: The activity responsible for movement of approved releases of hardware, software, documentation,
or processes to test and production environments.

4
Info-Tech Research Group
 Roles and Responsibilities
It is the responsibility of the IT staff to work within the guidelines of the Release and Deployment Management
Policy to minimize the chance of failed releases, increase the number of deployments completed on schedule,
and increase the level of automation present for releases.

The following RACI chart outlines which positions are Responsible, Accountable, Consulted, and Informed for
each release management process.

Modify the chart below with the output from Phase 1 in the blueprint.

Release Test Coordinator

Configuration Manager
Infrastructure Manager

IT Operations Manager
Development Manager

Service Desk Manager

Release Coordinator
Information Security

Release Manager
Change Manager

Release and
Deployment (R&D)
CIO

Management Tasks
Obtain and track release I C A R I I I I I
approval through change
management
Issue escalation and I C I A R C C C C C R
notification procedures
Establish an implementation C A R C C C C C
plan
Plan business process, C A R R C C C C
system and data conversion
I C A C R I I I I C
Plan acceptance tests
I A C R I I I I C
Establish test environment

I/C A C R C C C C
Perform acceptance tests

Promote to production and C C A R R R R R R I

manage releases
Provide early production I A R C R R R R C
support
Perform a post- I C A R C R R R R
implementation review (PIR)
Provide metric reporting on I I I A R C C C C C I
overall health of the release
and deployment practice

Release and Responsibilities

Deployment Team

5
Info-Tech Research Group
  Manages the quality and controls of all activities in the release management
lifecycle; ensures PIRs are actioned and documented in a continual service
improvement (CSI) register.
R&D Manager
 Drives continuous improvement efforts in the build, test, and deploy phases.
 Handles escalations and conflicting priorities during the release lifecycle.
 Manages the releases through change management and communicates
approval status to the Release Review Committee.
 Plans the release implementation and coordinates project teams.
 Develops implementation plans and schedules.
 Ensures proper implementation training is in place.
 Provides updates and communicates issue resolutions to Release Manager.
R&D Coordinator
 Drives stakeholder communication standards throughout the phases of each
release and tracks feedback for improvements.
 Ensures policy and build procedure documents are up to date and accurate;
reviews policy suite on an annual basis.
 Provides test procedures, use cases, verification of workflow, and validation
R&D of data integrity to verify all processes are back online.
 Prepares test environment for release testing.
Testing Coordinator
 Designs, schedules, and prepares test environments and assembles required
resources.
 Records and documents final results received from Release Team.
 Assigned by the R&D Coordinator on a per project basis. Comprised of
subject matter experts (SMEs).
 Establishes final release configuration, provides build procedure
R&D Project Team
documentation, and ensures the configuration management database
(revolving) (CMDB) and definitive media library (DML) are updated with all changes.
 Tests the final delivery prior to independent testing.
 Identifies and reports outstanding known errors and workarounds.

Release Lifecycle
The release and deployment management process at [Company Name] will adhere to a release lifecycle (RLC).
The RLC will be comprised of [five] sub-processes. These include:
 Intake and Planning
 Design & Build
 Testing
 Deployment
 Post-Deployment

Each subprocess is under the purveyance of the Release Manager. The post-deployment process ends when
support for a new release is transferred to the Service Desk Manager.

The hand-off period will be [two weeks], during which the Release Manager will work with the Service Desk
Manager to transfer knowledge and process surrounding the support of the new release.

Multiple release cycles can run in parallel based on the types of releases currently being built and deployed to
[Company Name]’s environment.
Insert the target state lifecycle workflow diagram completed in Phase 1. Below is the sample workflow provided in
the blueprint.

6
Info-Tech Research Group
Release Planning
Release planning controls the intake and planning of new releases to establish a standard process for a new
release lifecycle.

The RDM team will use the following criteria to assess the inclusion of service requests in a release package:
 Urgency of the service request to be provided to the business
 The complexity of the integration
 Risk to business continuity
 Work required to implement the service request
 Resource availability
 Release type

Release Types
Customize based on agreed types documented in tab 4, “Release Bundles” in the Project Roadmap Tool.

Release Type Description

Scheduled as needed; target critical system service requests where core business
Emergency (P1) continuity is affected, large user base is impacted, and there is significant data breach.

Major enhancements/upgrades, significant technical/functional impact on the production

High (P2) system, integrated testing required.
Minor enhancements/upgrades, significant technical/functional impact on the production
Medium (P3) system, may require integrated testing.
Minor enhancements with standalone impacts, master data break/fix changes, may have
Low (P4) functional impact, no integrated testing required.

7
Info-Tech Research Group
Release and Deployment Planning Workflow
Insert the target state release and deployment planning workflow diagram completed in Phase 2. Below is the
sample workflow provided in the blueprint.

Emergency Releases
A separate workflow must be created for emergency releases to minimize ad hoc activities during the
development of the required release.

Emergency releases must be accompanied by a separate Emergency Release Report that includes, but is not
limited to, the following information:
 Summary of the change
 Analysis and impact of the change
 Test results
 Sources affected
 Release specifications

8
Info-Tech Research Group
Emergency Release Workflow
Insert the target state emergency release workflow diagram. Below is the sample workflow provided in the
blueprint.

9
Info-Tech Research Group
Release Classification and Priority
Assessing Risk
Work with your security team to establish risk assessment and modify the definitions below to reflect your
organization’s classification scheme. Below are samples from the blueprint.

Critical Releases: The emergency process will require similar due diligence to regular releases but may have a
shortened period for testing. Risk will need to be evaluated before release to balance the threat of not
implementing the patch with the risk of affecting the business with a failed deployment. Typically, major
performance issues or impending security risks are the only times releases will be implemented immediately.

Major Releases: Major releases include significant changes to functionality such as new features, upgrades,
integrations, or structure. The user interface may change, and additional user testing and training may be
required. These releases happen less frequently and often require planning with the business to minimize
disruption.

Minor Releases: Minor releases generally include bug fixes, minor feature changes, and security patches. These
tend to be released frequently and will not affect users, other than fixing bugs in code.

10
Info-Tech Research Group
Release Vulnerability Matrix
Work with your security team to establish risk tolerance. The table provides a brief overview of assessing
vulnerability – modify it to reflect your organization.

Vulnerability Deployment Exposure Impact Simplicity

Rating

V1 – Major All systems Unauthenticated access Exploit successfully Exploit is written,

exposed from another less-secure deployed; full available, requires
network with control systems system control can basic skills to use
perimeter be gained

V2 – Minor Most systems Unauthenticated remote Limited access; Vulnerability exists,

exposed access DoS attack can be original work
launched required to use the
exploit

V3 – Low Some mostly Authenticated physical Can gain High level of

minor systems machine/network access information for a knowledge/skill
exposed preliminary required to use the
reconnaissance exploit
effort

System Criticality Matrix

Mission-critical systems or releases that affect many people should always come first, but the bulk of reported
problems are often individual problems with desktops. See step 2.2 of the blueprint for further details. Modify the
below table to meet the needs of your organization.

System Availability Impact on Security Impact on User Work

Rating Customers Stoppage

Critical 24/7 system Impact on security is Statewide/citywide Work totally stopped

occurring negative exposure

High Business system Impact on security is Local negative Significant loss of

needed now or within imminent within a day exposure work capacity, but
SLA time window can get some work
done

Medium Change request time Impact on security is Minimal negative Working with some
and implementation imminent within a week exposure loss of efficiency
SLA time fall within
normal business hours

Low Change request time Impact on security is No concern Workaround

and implementation imminent within a identified
time fall outside of month
normal business hours

11
Info-Tech Research Group
Release Severity Matrix
Modify the below table to reflect your organization.

Severity Description Time to plan Time to deploy

Critical system is down, little to no functionality, no workaround, 2 hours 2 hours

1 many services affected, many users affected.
Examples: New release knocks out a server, major security
breach requires emergency patch.
Functionality severely restricted, no workaround, several users 6 hours 6 hours
2 affected.
Examples: Workgroup server crash, VIP requests.
Basic functionality with some restrictions, workaround available, 2 days 2 days
3 Examples: New release affects users operating with a certain
environment, medium-usage application won’t work.
Minor problem, functionality unaffected, cosmetic or an 1 week 1 week
4 annoyance. Example: Minor application occasionally crashes for
a few users.

Approved Change Windows

Document the best times that are typically available to make changes. Include any annual change freeze
windows.

[LINK: Find the current release schedule here.]

Release Type Frequency Date & Time Deployment Model CAB Approval

Patch Tuesday Every Tuesday 3:00am EST WSUS No

Change Freeze Annual December 15-31 Emergency change only Yes

Yes

Yes

12
Info-Tech Research Group
Release Design and Build
Build Procedure
To enable the release and deployment process, we have created a build procedure template for hardware and
software deployments.

A "build" is a service that will be installed in actual working order – how it is actually installed and the various test
procedures to enable the functionality.

Modify this section and outline the agreed-upon design and build process.

[LINK: Build procedures are located here.]

Design and Build Workflow

Insert target state design and build workflow from the exercise in the blueprint. The below workflow is a sample.

13
Info-Tech Research Group
Approved Build Support Tools
Deployment Tool Procedure Location
Model

Release Testing
Test Planning Procedure
List the available test plans agreed to and modify the wording to reflect your organization. This should list only the
approved test plans that are aligned to each release type.

Once the design and build of the release is complete, create a detailed testing plan that includes:
 System testing
 Regression testing
 System integration testing
 User acceptance testing (UAT)

The RDM team will work to identify the integrated testing approach for the release. Items defined may include:
 Level of integration testing required throughout the sprint iterations that span the release.
 Number of integration test passes or release test sprints that may be included in the release and
deployment schedule.
 Entrance/exit criteria for integration testing.
 Various checkpoints for the integration testing.
 Listing of clients where the testing will occur.
 Defect definitions and other pertinent information surrounding the required integrated testing.

14
Info-Tech Research Group
Approved Test Plans

Test Plan Description Test Type Release Type Location

Evaluates the system’s behavior System testing LINK
Plan 1 and compliance with
requirements.
Tests the system to determine if Regression
Plan 2 the change has introduced any testing
bugs or regressions.
Tests how the changed system System
interacts with other systems. integration
testing
Tests the user interaction with User acceptance
the changed system; UAT occurs testing
in the later stage of testing and is
critical to determine if training is
necessary.
Tests the success of an uninstall; Rollback testing
if the release has to be
uninstalled, all components must
be returned to the state they
were in prior to installation.

Release Testing Workflow

Insert target state test workflow from the exercise in the blueprint. The below workflow is a sample

15
Info-Tech Research Group
Release Deployment
Modify this section to outline the target process for pre-deployment validation and deployment approval.

All deployments must have the approval or pre-approval from the Change Board. All requests for change (RFCs)
to the Change Board must include:

 Release type
 Risk level
 Business impact
 Build procedure and deployment model
 Test strategy
 Backout plan
 Communication plan
 Planned start and end time

[LINK: Change Management Process]

16
Info-Tech Research Group
Deployment Models
Modify the below table with the agreed-upon deployment models discussed during the blueprint exercises. The
models should also be in tab 5, “Deployment Test Plans,” in the Project Management Roadmap Tool.

Model Name Model 1 Model 2 Model 3 Model 4

(Big Bang) (Phased) (Push/Pull) (Automated)
Services The service is deployed Software is made Use of support tools.
deployed to all to a part of production available to a target
Definition users in one initially and then set of users in a
operation. repeated based on a central location for
scheduled plan. them to download
upon convenience.

Release Types

Benefits

Considerations

Tool Used

Post-Deployment Verification
Customize this section with the target verification process.

[LINK to pre- and post-deployment verifications checklist library.]

17
Info-Tech Research Group
Post-Deployment Workflow
Insert target state post-deployment workflow from the exercise in the blueprint. The below workflow is a sample.

18
Info-Tech Research Group
Metrics and Reporting
What is the overall goal of gathering the metrics you are choosing to gather? This section should highlight the
benefits to your organization and the value the data is bringing.

Metrics and their associated key performance indicators (KPIs) and critical success factors (CSFs) will be
recorded and tracked as part of the release and deployment management process at [Company Name].

Objectives
 To enable [Company Name] to have a standardized, stable release management practice.
 To reduce the productivity downtime for teams involved in the release production process.
 To support [Company Name]’s needs through defined, repeatable release processes.
 To reduce costly outages for the business resulting from poorly executed releases.
 To improve the agility and proactivity of IT as a whole as a result of increased capacity for change.
 To implement an RDM tool to assist with automation and data tracking.

How We Measure Success

Use metrics strategically to provide value to the organization.

Divide metrics into three categories:

 Operational metrics  e.g. number of releases in process
 Efficiency metrics  e.g. percentage of failed releases
 Quality metrics  e.g. percentage of customer satisfaction that resulted from a new release

Metrics
Type: Operational (O), Efficiency (E), Quality (Q)
Purpose: Process (P), Delivery (D)

Ref# Type Purpose Metric

M1 O P Number of releases implemented for a time period
M2 Q D Number of releases successfully implemented for a time period
M3 Q P, D Number of releases implemented causing incidents

M4 E, Q D Number of accepted known errors when release is implemented

M5 E P Total days for release development
M6 E P Number of releases rescheduled
M7 O, Q D Number of training questions received following a release

Key Performance Indicators

Ref# KPI Product
K1 Successful releases for a period of time M2 / M1 x 100
K2 Releases causing incidents M3 / M1 x 100
K3 Average days to implement a release M5 / M1

19
Info-Tech Research Group
 K4 Release efficiency M6 / M1
K5 Quality of releases being implemented (1 - (M4 / M1)) x 100
K6 Release training efficiency (1 - (M7 / M1)) x 100

Critical Success Factors

Ref# Critical Success Factor Indicator
C1 Successful release process producing quality releases K1, K5
C2 Consistent efficient release process K4, K6
C3 Release process maps to business needs K5, K6

Continual Improvement Initiatives

Insert the process of how you will feed initiatives to improve year over year. Do not include projects, as they will
change. Include the methodology and approach your organization takes to improvement efforts.

The RDM program at [Company Name] requires strategic foresight and a focus on continual improvement
initiatives in order to maintain momentum.

20
Info-Tech Research Group
Revision History
Version Change Author Date of Change

_____________________________________________________

For acceptable use of this template, refer to Info-Tech's Terms of Use. These documents are intended to supply
general information only, not specific professional or personal advice, and are not intended to be used as a
substitute for any kind of professional advice. Use this document either in whole or in part as a basis and guide for
document creation. To customize this document with corporate marks and titles, simply replace the Info-Tech
information in the Header and Footer fields of this document.

21
Info-Tech Research Group