IT Service Management - Update Sets Best Practices.

According to ServiceNow, update sets can be defined as:

 "A grouping of customizations into a single package that can easily be promoted to other
instances."

Customizations include:

 Tables, Forms, Fields, Business Rules, Clients Scripts, Views, etc….

 Records in tables that contain the 'update_synch=true' attribute. (Dictionary entry for table,
'type=collection', and add the attribute 'update_synch=true')

Use update sets:

 To make change you intend to apply to other instances

 To ensure instances are in sync.

No need to use an update set when:

You are moving data from one source to another (use data extracts/import sets.)
All changes when not within a custom update set, will be tracked in the Default update set. ServiceNow
says that "This way we can see can see what you have changed" and use this for problem resolution as
your change is at least tracked "somewhere".

Naming conventions.
Update sets should have relevant naming conventions.
Suggested convention is:

 For immediate fixes, suggested naming is update set name + FIX

Alternative naming convention

 (no point putting in description in title as it would be too long)

 For immediate fixes, suggested naming is update set name + FIX
 For Emergency Change; update set name + EChg

Release dates
Schedule release dates accordingly. When you are in the project phase, or during implementation it's
difficult to wait for the next release date, but once you're past these phases, you should be able to start
doing monthly or bi-weekly updates. Allowing for of time to develop, test, document, and communicate
the updates to the end users through Release Notes.
Schedules to be based on priority and estimated development effort.

Sensitivity: Internal & Restricted

The life-cycle of an update set:

 Play, test, break, compare, prepare…do all this in Sandbox.

 Create update set in DEV
 Create / recreate your changes in DEV
 Capture Customizations
 Compare/Merge as needed
 Mark completed
 Test changes in DEV
 Retrieve update set in QA
 Preview
 Commit
 Test changes in QA
 Retrieve update set in PROD
 Preview
 Commit
 Communicate

Admin Duties

 Set release date and time, taking into consideration when the least impact to the business is.
 Prepare RFC for CAB
 Prepare Release Notes
 Prepare a list of update sets on the day to be updated.
 Communicate date of release to end users.
 Commit update sets to QA in correct order. ie order they were created and by application.
 Commit update sets to PROD in correct order. ie order they were committed in QA IF QA
testing is agreeable.
 Set date for next instance clone.

Best Practices.

 Don't keep update sets open which will span upgrades.

 No open update sets during cloning. All updates promoted to PROD before cloning.
 Ensure that all instances are on the same version
 All instances should be clones of Production
 Identify common path for update sets to move to/from
o good practice: dev > QA > prod
o bad practice: dev > < QA > prod
 Use meaningful names and descriptions in your update sets
 Be cognizant of what will and will not be captured in an update set
 MAKE SURE YOUR UPDATE SET IS ACTIVE!!!
 DO not delete any update sets. If you have merged update sets, and they have migrated
successfully, you can delete them to save confusion later.
 Do not touch 'Default' update set, its properties or values.

Sensitivity: Internal & Restricted

  Don't delete anything from 'Default' update set. It may save your bacon!
 Only 'complete' an update set when it's 100% complete
 Commit update sets to QA in correct order. ie order they were created and by application.
 Commit update sets to PROD in correct order. ie order they were committed in QA IF QA
testing is agreeable.

 Ensure that you have captured the most recent update in the update set
 Ensure that someone did not modify the configuration and moved to the target instance already before your mo
 If you have a large custom updates then try to break into different update sets and name them accordingly.

 If committed update set has problem, complete your fixes in another update set (in dev) and
promote fix with the correct naming convention ie meaningful.
 Promote fixes in the same way as normal changes. See "Life-cycle of an update set
 Know who is doing what
o To prevent 'stepping on another admin's toes,'
o Communicate between admins/developers
 Don't use other developer update sets, create your own
 Consider merging update sets prior to committing. According to ServiceNow, Last update wins!
 Allow for an emergency change process to quickly promote an emergency fix through
DEV>QA>PROD
 Merge completed update sets that you are going to promote together, and delete the original
sets that were merged. (If you plan to use merged update sets)
 Always run preview just prior to committing an update set.
 Create FIX update sets to promote any changes needed from QA testing
 Set completed local update sets in production to a state of "ignore" so they are not reapplied
after cloning production over DEV and TEST. I don't think you have to do this anymore, but I
haven't tested it yet!
 Use one update set for a workflow; do not use multiple update sets to transfer a workflow
change.
 Publish the workflow before you close the update set.
 Schedule updates after hours — time of least end user impact (example of when user was
updating an RFC)

Common mistakes.

 Update sets are committed to QA, but not to PROD. All instances should be the same.
 Update sets are created, and deleted before use. Can you confirm that none of these changes
impact changes in another update set?
 Users both working on the same application, especially workflows.
 Making "on the fly' changes in PROD. This 'breaks' future update sets.
 Leaving workflows checked out when you complete an update set.

Sensitivity: Internal & Restricted

  Cannot publish a workflow Set? I have found that if I am testing a workflow, a record may have
the new workflow open. Close those records!

Workflow issues

Overview.
Workflows are tracked in update sets differently from other records because the information is stored
across multiple tables. Changes made to a Workflow Version are not added to the update set until the
workflow is published, at which point the entire workflow is added into the update set.
Avoiding Duplicate Workflows
Duplicate workflow records may be created on the target instance if you use multiple update sets that
do not include all of the intermediate changes. Changes may be missed if an intermediate update set is
not applied to the target instance or if some changes were applied to the Default update set by mistake.
To avoid duplicate workflows, ensure that every change is moved to the target source. Use the
following practices for the best results:

 Use one update set for a workflow; do not use multiple update sets to transfer a workflow
change.
 Publish the workflow before you close the update set.

Trick if you see duplicate workflows — de-activate/activate the newer workflow and the older version
will disappear.

Example
For example, duplicate records can occur in the following scenario:

1. A workflow is created and published in update set 1, which is moved to the target instance and
applied.
2. The workflow is checked out, changed, and published in update set 2. This workflow is not
moved to the target instance.
3. The workflow is checked out again, changed, and published in update set 3, which is moved to
the target instance and applied.
4. This scenario results in duplicate published versions of the same workflow because the original
workflow was marked as unpublished as part of update set 2, which was not moved.

1. Before starting the deployment disable the LDAP server to prevent users from logging in
2. Kill all active user sessions (including the prod MID server?) … the "do the deployment" part …
3. Re-enable LDAP server.

Additional Notes - from worthy contributors:

When you run a clone from prod to dev/test, the clone uses the previous day's backup, not a real-time
snapshot of your prod environment. Therefore, if you complete and migrate your update sets to prod,
then do the clone back to dev/test on the same day, your dev/test instances will not have the latest
update sets in them and your instances will now be out of sync.

Sensitivity: Internal & Restricted

Sensitivity: Internal & Restricted