ServiceNow Process Guide RELEASE

Release Management
Process Guide
Release Management
Process Guide
Table of Contents
1 Introduction .................................................................................................................................. 1
1.1 Overview.................................................................................................................................................. 1
1.2 Process Description .................................................................................................................................. 1
1.3 Process Goal............................................................................................................................................. 1
1.4 Process Objectives ................................................................................................................................... 1
1.5 Relationship with Other Processes ........................................................................................................... 2
1.6 Principles and Basic Concepts .................................................................................................................. 2
1.6.1 Policies ................................................................................................................................................ 2
1.6.2 Release Management Tables .............................................................................................................. 3
1.6.3 Software Distribution Control ............................................................................................................. 3
1.6.4 Managing the Release Process ........................................................................................................... 3
1.6.5 Release Units and Packages................................................................................................................ 3
1.6.6 Release Types ...................................................................................................................................... 4
1.6.7 Release States ..................................................................................................................................... 4
2 Release Process Roles .................................................................................................................... 4
2.1 RACI Matrix .............................................................................................................................................. 6
3 Release Management Activity Description ..................................................................................... 7
3.1 Process Overview ..................................................................................................................................... 7
3.1.1 Process Overview Activity Description ................................................................................................ 8
3.2 Plan the Release ..................................................................................................................................... 10
3.2.1 Release Planning Procedures ............................................................................................................ 11
3.3 Build and Test ........................................................................................................................................ 14
3.3.1 Build and Test Procedure .................................................................................................................. 15
3.4 Deployment ........................................................................................................................................... 17
3.4.1 Deployment Procedure ..................................................................................................................... 18
3.5 Review and Close ................................................................................................................................... 20
3.5.1 Review and Close Procedure ............................................................................................................. 21
4 Process Control ........................................................................................................................... 22
4.1 KPIs ........................................................................................................................................................ 22
4.2 Operational Data ................................................................................................................................... 22
4.3 Reports and Homepages ........................................................................................................................ 22
© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. i
Release Management
Process Guide
Figures
Figure 1 Process Overview
Figure 2 Plan the Release
Figure 3 Build and Test
Figure 4 Deployment
Figure 5 Review and Close
Appendices
Appendix A Document Conventions
Appendix B Release Management Plugins

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. ii
Release Management
Process Guide
1 Introduction
The concepts described in this guide are aligned with ITIL 2011 and may reference capabilities that are
dependent upon other ServiceNow applications. These references will be noted by blue italicized font.
1.1 Overview
A process is defined as a set of linked activities that transform specified inputs into specified outputs,
aimed at accomplishing an agreed-upon objective in a measurable manner. The process definition laid
out in this document further breaks down these activities into actions and the role(s) responsible for
their execution.
This document also describes how ServiceNow supports the release management process with its
abilities to manage the planning, build and test, deployment, and review and closure phases of releases
to minimize risk to the IT environment when delivering new functionality.
1.2 Process Description
A release is one or more changes to an IT service that are built, tested and deployed together. Release
management is the process responsible for controlling the life cycle of releases to minimize the risk of
disruption to IT services.
1.3 Process Goal
The goal of the release management process is to enable beneficial changes to be made with minimum
disruption to business operations, thus ensuring that the best possible levels of service quality and
availability are maintained. This is accomplished through a formal approach that plans, schedules, and
controls the build, test and deployment of releases to deliver new functionality required by the business
while protecting the integrity of existing services.
1.4 Process Objectives
The objectives of release management are to:
 Define and agree on release and deployment management plans with customers and
stakeholders.
 Create and test release packages that consist of related configuration items that are compatible
with each other.
 Ensure that the integrity of a release package and its constituent components is maintained
throughout the transition activities and that it can be backed out, if appropriate.
 Record and manage deviations, risks, and issues related to the new or changed service and take
necessary corrective action.

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. 1
Release Management
Process Guide
 Ensure there is knowledge transfer to enable customers and users to optimize their use of the
service and service operation functions to deliver, support, and maintain the service according
to required service levels.
1.5 Relationship with Other Processes
Process Relation Description Input Output
Change management provides the authorization for the work that

X
is carried out in a release.
Change  Release management provides the actual execution of many

Management changes.
X
 Release plans are a significant part of the change schedule and
they must be managed together.
Knowledge Knowledge management provides pertinent information such as

X
Management operational support information and Service Desk information.
Problem Known errors introduced as part of the release deployment are

X
Management documented.
Service Catalog The service catalog item is created, or revised, to reflect
X
Management information about the new, or revised, service.
Information from configuration management (CMDB) is used to

plan and coordinate the release changes to business services or X
Configuration configuration items (CIs).
Management
Release management provides updates to CI information to ensure
X
that CMDB data is kept up to date.
1.6 Principles and Basic Concepts
1.6.1 Policies
Policies are formally documented management expectations and intentions that are used to direct
decisions and ensure consistent and appropriate implementation of processes, standards, roles, and
activities. Policies may also dictate specific tool requirements. Examples of common release
management policy topics include:
 All changes to an individual service will be packaged into releases (annual, monthly, bi-weekly,
etc.) and the only permitted changes between these releases will be to resolve problems that
have a major impact on the business.
 All changes and releases must be fully tested under a realistic load before they are deployed.
 Acceptance criteria will be established for each release.

Release Management
Process Guide
 Training requirements for identified users and technical support will be assessed for all releases.
1.6.2 Release Management Tables
 Products: represents the hardware or software for which releases will be built. A product can
be linked with a business service in the CMDB to link it with other ITIL processes.
 Releases: represents planned releases for a product. The content of a release is defined by the
features and associated requests for change that it implements.
 Features: represents the individual changes being made to the product. A feature may also be
associated with a configuration item or a change request, and to a parent release.
 Release Phases: represents the planned phases that a release will have, which are used to
group the tasks required to implement the release.
 Release Tasks: represents any of the tasks required to implement a feature of a product.
 DSL: represents digital media that store the product at time of release. Although it is not a CI, it
can be related to a CI with a reference field.
1.6.3 Software Distribution Control
The ServiceNow platform allows the release management team to control the distribution of software
through the creation of a Definitive Software Library (DSL) stored in the CMDB. The DSL table is a logical
store that indexes all software, releases, and versions, highlighting where the physical media can be
located. Both physically and logically stored software are represented as records on the DSL table stored
in the CMDB.
1.6.4 Managing the Release Process
Because features, phases, and release tasks extend the Task table, all of the task management tools in
the ServiceNow platform are available to manage their use:
 Approval Rules automatically issue approvals to involved parties based on predefined

conditions.
 Assignment Rules automatically assign tasks to users or groups based on predefined conditions.
 Workflows define and automate multi-step execution processes to standardize how work is
performed.
In addition, scripts such as business rules and scheduled jobs can further increase the automation of the
process.
1.6.5 Release Units and Packages
A release unit consists of components of an IT service that are normally released together. A release unit
typically includes sufficient components to perform a useful function. For example, one release unit
could be a desktop PC, including hardware, software, licenses, documentation, etc. A different release
unit may be the complete payroll application, including IT operations procedures and user training.

Release Management
Process Guide
A release package is a set of configuration items that will be built, tested and deployed together as a
single release. Each release package will usually include one or more release units.
1.6.6 Release Types
Many organizations define different categories of releases that may be managed differently. For
example, major releases may be on a fixed schedule whereas emergency releases may be scheduled as
necessary and require a different approval process. The ServiceNow Release form, and workflow, can be
modified to accommodate the specific release categorization schema requirements of each organization.
1.6.7 Release States
Releases should be tracked throughout their life cycle to support proper handling and reporting. The
state of a release indicates where it is in relation to the life cycle and helps determine what the next step
in the process might be. The typical uses of the workflow state values in the ServiceNow base system
are:
 Draft: default value upon creation. The release is in the planning phase.
 Scoping: release features and feature tasks are defined.
 Awaiting Approval: the release has been submitted for approval.
 Work In Progress: the build phase of the release is in progress.
 Testing/QA: the testing phase of the release is in progress.
 Deploy/Launch: the release is in the process of being implemented.
 Closed Complete: the deployed release has been reviewed and closed.
 On Hold: the release activities have been suspended.
 Cancelled: the release has been closed because it is no longer required.
2 Release Process Roles
Each role is assigned to perform specific tasks within the process. Within a specific process, there can be
more than one individual associated with a specific role. Additionally, a single individual can assume
more than one role within the process although typically not at the same time. Depending on the
structure and maturity of a process, all roles described may not exist in every organization.
The following describes the typical roles defined for release management.

Release Management
Process Guide
Role Description
Process Owner A senior manager with the ability and authority to ensure the process is rolled out and
used by all departments within the IT organization.
Responsible for:
 Defining the overall mission of the process.
 Establishing and communicating the process mission, goals, and objectives to all
stakeholders.
 Resolving any cross-functional (departmental) issues.
 Ensuring consistent execution of the process across the organization.
 Reporting on the effectiveness of the process to senior management.
 Initiating any process improvement initiatives.
Release Manager Responsible for:
 Managing the day-to-day activities of the process.
 Gathering and reporting on process metrics.
 Tracking compliance to the process.
 Ensuring that release requirements have been identified and addressed.
 Producing and maintaining an up-to-date forecast of releases.
 Working closely with change owners to ensure that new functionality is delivered
without negatively impacting existing services.
 Participating in the Change Advisory Board (CAB) meetings.
Release & There may be a different coordinator for each specific release.
Deployment
Coordinator Responsible for:
 Developing detailed release plans
 Acting as a liaison to appropriate management
 Defining and managing the release communication plan
 Coordinating the release build, test, and deployment activities, as appropriate.
 Participating in the release review prior to closure.
Implementers This role may also be referred to as release packaging or deployment practitioner.
Responsibilities of this role include the building, testing and physical deployment tasks
associated with approved changes of a release that may be assigned to multiple
individuals.
Change Advisory The CAB is typically comprised of representatives from all areas of IT, the business,
Board (CAB) and possibly third-party providers or suppliers. It supports the assessment,
prioritization, authorization, and scheduling of changes.
Responsible for:
 Reviewing and approving RFCs.
 Reviewing the change schedule and providing information to help identify
conflicts or resource issues.

Release Management
Process Guide
Role Description
 Reviewing projected service outages.
 Reviewing unauthorized and failed changes.
2.1 RACI Matrix
Roles and responsibilities are assigned to specific process activities.
Change Advisory Board

Release Process Owner
Release Coordinator
Release Manager
Implementer(s)
ID Activities
Release Process Planning
REL P1 Define products. A R C
REL P2 Define release phases and phase advancement rules. A R C I
REL P3 Determine plugin usage (SDLC, SCRUM) A R C I
REL 1 Plan the Release
REL 1.1 Create release record. A/R C I
REL 1.2 Document requirements and acceptance criteria. A/R C
REL 1.3 Design the solution and release package. A R I
REL 1.4 Schedule activities and resources. A R C
REL 1.5 Define and create release plan details. A R C
REL 1.6 Assess and authorize. I C A/R
REL 3 Execute the Deployment
REL 3.1 Conduct readiness assessment. A R C
REL 3.2 Plan and schedule deployment. A R C
REL 3.3 Request deployment approval I A/R I C
REL 3.4 Authorize deployment. C C R I
REL 3.5 Execute the deployment plan. I A R
REL 3.6 Verify deployment. A R C
REL 3.7 Support early life. A R
REL 4 Review and Close the Release
REL 4.1 Review the release. A/R C
REL 4.2 Close the release. A/R C
Continuous Service Improvement
REL C1 Conduct periodic release reviews. A R C I
REL C2 Implement service improvement plans. A R C I
R: Responsible A: Accountable C: Consulted I: Informed

Release Management
Process Guide
3 Release Management Activity Description

3.1 Process Overview
Figure 1: Process Overview

Release Management
Process Guide
3.1.1 Process Overview Activity Description
ID Activity Description
REL P1 Define Products Before executing a release process, define the products whose releases will be managed. A product record stores
information about the product for reference purposes, as well as grouping together all of the releases and features
for a single product.
REL P2 Determine Plugin Release management plugins enhance release functionality by implementing a new data structure and new user
Usage interfaces to make managing a release more flexible and more powerful. See Appendix B for a detailed description of
these plugins.
REL P3 Define Release The sequence of the release lifecycle phases can vary based on the release type. For example, if the type is Bug Fix,
Types and Phases the phases may be Build, Accept, and Deploy, whereas the phases of a Major release may include Planning, Testing,
and Review and Closure.
REL 1 Plan the Release This activity defines the specific plans for the release that are agreeable to all relevant stakeholders, and that support
the fulfillment of the changes involved in the release. The plans are subject to authorization requirements specified
in the release policy. Plans are updated and refined as necessary throughout the life cycle of the release.
REL 2 Build and Test The build and test activities start with authorization to build the release, and end with change management
authorization for the release package to be checked into the DSL via the configuration management process. During
this phase, the release might cycle through multiple iterations of building, testing, and authorization activities until
the release package is ready for deployment and the change authority is satisfied.
REL 3 Execute the Deployment activities begin with authorization to deploy the release package to one or more target environments,
Deployment and end with a handover to the service operation functions and early life support. The continuing referral to the
release plan documents achieves a smooth, effective transition into the live environment while protecting the
integrity and stability of all existing IT services.
REL 4 Review and Close The review and close phase marks the conclusion of the release management process. This phase provides a formal
review of the release including all of the deployment activities performed in the previous phase, as well as the final
status of the release record, which is reflected in the associated change records.

Release Management
Process Guide
ID Activity Description
REL C1 Conduct Periodic On a routine basis, evaluate the effectiveness and efficiency of the release management process to identify process
Release Reviews improvement opportunities.
REL C2 Implement Service

Develop and implement improvement plans that address the specific release management weaknesses or gaps
Improvement
identified during the reviews.
Plans

Release Management
Process Guide
3.2 Plan the Release
Figure 2: Plan the Release

Release Management
Process Guide
3.2.1 Release Planning Procedures
ID Tasks Procedure Primary Role Input Output
REL 1.1 Create Release From the Release application, create a Release Authorized Change records New release record
Record new release record. Manager
REL 1.2 Document Documentation of requirements and Release New release record Release record with
Requirements specifications is generally completed in Coordinator documented
and Acceptance the Planning phase but may be requirements and
Criteria reviewed and revised throughout the acceptance criteria
process. Planning and communicating
the acceptance criteria before work
begins is important to set stakeholder
expectations and establish how the
release will progress. The Release
Manager ensures that requirements,
specifications and acceptance criteria
are documented and included in, or
attached to, the release record.
REL 1.3 Design the A solution is designed that considers Release Release record with documented Release record with a
Solution and strategies and constraints, as well as the Coordinator requirements and acceptance documented solution
Release Package impact or compatibility with other IT criteria design and list of CIs
services. The design also includes the to be included in the
tools and systems needed to support release package
the build, test, deployment, operation
and continual improvement of the IT
service. The retirement of any IT service
or component is also subject to design
in the same way.
Based on the solution design, the
Release Coordinator can ensure that a

Release Management
Process Guide

release package is designed to include
all CIs that will be built, tested, and
deployed together as a single release.
New and existing CIs are listed in the
release package.
REL 1.4 Schedule The schedule of activities and Release Release record with a documented Release record with
Activities and associated resources is effectively a Coordinator solution design and list of CIs to be associated task
Resources working document that is updated all included in the release package records containing
the way through the conclusion of the start/complete dates
release process. Release policies may and assigned
dictate how resources are assigned to resources
specific release tasks.
Create release task records and assign
resources as appropriate.
REL 1.5 Define and Release plan details may vary, Release Release record with associated task Release record with
Create Release depending upon the complexity of the Coordinator records containing start/complete all required plans
Plan Details release. These specific plans provide dates and assigned resources completed
the release implementer(s) with the
information they need to coordinate
and perform all of the release tasks.
Areas that may be addressed in these
plans include:
 Development and testing
methodology
 Scheduling of build and test
activities
 Defining roles and responsibilities

Release Management
Process Guide

 Establishing build and test
procedures
 Defining the success criteria for
each build
 Remediation/Backout plan
Upon completion of planning activities,
the release record and associated
documentation are submitted for
review and approval.
REL 1.6 Assess and The CAB reviews the release plans and Change Release record with all required Release approved for
Authorize either approves for transition to the Advisory Board plans completed Build phase, or,
build phase or identifies additional Release returned for
areas to be addressed in the planning further additional
phase. planning.

Release Management
Process Guide
3.3 Build and Test
Figure 3: Build and Test

Release Management
Process Guide
3.3.1 Build and Test Procedure
REL 2.1 Construct and Whether constructing a new Implementer(s) Approved release record with all Newly constructed
Manage the Build environment or leveraging an existing required plans documented build and test
and Test one, the build environment must be environments
Environments managed so that it remains stable and Or
valid. Management of the build
environment is best achieved with Re-configured
automation, version control, baseline existing build and
management, and the control of inputs test environments
and outputs.
REL 2.2 Create/Acquire/V The Release Coordinator ensures that Release Release record with a documented Release package with
erify Packaging the CIs in the release package are Coordinator/ solution design and list of CIs to be CIs verified
Components produced (created or acquired) and that Implementer(s) included in the release package
they comply with the verification
requirements. The Implementer(s) use
the schedule and release documents to
complete their assigned activities.
Additional CIs may be added to the
release package, as needed.
REL 2.3 Create, Acquire Develop/acquire documentation Release Release package with CIs verified Release package with
and Manage specific to the release package CIs as Coordinator accurate and
Documentation the build activities are executed. updated
documentation

Release Management
Process Guide
REL 2.4 Test Depending upon the complexity of the Implementer(s) Release package with accurate and Successfully tested
release, a number of tests will be updated documentation and test Release package with
performed to ensure that the release is plans from REL 1.5 documented test
ready for deployment. These may results
include:
 Component and assembly testing
 Release testing
 Operational readiness testing
 Service testing (User Acceptance)
 Pilot testing
REL 2.5 Finalize the This activity is focused on validation of Release Successfully tested release package Validated release
Release Package the release package against all Coordinator with documented test results package
requirements to plan, build, and test
the release. The output of this activity
may be a validation report that includes
a prioritized accounting of issues and
recommended actions based on the
results of activities and other
considerations relative to the design
and plans.

Release Management
Process Guide
3.4 Deployment
Figure 4: Deployment

Release Management
Process Guide
3.4.1 Deployment Procedure
REL 3.1 Conduct In this activity, the Release Coordinator Release Validated Release package Release package with
Readiness checks that the target groups are truly Coordinator completed readiness
Assessment ready before they are affected by the assessment report/
deployment of the release. Target information
groups include personnel who deliver
training and communications,
deployment groups, customers, users,
IT Services staff, and other stakeholders
such as suppliers and partners.
REL 3.2 Plan and Verify and finalize the detailed Release Release package with completed Release package ready
Schedule deployment plans before requesting Coordinator Readiness Assessment report/ for CAB review and
Deployment deployment authorization. This may information approval
include the adding activities that were
identified from the assessment and
assigning resources to these activities.
The deployment schedule is reviewed
and revised as necessary.
REL 3.3 Request Coordinate with the owners of the Release Release package ready for CAB Scheduled CAB review of
Deployment related change records to invoke the Coordinator review and approval release package
Approval change management process for
purposed of CAB review and
deployment approval.

Release Management
Process Guide
REL 3.4 Authorize Review the release package and either: CAB Scheduled CAB review of release  Authorization to
Deployment package deploy
 Authorize the deployment, or
Or
 Request revisions to the
deployment plan and/or schedule  Request to revise
release deployment
plan and/or
schedule
REL 3.5 Execute the This high-level activity includes Implementer(s) Authorization to deploy Updated release task
Deployment Plan numerous sub-activities to records that reflect
communicate, conduct training, deploy deployment activity
new or changed CIs, and decommission completed
any retired service assets. Release task
records should be updated in a timely
manner to reflect the current state of
each deployment activity.
REL 3.6 Verify The Release Coordinator ensures that Release Updated release task records Verified release
Deployment all activities are completed as described Coordinator that reflect deployment activity deployment and release
and specified in the release plans, and completed record ready for closure
that the release record is accurately
updated. This activity is typically
initiated in parallel with executing the
deployment plan.
In the event that the release
deployment fails, the Release
Coordinator ensures that the
remediation plan is executed and
updates the release record and
schedule of assigned activities
accordingly.

Release Management
Process Guide
REL 3.7 Support Early Life This high-level activity provides support Implementer(s) Completed release deployment Formal handover to
for the new or changed service while service operation
the fully deployed release is
transitioned from the deployment team
to service operation.
3.5 Review and Close
Figure 5: Review and Close

Release Management
Process Guide
3.5.1 Review and Close Procedure
REL 4.1 Review the  Confirm that all release activities Release Verified release deployment and Reviewed and
Release are completed, and that all Manager release record ready for closure verified release
documentation and information are record
captured, updated, secured, and
archived, as necessary.
 Verify that accurate metrics were
captured
REL 4.2 Close the Release Change the State field on the release Release Reviewed and verified release record Closed release record
record to ‘Closed Complete’. Manager

Release Management
Process Guide
4 Process Control
4.1 KPIs
KPIs are best represented as trend lines and tracked over time. They provide information on the
effectiveness of the process and the impact of continuous improvement efforts.
KPI/Metric Purpose
Number/percent of completed releases that Measure of process effectiveness. Well-tested and planned
caused incidents. releases should not give rise to incidents.
Number/percent of releases completed on Measure of the accuracy of release planning activities and
time. the efficiency of the release process.
Customer satisfaction. Measure of how well release end user communication and
training have been provided.
4.2 Operational Data
Active changes that require visibility, oversight, and possible management intervention are best tracked
on a dashboard or homepage that is monitored by the Release Manager.
KPI/Metric Purpose
Forward schedule of changes. Provides a calendar view of all releases that have been
approved for deployment.
List of releases awaiting CAB or ECAB approval. Provides a view of work in progress.
List of open emergency releases. Provides a view of higher risk releases that are in progress.
List of releases that caused incidents. Provides a quick view of releases that need investigation to
determine if process improvements are needed.
4.3 Reports and Homepages
There are numerous default reports available in ServiceNow that can be used to generate charts, publish
to a URL, or schedule to be run and distributed at regular intervals. Users can also create custom
reports. See Creating Reports in the Wiki for more detail on this capability.
In addition to reports, each user can create a personal homepage and add gauges containing up-to-the-
minute information about the current status of records that exist in ServiceNow tables. See Customizing
Homepages in the Wiki for details.

Release Management
Process Guide
Appendices

Release Management
Process Guide
Appendix A: Document Conventions

Symbol Description
Process start or end point: represents the starting and ending point of the
process.
Process activity or task: presents an activity or task that needs to be accomplished

to produce a specific outcome.
Predefined external process or organization: indicates a contribution from an

external process or organization.
Decision: indicates that a question needs to be answered in order to identify the

following activity or task in the process. The answers are indicated on the different
connectors attached to the decision box. Every answer is linked to an associated
activity or task.
System action or function: indicates that an action is being performed in the

system as an output of the previous activity and an input to the next.
Off-page reference: indicates a reference to another diagram within the same

process. The number of the referenced diagram is indicated in the shape.
On-page reference: indicates a link to another activity within the same diagram.
Association: indicates an association or a relation between the connected,

processes, tasks, or activities. May be represented by a dotted or dashed line.
Sequence flow: shows the order in which the activities are performed.
Represented by a solid line and arrowhead.

Release Management
Process Guide
Appendix B: Release Management Plugins

The ServiceNow platform provides three primary plugins for managing a software release process. All
three plugins consist of tables extended from the Planned Task table shared with project management.
This allows all of the release structures to take advantage of the existing planned task functionality, like
scheduling, task dependencies, utilizing the Gantt chart, resource, and time card management.
Release Management v2 plugin is the most basic of the three plugins. It is designed with a flexible
Product, Release, Feature, and Task hierarchical table layout to allow for releases of varying complexity.
The following tables represent the concepts that underlie Release Management:
 Product [rm_product]: represents whole products whose releases are being managed.
 Release [rm_release]: represents individual versions of the product.
 Release Phase [rm_release_phase]: represents the different stages of work required to
complete a release.
 Feature [rm_feature]: represents each feature within the release.
 Release Task [rm_task]: represents tasks to create individual features.
SDLC - Software Development Life Cycle plugin further extends the Release Management v2 plugin by
adding some new structures to accommodate the software development life cycle. This plugin is
designed to accommodate most non-agile development methodologies, including the common waterfall
method of development. This plugin adds more specific 'Feature' types allowing for the independent
management of notions (such as defects, enhancements, testing tasks, etc.) critical to successful
software development. The following tables support the Software Development Life Cycle:
 SDLC Release [rm_release_sdlc]: represents individual versions of the product.

Release Management
Process Guide
 Release Phase [rm_release_phase]: represents the different stages of work required to

complete a release.
 The following tables represent different types of features included in a release:
- Enhancement [rm_enhancement]: represents an improvement to an existing product.
- Defect [rm_defect]: represents a deviation from a product's expected behavior.
- Documentation [rm_doc]: represents documentation tasks for the product.
- Testing Task [rm_test]: represents testing tasks for the product.
 Release Task [rm_task]: represent tasks to create individual features.
The SDLC - Scrum plugin includes the two plugins above, and adds sprints and feature types specific to a
Scrum development process. The following tables support a Scrum process:
 The following tables represent releases:
- Scrum Release [rm_release_scrum]: represents individual versions of the product.
- Sprint [rm_sprint]: represents the backlog to be addressed together.
 The following tables represent product backlog items to be included in the sprint:
- Epic [rm_epic]: represents related stories or requirements that you have not yet
transformed into stories.
- Story [rm_story]: represents self-contained pieces of work that can be completed within a
sprint.
- Documentation [rm_doc]: represents documentation tasks for the product.
- Testing Task [rm_test]: represents testing tasks for the product.

Release Management
Process Guide
SDLC - Scrum Process Pack plugin enhances the SDLC Scrum plugin by adding a formal Scrum process.
The SDLC Scrum Process Pack uses these tables to manage the Scrum process:
 Application Model [cmdb_application_product_model]: represents whole products whose

releases are being managed.
 Release Product [m2m_product_release]: represents all managed products.
 The following tables represent releases.
- Scrum Release [rm_release_scrum]: represents all available releases. Each release contains a
list of sprints with a time range in which the stories in those sprints need to be completed.
- Sprint [rm_sprint]: stores sprints, which are the backlog items to be addressed during a
given time period.
 The following tables represent items to be included in the sprint.
- Team [scrum_pp_team]: represents who will complete Scrum tasks and stories during
releases and sprints.
- Epic [rm_epic]: represents stories or requirements that have not yet transformed into
stories.
- Theme [scrum_theme]: represents either a tangible product (such as a trading application)
or an abstract goal (such as performance tuning).
- Story [rm_story]: represents self-contained pieces of work that can be completed within a
sprint.
- Scrum Task [rm_scrum_task]: represents a discrete amount of work for a story carried out
during a sprint.
- Enhancement [rm_enhancement]: represents an improvement to an existing product.

Release Management
Process Guide
See SDLC Scrum Process in the Wiki for a more detailed description of this functionality.


ServiceNow Process Guide RELEASE

Uploaded by

Copyright:

Available Formats

ServiceNow Process Guide RELEASE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ServiceNow Process Guide RELEASE

Uploaded by

Copyright:

Available Formats

What are the different roles involved in release management?

What are the different roles involved in release management?

What are the different tables used to manage releases?

What are the different tables used to manage releases?

Release Management

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.2 Process Description

1.3 Process Goal

1.4 Process Objectives

The objectives of release management are to:

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.5 Relationship with Other Processes

Process Relation Description Input Output

Change management provides the authorization for the work that

Change  Release management provides the actual execution of many

Knowledge Knowledge management provides pertinent information such as

Problem Known errors introduced as part of the release deployment are

Information from configuration management (CMDB) is used to

1.6 Principles and Basic Concepts

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.6.2 Release Management Tables

1.6.3 Software Distribution Control

1.6.4 Managing the Release Process

 Approval Rules automatically issue approvals to involved parties based on predefined

1.6.5 Release Units and Packages

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

1.6.6 Release Types

1.6.7 Release States

2 Release Process Roles

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

2.1 RACI Matrix

Roles and responsibilities are assigned to specific process activities.

Change Advisory Board

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3 Release Management Activity Description

Figure 1: Process Overview

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.1.1 Process Overview Activity Description

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

REL C2 Implement Service

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.2 Plan the Release

Figure 2: Plan the Release

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.2.1 Release Planning Procedures

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.3 Build and Test

Figure 3: Build and Test

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

3.3.1 Build and Test Procedure

ID Tasks Procedure Primary Role Input Output

© 2014 ServiceNow, Inc. All rights reserved. ServiceNow Confidential.

ID Tasks Procedure Primary Role Input Output