SERVICE EXCELLENCE PROGRAM

Release Management
Quick Reference Guide
for users of ServiceNow

November 2013

THIS GUIDE BELONGS TO:

 

TABLE OF CONTENTS 
TABLE OF CONTENTS ..................................................................................................................................... 1 
KEY RELEASE MANAGEMENT POLICIES (Rev. 2013‐12‐10) ........................................................................... 2 
RELEASE MANAGEMENT RECORD RELATIONSHIPS (Rev. 2013‐12‐10) ........................................................ 3 
RELEASE MANAGEMENT PROCESS PHASES (Rev. 2013‐12‐10) .................................................................... 4 
RELEASE PROCESS WORKFLOW TABLE (Rev. 2013‐12‐10) ........................................................................... 5 
Planning a Normal Release (Rev. 2013‐12‐10) .............................................................................................. 6 
DEPLOYMENT TASKS (Rev. 2013‐12‐10) ....................................................................................................... 7 
P‐1 APPROVALS (Rev. 2013‐12‐10) ............................................................................................................... 8 
PRODUCTION APPROVALS (Rev. 2013‐12‐10) .............................................................................................. 9 
FEATURE TYPES (Rev. 2013‐12‐10) ............................................................................................................. 10 
FEATURE: DEFECT CORRECTION OR ENHANCEMENT (Rev. 2013‐12‐10) ................................................... 11 
FEATURE: UPGRADE OR PATCH (Rev. 2013‐12‐10) .................................................................................... 12 
FEATURE: CONFIGURATION (Rev. 2013‐12‐10) .......................................................................................... 13 
FEATURE: APPLICATION DEPLOYMENT (Rev. 2013‐12‐10) ......................................................................... 14 
FEATURE: BACK‐END DATA CHANGE (Rev. 2013‐12‐10) ............................................................................ 15 
FEATURE: MONTHLY REPORTING (Rev. 2013‐12‐10) ................................................................................. 16 
TESTING A FEATURE (Rev. 2013‐12‐10) ...................................................................................................... 17 
RELEASE MANAGEMENT ............................................................................................................................. 18 
ROLES AND PERMISSIONS (Rev. 2013‐12‐10) ............................................................................................. 18 
NOTES: ........................................................................................................................................................ 19 
 

 
QUICK_REF_GUIDE_TEXT_V9.DOCX 

Page 1 
KEY RELEASE MANAGEMENT POLICIES (Rev. 2013‐12‐10) 
1. All  in‐scope  product  and  practice  teams  will  use  ServiceNow  for  Release  Management 
process.    However,  JIRA  may  be  used  to  manage  the  build  and  test  phase  that  includes 
capturing  requirements,  documenting  functional  and  technical  specs,  developing  and 
testing up to, but not including, P‐1 testing. 

2. Release activity and configuration items (CIs) comply with Harvard's Information Security 
policy. 

3. All Financially Significant release requirements for signoffs and significant control points 
reside in ServiceNow.   

4. An  Emergency  Release  can  only  be  used  to  address  a  production  outage  (e.g.  major 
incident, regulatory, security incident). 

5. An Exception Release is an out of cycle release, and the business must submit a business 
case for approval. 

6. Release versioning: major number is updated when the platform changes.  Minor number 
is updated for each release. 

7. Features must be tested and signed off before they are deployed into P‐1 and production. 

8. Releases  must  be  approved  by  the  Product  Manager,  the  Practice  Manager  and  the 
Release Manager before they are deployed into P‐1 or production, and must be installed 
by deployment teams separate to the technical contact in line with the audit requirement 
for separation of duties. 

9. Release  Management  will  inform  Change  Management  of  scheduled  deployments  into 
production. 

10. Change  Management  is  the  authority  for  approving  updates  to  the  CMDB.    However, 
Change Management delegates the responsibility of updating the CIs affected by a release 
and the responsibility for validating those updates to the Release Management process. 

11. If  a  feature  is  dependent  on  other  features,  it  must  be  documented  on  the  Dependent 
Features tab. 

12. The Release Management process shall comply with Harvard's policies and procedures for 
IT controls and governance. 

Page 2 
RELEASE MANAGEMENT RECORD RELATIONSHIPS (Rev. 2013‐12‐10) 
 

Page 3 
RELEASE MANAGEMENT PROCESS PHASES (Rev. 2013‐12‐10) 
 

P-3 P-2 P-1

Release Planning PRODUCTION
Development QA / Test Test/Stage for Production

Release Record Status READY

IN IN AWAITING P-1 AWAITING PROD READY FOR IN
IN PLANNING FOR IN P-1 CLOSED
DEVELOPMENT QA / TEST APPROVAL APPROVAL PROD PROD
P-1

Release Approval required Release Approval required

Feature Record Status

ANALYSIS & READY FOR READY FOR PROD AWAITING PROD READY FOR IN
DRAFT IN DEVELOPMENT READY FOR P-2 IN P-2 IN P-1 APPROVAL APPROVAL
CLOSED
DESIGN P-1 PROD PROD

When Feature status

moves past DRAFT, The Feature MUST be
Tasks are associated with a Release in Feature Approval required
automatically created. order to move to P-2.

Release Level Approvals:

Practice Manager and one or more Product
Group Managers must approve the release as
a package prior to deploy to P-1 and prior to
deploy to production. All Features in the
Feature Level Release must have
All Features must be in Ready for P-1 or Approvals: Practice a status of Closed
Ready for Prod status. Manager must or Cancelled in
approve each Feature order to close the
prior to deploy to Release.
production

Page 4 
RELEASE PROCESS WORKFLOW TABLE (Rev. 2013‐12‐10) 
Release Phase  Release Status  Release Status Update Trigger Feature Status Feature Status Update Trigger
Planning  In Planning  Open new Release record  Draft  Open new Feature record 
      Analysis & Design  Click button for Analysis & Design 
P‐3 Development  In Development  Click button for In Development  In Development  Status update from Pending on task to 
develop and unit‐test code 
OR 
Click button for In Development 
      Ready for P‐2  Click button for Ready for P‐2 
P‐2 QA/Test  In QA/Test  Click button for In QA/Test  In P‐2  Status update to Completed on task to 
deploy feature to P‐2 
      Ready for P‐1  Click button for Ready for P‐1 
  Awaiting P‐1 Approval  Click button for Awaiting for P‐1     
Approval 
  Ready for P‐1  Approval of release to P‐1     
P‐1 Test/Stage      In P‐1  Status update to Completed on task to 
deploy feature to P‐1 
  In P‐1  All features for release have In P‐1     
status 
      Ready for Production Approval  Click button for Ready for Production 
Approval 
    Click button for Request Approval  Awaiting Production Approval  Request for approval from Release Record 
  Waiting for Production  Click button for Awaiting for  Ready for Production  Approval of each feature for release to 
Approval  Production Approval  Production 
  Ready for Production  Approval of release to Production     
Production      In Production  Status update to Completed on task to 
deploy feature to Production 
  In Production  All features for release have In     
Production status 
Post‐production      Closed  Click button for Close after all features 
validated and CI updated where required 

  Closed  Click button for Close after all     
features validated and closed 
 

Page 5 
Planning a Normal Release (Rev. 2013‐12‐10) 

1. The Release Manager creates a new Release Release Record and clicking the New button (to
Record in coordination with the Product and add a new feature) or the Edit button (to edit an
Practice Managers, identifying the Release as existing feature) to the Release. For example, the
Normal. Release Manager typically enters certain feature
types (e.g., Upgrade/Patch, possibly
Release versioning—major number is updated when Configuration) and Product and Practice
the platform changes. Minor number is updated for Managers others (e.g., Enhancement, Defect
each release. Correction, possibly Configuration).
2. The Release Manager, Product Manager and The approval of a release as Ready for P-1 defines
Practice Manager establish the release schedule. the “Release Package” for that release.
Production start and Production end (i.e. projected 5. Approval is required at Ready for Production by
maintenance window) dates are mandatory. Use the the Practice Manager for every feature in the
Schedule tab of the Release Record to specify release.
additional milestone dates.
6. Release approvals are required at Ready for P-1
3. The Release Manager enters any release tasks and Ready for Production by the Release
(e.g., Refresh P-3, etc.) as appropriate by clicking Manager, Practice Manager and Product
the New button on the Release Tasks tab of the Manager.
Release Record.
Once a Release reaches a status of In P-1, only the
4. The Release Manager, Product Manager and Release Manager may add or remove features from a
Practice Manager enter features to be included in release.
the release by going to the Features Tab of the
 

Page 6 
DEPLOYMENT TASKS (Rev. 2013‐12‐10) 
1. Deployment tasks involve deploying features to various HUIT environments and
will have the Deployment task checkbox checked on the Task Record. The
Release Manager will identify Configuration Items (a mandatory field) associated
with the deployment task.

2. The Assigned to individual will open the Task Record, change the status to In
Progress and begin deployment activities.

The Assigned to individual for the deployment task may access the Deployment
instructions and the Back-out plan for the feature by going to the Deployment Plan
tab of the Feature Record.

3. The Assigned to individual completes the deployment activities as instructed by

the deployment instructions, updating the Work Notes in the Release Task
Record.

If there are Incidents created as a result of the deployment, Incident Management

procedures apply.

4. If Issues are identified during deployment, an Issue record is created.

Do not combine multiple issues (bugs) in a single Issue Record. Create an Issue
record for each issue or bug identified.
If it is determined that a new feature is required to address the issue in production,
the Stabilization issue checkbox in the Documentation tab of the Feature Record
should be checked.

5. If the CI needs updating checkbox is checked, the Assigned to individual will

select the appropriate designation.

6. When the deployment is completed, the Assigned to individual sets the status of
the Task Record to Completed.

If the CI needs updating checkbox is checked, a Confirm CI updates for Feature task
will be created and assigned to the Release Manager.

Page 7 
P‐1 APPROVALS (Rev. 2013‐12‐10) 
Clicking the Awaiting for P-1 Approval button on the Release Record will display an
error message if there are Features included in the Release that are not yet in a
Ready for P-1 status.

1. When all Features associated with the release are in a Ready for P-1 status, the
Release Manager clicks the Awaiting P-1 Approval button. The release status
now reads Awaiting P-1 Approval.

2. The Release Approvers tab shows a related list form listing the approvers for the
release.

3. The approvers a) click on the Requested link associated with their approval to
open the Approval Record, or b) open the Approval Record by clicking the link
from a gauge on their Overview page.

4. Each release approver will open his Approval Record and click the Approve or
Reject button to approve or reject the Release.

If rejecting a release, comments are required indicating the reason(s).

The approval of a release as Ready for P-1 defines the “Release Package” for that
release. Only a Release Manager can add new features to the release.
When the release is Ready for P-1, the feature task Deploy FEATURE to P-1 is
created and the feature status remains Ready for P-1. When the task is completed,
the feature status automatically changes to In P-1.

5. The release will remain in a Ready for P-1 status until all the Features associated
with that release are in a status of In P-1. Once all the Features associated with a
release have a status of In P-1, the status of the Release will automatically
change to In P-1.

Page 8 
PRODUCTION APPROVALS (Rev. 2013‐12‐10) 
Clicking the Waiting for Production Approval button will present an error message if
any of the features included in the release are not yet in a Ready for Production
Approval status.

1. The Release, Product and Practice Managers for the features in the release
approve the release for production, and the Practice Manager approves each
Feature by opening the Approval Record and clicking Approve or Reject.

If rejecting a feature, comments are required indicating the reason(s).

At this point all features in the release will have a Ready for Production status.

2. The Release Manager clicks the Waiting for Production Approval button that
adds release approval records for the release and updates the status of the
release to Awaiting Production Approval.

3. The Release Approvers click on the Requested link associated with their
approval to open the Approval record, or open the Approval record by clicking the
link from a gauge in their Overview/Dashboard page.

Once all release approvers have approved the release, the status of the release will
change to Ready for Production.

4. Moving a Release to Ready for Production will trigger the automatic creation of
Deploy Feature to Production tasks for each Feature record in the Release.

Page 9 
FEATURE TYPES (Rev. 2013‐12‐10) 
Defect Corrections & Enhancements
 Defect Correction Feature types are used to fix bugs and application defects
 Enhancement Feature types are used to add functionality to an application
Upgrades & Patches
 Upgrade & Patch Feature types are used for operating system, database,
application server and/or web server patching
 This feature type does not create tasks unless CIs are added to the Affected
CIs tab
Configurations
 Configuration Feature types are used for tuning, changing settings and/or
configuration parameters on applications and devices
 While task names vary, Configuration Features follow the same workflow as
Defect Correction & Enhancement Features
 Making configuration changes to a front end that are dependent upon the
release
Application Deployments
 Application Deployment Feature types are used primarily by practices that
use JIRA for development and must be reconciled with ServiceNow to
complete the release
Monthly Reporting
 Monthly Reporting Feature types are used specifically for monthly reporting
requirements and should not be used for other purposes
Back-End Data change
 Back-End Data Changes are not typically associated with a release

Page 10 
FEATURE: DEFECT CORRECTION OR ENHANCEMENT (Rev. 2013‐12‐10) 

1. The creator of the Feature record selects Enhancement or Defect 4. When the Develop & unit test code for FEATURE task has a status
Correction as the Feature Type when creating the Feature record, of In Progress, the Feature record will automatically change its
enters all mandatory fields and saves the record with a status of status to In Development. The Ready for P-2 and Ready for P-1
Draft. buttons appear.
Features MUST be associated with a Release before moving to P-1
2. The creator of the Feature record must determine whether
except for Back-End Data Change Feature types.
additional documentation and/or impact implications are required. If
so, he clicks on the Documentation and/or Impact Implications tabs.
5. When the Release is Ready for P-1, the Feature task Deploy
FEATURE to P-1 is created and the Feature status remains Ready
3. When the Analysis & Design button is clicked, the status of the
for P-1. When the task is completed the Feature status
Feature record becomes Analysis & Design and the tasks
automatically changes to In P-1.
associated with the Feature are created.
If a checkbox on the Documentation or Impact Implications tabs is 6. Moving a Release to Ready for P-1 or to Ready for Production will
checked, additional tasks will be added. The Code Peer Review and trigger the automatic creation of Deploy Feature to Production tasks
Test Plan checkboxes will trigger mandatory fields (Technical / Func- for each Feature record in the Release EXCEPT for Feature Type
tional Contacts) Upgrade/Patch.

Page 11 
FEATURE: UPGRADE OR PATCH (Rev. 2013‐12‐10) 

The Upgrade/Patch workflow will NOT automatically generate tasks

1. The creator of the Feature record selects Upgrade/Patch as the
(i.e., the Deploy updates to P-2 for FETR0000000 task when the
Feature Type when creating the Feature record, enters all
Feature status is Ready for P-2).
mandatory fields and saves the record with a status of Draft.

Upgrade/Patch Feature types are typically created by Release

3. Complete tasks as required by the Feature for P-2 and P-1.
Managers or Practice Managers. The Release Manager adds CIs to the
Affected CI tab to create deployment tasks. Features MUST be associated with a Release before moving to P-1
except for Back-End Data Change Feature types.
2. Click the In Development button to change the status of the Feature
to In Development. The Feature displays a Ready for P-2 and a
Ready for P-1 button.

Page 12 
FEATURE: CONFIGURATION (Rev. 2013‐12‐10) 
 

Adding a configuration item (CI) under the Affected CIs tab triggers the
1. The creator of the Feature record selects Configuration as the
task for deploying the infrastructure change in the development
Feature Type when creating the Feature record, enters all
environment.
mandatory fields and saves the record with a status of Draft.

3. Complete tasks as required by the Feature for P-2 and P-1.

2. Click the In Development button to change the status of the Feature
to In Development. The Feature displays a Ready for P-2 and a The Configuration Feature type requires identification of the CI for the
Ready for P-1 button. installation to take place. The rest of the workflow for the Configuration
Feature type is the same as Enhancement and Defect Correction
Feature types from this point forward.

Page 13 
FEATURE: APPLICATION DEPLOYMENT (Rev. 2013‐12‐10) 

1. The creator of the Feature record selects Application Deployment 4. When the status of the Feature changes to In Development, the
as the Feature Type when creating the Feature record, enters all following tasks are created:
mandatory fields and saves the record with a status of Draft.
• Build FETR0000000 application for deployment

Application Deployment Feature types are limited to practices that use • Reconcile ServiceNow and JIRA Release
JIRA.
Features MUST be associated with a Release before moving to P-1
except for Back-End Data Change Feature types.
2. The creator of the Feature record goes to the External Tickets tab
of the Feature record and enters the JIRA ticket number and URL.
5. When the Release is Ready for P-1, the Feature task Deploy
FEATURE to P-1 is created, and the Feature status remains Ready
Documentation tracked in JIRA must be reconciled with ServiceNow for P-1. When the task is completed, the Feature status
before moving the Feature to a Ready for P-2 status. automatically changes to In P-1.

3. Click the In Development button to change the status of the Feature

to In Development. 6. Moving a Release to Ready for Production will trigger the automatic
creation of Deploy Feature to Production tasks for each Feature
record in the Release EXCEPT for Feature Types Upgrade/Patch.

Page 14 
FEATURE: BACK‐END DATA CHANGE (Rev. 2013‐12‐10) 

Back-End Data Changes are not typically associated with a release. When the Awaiting Production Approval button on the Feature is
clicked, the Feature status will be Awaiting Production Approval, and
1. The creator of the Feature record selects Back-End Data Change the Feature Approval records will be created for the Practice Manager
and the Product Manager.
as the Feature Type when creating the Feature record, enters all
mandatory fields and saves the record. If the Back-End Data
Change must be associated with a specific Release, enter that 3. When the Feature is approved the Feature status changes to
information in the Release field. Ready for Production, and a Deploy FEATURE to Production task
is created.
2. The workflow is the same as Enhancements & Defect Correction
Feature types. If the HDW Impact is checked on the Impact 4. When the Deploy FEATURE to Production task status is
Implications tab, the Review HDW impact for FEATURE task will be Completed, the Feature status will be In Production and the
created as well. Validate production install of FEATURE task is created. The Close
Feature button will display on the Feature record.

Page 15 
FEATURE: MONTHLY REPORTING (Rev. 2013‐12‐10) 

The Monthly Reporting feature type is identical to the Defect

1. The creator of the Feature record selects Monthly Reporting as the
Correction or Enhancement feature type with the following exception:
Feature Type when creating the Feature record, enters all
mandatory fields and saves the record with a status of Draft. Awaiting P-1 Approval and Ready for P-1 release statuses do not
apply.

Page 16 
TESTING A FEATURE (Rev. 2013‐12‐10) 
1. When the Feature status is In P‐2, the Functional Contact will be assigned a Validate and 
test feature in P‐2 for FEATURE task. The Functional Contact clicks on the Number link of 
the task in the related records list, opens the task by clicking the link from his dashboard 
or uses the Tasks assigned to me link from the application navigator.  
2. 2 Once the task is opened, the Functional Contact changes the status to In Progress and 
begins testing.  
3. 3 The Functional Contact enters information in the Work Notes of the task record as 
appropriate, and may create a Watch List to inform relevant stakeholders.  
4. 4 If a new Issue (bug) is identified, the Functional Contact will create an Issue record by 
going to the Issue tab on the Feature record and clicking the New button.  
Assignment group and Assigned to fields are mandatory for Issue records. Due date is 
optional.  

5. The Assigned to person for the Issue sets the status to In Progress and begins working 
the Issue, adding Work Notes as appropriate.  
6. When completed, the Assigned to person changes the status to Ready for Testing.  
7. The Functional Contact continues testing the Feature. When completed, the status of 
the task is changed to Completed.  

Page 17 
RELEASE MANAGEMENT 
Release [and Deployment] Management is the process responsible for planning, 
scheduling and controlling the build, test and deployment of releases, and for 
delivering new functionality required by the business while protecting the 
integrity of existing services. 
Source: ITIL® glossary and abbreviations (2011) 

ROLES AND PERMISSIONS (Rev. 2013‐12‐10) 
ServiceNow Role  Process Role  ServiceNow Permissions 
Release User  Practice Group members View Product & Release records 
Create/Update feature records 
Product Group members  (except Affected CIs Tab) 

DBAs  Create/Update Issue records 

Sys Admins  Create/Update Task records 
Approve feature 

Release Admin  Release Managers All Release user permissions 

Create/Update product record 
Create/Update release record 
Approve a release 
Assign Deployment Tasks to 
deployment group 
(Sys Admin DBA) 

Approve feature 
Add/Remove Features to release 
after In P‐1 status or later 
Edit the Affected CIs tab 
 

Page 18 
NOTES: 
 

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

  ____________________________________________________________________________________   

Page 19 
Call Support ServiceNow Login
(617) 495-7777 http://harvard.service-now.com

Email Support Email ITSM

[email protected] [email protected]

See Something, Say Something ServiceNow and ITSM help

(617) 496-2831 http://huit.harvard.Wedu/itsm