Go to portal
Update Sets, Applications and two ways to promote or transfer Update Sets between instances
What are Update Sets?
System Update Sets are how ServiceNow allows its users to move updates from one instance to another. They group configuration changes and this is usually how customers deploy their changes from development up to production.
It is an XML file containing its own identifying information, the list of changes recorded in the source instance and data to determine whether the target instance can accept the changes or not.
Update Set vs Application
Similarly to Update Sets, Applications are groups of files used to deliver new features or functionality. Conceptually they are very different though. Applications group the entire concept of a new business process (HR for example, or Jira integration) and Update Sets… they just group configuration changes.
Applications have been shadowing Update Sets as the preferred method of promoting changes to other instances. ServiceNow has been empowering Applications for quite some time and they seem the way to go in the future. They add flexibility, power and additional features that Update Sets can simply not provide. But many ServiceNow users have Update Sets so rooted in their process that they cannot afford switching to Applications in a day.
But Update Sets also have a spot in the Application world. For each Application, you can have as many Update Sets as you need. The Default Update Set is created when an Application is started, but then for each developer working on it, an Update Set is created. So you can still benefit from the simplicity of Update Sets and you can work with Quality Clouds in order to check their quality.
How to transfer Update Sets?
There is more than one way to promote or transfer Update Sets between instances.
1. Old good retrieve method: Once an Update Set has been completed, it can be retrieved from a target instance. To allow this, the target instance needs to configure the source instance (the one containing the Update Set and the changes) as an Update Source. To do so the, URL, username and password need to be provided.
Once that is done, accessing the Remote Instance will allow you import all completed Update Sets, effectively marking them as Loaded. All update sets need to be previewed before being imported. This allows you to foresee any conflicts you may experience when committing the update set in the target instance. (See more in the next blog; Update Set Consolidation & Why it Can Get Confusing).
Once previewed, and only if there are no conflicts, the Update Set can be committed to effectively bring in all the promoted changes. (you can also get errors and clashes at this stage, even with a fully previewed Update Set).
2. Export and Import: Update Sets can be exported to an XML file through a Related Link under its form. After downloading it, you can access the Retrieved Update Sets module in your target instance and use the Import Update Set from XML option.
This is it for this first entry of the blog talking about Update Sets. Pretty basic stuff. If you want to dig deeper, check our next blog entry regarding Update Set troubles and how we can help, or why not book a demo?
