As a contract admin / developer, I have often had to troubleshoot Update Sets with new Admins, or at   least give them some help in understanding their use. Unfortunately, a lot is learned by making mistakes, mistakes such as having Workflows open when you close an update set, or having multiple browsers or sessions open (yes, we all do it when developing/testing ), so I came up with an article I was willing to share with new Admins of ServiceNow.

Please feel free to comment, suggest any improvements or updates, or send any unwanted chocolate Easter eggs as appreciation.

IT Service Management - Update Sets Best Practices.

In addition to this document, make sure to review Getting Started with Update Sets on the ServiceNow wiki

Update sets.

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.

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
  • good practice: dev > QA > prod
  • 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.
• Don't delete anything from 'Default' update set. It may save your bacon!
• Never modify the 'update set' field value in a customer update set. (i.e. do not manually move changes between update sets). Unless there is no alternative.
• 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.

• 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
  • To prevent 'stepping on another admin's toes,'
  • 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 any more, 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.
• Cannot publish an 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.