Best practices for Update Sets

Praveen90 · ‎07-12-2020

Hi Fellow Experts

I’ve recently got ADMIN access to DEV / UAT / PROD instance of ServiceNow (NewYork) – I’ve started to do a lot of Update Set configurations from DEV through to PROD instance and I’ve come to understand that Committing an US doesn’t necessarily mean that the customization has worked from DEV to PROD SN environments.

There’re instances where it(customizations) goes through (export/import to xml) without any errors; however, the end result is not an exact replica/clone of DEV SN env to PROD SN env … i.e. hasn’t validated 'like for like' between the SN instance states … how does one troubleshoot those issues effectively?

For e.g. May not reflect the field or 2 OR may not replicate the Variable sets properly from DEV to PROD for instance…

So, some questions –

1 > What’s the best way to Back out Update Sets, if things go south or when the replications haven’t happened either from DEV->UAT->PROD OR DEV->PROD?

For a customization issue on DEV->UAT->PROD SN US

In UAT, Do I back out a ‘Committed’ US from ‘Local Update Set’ & then delete the ‘Backed out’ US from ‘Retrieved Update Set’
Then from DEV – Back out ‘Committed Set’ from ‘Local Update Set’ – Once completed the back out sequence, proceed to do the US from scratch – Is that a good approach?

Repeat the same steps on PROD, for a customization issue on DEV->PROD US

2 > When do we ideally merge an US? Different Scenarios to merge US?

3 > Is there a set sequence to be followed on performing an US from DEV->UAT->PROD?

4 > Easiest way and right way to troubleshoot US?

5> Say, in DEV; you created an US first,

then accidently deleted some Variable Sets for a particular Catalog item in DEV; Saved the changes

added that saved Catalog item to the US (Changed the State from ‘In Progress’ to ‘Completed’ for that US);

then imported the Completed US to XML; & did a retrieve US in UAT via import XML; find out that the deleted VS hasn’t propagated to UAT env, although the preview & commit of the US went through without errors in UAT …

but validation is still missing the VS in UAT … what’s the steps to troubleshoot the deleted VS in DEV and fix the VS UAT validation… if that makes sense?

Overall, I’m looking for advice on the best practices for US customization and configurations.

Cheers

PV

Prasant Kumar 1 · ‎07-12-2020

Hi,

Please follow below document:-

In the ServiceNow environment, an update set is defined as a group of customizations that users can move from one instance to another. Thanks to update sets, users can develop customizations in a development instance, move them to a test instance, and apply them to a production instance.

Update Sets are among the most important development tools ever released by ServiceNow because they record all your development efforts, so you can move them from development to production.

Customizations include Tables, Fields, Forms, Views, Client Scripts, etc. Users can use update sets to make changes they intend to apply to other instances and to make sure that instances are in sync.

Breakdown of Basic Process

The basic process for getting an update set from the stage of development to production is the following:

Development instance

Proceed to create an update set on the development instance
Make changes and customizations. Use meaningful names and descriptions in your update sets.
Mark it as Complete.

Test instance

First, log in to the test instance and retrieve the update set from the development instance.
Next, commit to retrieved update set on the test instance and proceed to test the customizations. Always run a preview just prior to committing an update set.
In case of any issues in the test instance, return to the development instance and create another update set.

Production instance

Locate the production instance, log in, and retrieve the update set from the development instance. In case the update set needs to be fixed, be sure to complete the fixes in another update set, and retrieve both update sets.
Next, commit the update set on production, or if it requires a fix, commit both in the order they were made.

Don’t delete any update sets, unless you have merged update sets. Prior to committing, consider merging update sets that you’re going to promote together. Once they are merged, delete the original sets to avoid later confusion.

Always use one update per workflow. Never use multiple update sets to transfer a workflow change. Before you close an update set, always publish the workflow.

When You Don’t Need to Use an Update Set

There are situations in which there is no need for you to use an update set. For example, you don’t need to use it when you’re using data export/import sets to move data from one source to another. When not within a custom update set, all changes will be tracked in the Default update set. That allows you to see what you’ve changed and used the information for resolving any problems. Be sure not to touch the ‘Default’ update set or its properties or values, and don’t delete anything from it.

When to Backup Update Sets

Be sure to backup update sets when:

Cloning over development
Working in customer instances as a consultant
Working with several other developers
You don’t trust yourself completely

If i was able to solve your query, please mark my answer correct and helpful.

Thanks & Regards

Prasant kumar sahu

View solution in original post

Priya Shid1 · ‎07-12-2020

Hi ,

Please find below that will definitely help you,

https://medium.com/@servicenowscholar/update-set-best-practices-e9b88f2b92f1

Please mark if that helps you!!