Creating, Managing & Committing Update Sets

The last topic focused on the fundamentals of Update Sets. Moving forward, in this topic, we will understand the implementation and creation process of ServiceNow update sets. 

While creating update sets, remember that they are not forgotten once created, but are actively administered. Developers create new local update sets for every piece of work, track it, export it, and hand it over to another instance. 

This topic focuses on how to create local update sets, understand update set states, and what previewing and committing update sets in ServiceNow means. 

Update Sets Administration

Administering update sets means the day-to-day management of Update set records, like creating them, naming them, activating the right set, tracking them, and organizing them. Let us understand them in brief: 

1. Viewing existing Update Sets: They are found under Local update sets, which are owned and created by the current instance, and Retrieved update sets that are imported from another instance. 
2. Activating current Update Sets: At all times, one update set is always marked Current, where every configuration change gets saved. By changing the current update set state, you can control where the next changes will be applied. 
3. Naming Conventions: Using a consistent naming pattern in a project makes it easier to identify Update sets. 

Update Sets States

Update sets in Servcienow move through defined states that control what can and cannot be done at any given point. There are three major states in ServiceNow: 

Create New Local Update Sets

Local update sets in ServiceNow are the sets created in an instance, unlike retrieved update sets that are imported after being created elsewhere. Every scoped application has a default update set, which might not be the intended way to use local update sets. To create a new local update set, follow the given steps: 

1. Go to Local Update Sets → click New. 
2. Give it a proper name, like a story or task number, and a description. 
3. Save the record and mark it current. 

Once you mark the update set as current, any configuration changes are automatically added to it without needing a separate step for each change. 

Retrieved Update Sets ServiceNow

Unlike local update sets that are created in the instance, retrieved update sets originate from a different instance or source and are then imported into the current instance. These update sets are not active but sit in the staging state. To work with retrieved update sets, there are two ways you can import them: 

1. Manual Export/Import: Update sets are exported to XML files from the source instance and manually uploaded to the target instance. 

• Go to Retrieved update sets in the target instance. 
• Use the Import update sets from the XML related link. 
• Choose the XML file and upload it. 

2. Platform Native Retrieval: In connected/paired instances, update sets can be pulled directly rather than the manual file transfer.

Preview Update Sets

Previewing update sets in ServiceNow is an important process before committing the update set. Preview is like a dry run done to check missing dependencies, conflicts between new or old versions, and any structural issues. 

To handle preview results:

• If no errors occur, then the Update set is safe to commit. 
• If errors are found, each problem must be listed separately. Each flagged item/error must be resolved before you proceed. 

Previewing the Update Sets helps avoid chaos and broken deployments. If not previewed, some changes might not be effective, creating an inconsistent state of the target instance. 

Commit Update Sets

Committing update sets is the next step after previewing, where retrieved update set changes are applied in the target instance. The steps to do so are: 

1. Ensure that update sets are previewed and that there are no errors in the set. 
2. Click the commit update set option. 
3. ServiceNow will apply each change to the target instance. 
4. Finally, the target instance will show new changes, including tables, fields, and business rules. These are now ready to be used and presented. 

Back Out Changes from Target Instance

Even after a sprint of previews and committing to the update set, there is a chance that the deployment was wrong. It can be for different reasons, like a change in requirements, issues while testing, or a wrong update set might be committed. If any of these things happen, ServiceNow provides a backout option, but what does it actually do? 

The backout option for Update sets rollback the changes to the target instance and attempts to return the instance to the original state after the Update set was committed. 

The steps to back out changes from the target instance are: 

1. Select the committed update set on the target instance and select Backout. 
2. Confirm the action, and ServiceNow reverts the associated changes. 

What’s Next? 

Administering Update sets is an important process as it ensures that each update set is well named, clearly scoped, tracked, and focused. You can create local update sets in ServiceNow and also retrieve them from another instance. 

In the next topic, we will be focusing on the migration and merging of Update sets in ServiceNow.

Next Topic