Best practices for Update Sets

[Praveen90]

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

[sachin_namjoshi]

Below should give you answers to your questions

https://community.servicenow.com/community?id=community_question&sys_id=4889cf65db5cdbc01dcaf3231f96...

Regards,

Sachin

[Michael Jones -]

While update sets are the best method for moving changes between environments, they are certainly not without some limitations. You need to consider the differences between environments when planning a deployment such as what records are typically unique between instances (data) and how recently you may have cloned down from PROD, etc.

Generally speaking the best practices that I've learned are:

UAT should be as close to PROD as possible; a regular clone is the best approach. You would use your deployment to UAT to identify and resolve any issues you would encounter with the deployment to PROD, which is why UAT should remain as close to PROD as possible. You would strongly discourage any manual changes in UAT, except as documented manual deployment steps.  

Always deploy update sets from DEV to UAT and from UAT to PROD. Don't migrate updates backwards in the chain manually; use a clone!

I recommend adding an Order field to the update set form and using that as a means to document the deployment order for each update set; you'd be surprised how much grief this can save you. 

I would suggest only using a rollback in an extreme situation, such as a deployment to PROD that causes an outage or critical failure. Otherwise I'd suggest correcting the issue in in DEV and deploying an additional update set to correct any issues. 

Troubleshooting update sets really comes down to learning to read the XML updates. The process will usually give you a clue with a collision such as "Could not find a record in sys_user for column manager referenced in this update" so learning how to figure out what might be missing is key. 

It's also important to understand which records are unique between instances (such as users, groups, CI's, etc.) so that you can either plan to manually update those fields, or pull those records from PROD so that you can set references. 

As far as merging update sets, I strongly recommend using this approach especially if you have potentially touched common objects between update sets. When you merge only the latest updates are pushed to the merged set, which can reduce collisions across update sets. An example might be where you have a story to create a number of catalog items and over time (and UAT) you end up creating multiple update sets for each item with tweaks and changes. Rather than having to keep track of the deployment order, you would merge those update sets.

I've also seen situations where you might consider merging all update sets in a particular sprint release, again, to prevent multiple updates from colliding however, with proper planning and development assignment you should be able to manage this effectively. 

If this was helpful or correct, please be kind and click appropriately!

Michael Jones - Proud member of the CloudPires Team!

[Kunal Varkhede]

Hi,

In addition,

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.

Thanks,

Kunal

[Prasant Kumar 1 · Accepted solution]

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

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

Test instance

1. First, log in to the test instance and retrieve the update set from the development instance.
2. 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.
3. In case of any issues in the test instance, return to the development instance and create another update set.

Production instance

1. 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.
2. 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