ServiceNow Update Set Leading Practices Part 2

[dipak_thakor]

As part of Technical governance, surrounding your ServiceNow instance, we need to understand, how we work with update sets to avoid errors and performance issues. 

What is an update set System Update sets

An update set refers to a collection of configuration modifications that can be transferred from one instance to another. This functionality enables administrators to consolidate a series of changes into a designated set, which can then be moved as a single unit to other ServiceNow instances for the purposes of testing or deployment. It is important to note that when an update set is reverted, there exists an out-of-the-box business rule that will remove the sys_upgrade_state record upon the deletion of a customer update, which is considered standard behavior.

An update set is represented as an XML file that includes:

- A collection of record details that distinctly identify the update set.
- A compilation of configuration changes.
- A status that indicates whether another instance is permitted to retrieve and implement the configuration changes.

Update sets monitor modifications to applications and platform features, thereby allowing developers to create new functionalities in a non-production environment and subsequently promote those changes to another instance.

Working with update sets leading practices

• Don’t delete update sets. If an update set is deleted, any updated records may be overwritten in the next update.
• Don’t include the system_id field from the ldap_server_config record in an update set. An update set from a working configuration points to the wrong system_id node for the target instance and doesn’t work.
• Don’t back out the Default update set. This action damages the system.
• Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:
  1. Switch to the desired update set.
  2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
  3. Save the record.
  4. Back out the change just performed, and then save the record again.

     This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set.

• Don’t mark an update set as Complete until it’s ready to migrate. After an update set is complete, don’t change it back to In progress. Instead, create another update set for the rest of the changes, and make sure to commit them together in the order that they were created. Naming conventions may help in this case (for example, Performance Enhancements and Performance Enhancements 2).
• Don’t manually merge updates into an update set. Use the Merge Update Sets module. This tool compares duplicate files between update sets and selects the newest version.
• If a committed update set has a problem in the test instance, build the fix in another update set in the development instance. Commit this set to the test instance, and then make sure both sets are migrated to the production instance and committed in the order they were made.
• Always preview an update set before committing it.
• Set completed update set on the production instance to Ignore. This state ensures the update set isn’t reapplied when cloning the instance.
• Keep a to-do list of manual changes and data loads that must be completed after an update set is applied.