Update Set best practices

[ServiceNow SA]

Hi Team,

I would like to know the best practice regarding update sets and cloning.

I understand that "The best practice of handling "update sets" is by exporting these to xmls and then importing them after the clone."

What should we do regarding in progress update sets after cloning? 

a) Should we re-open those after importing XML so that we can continue working on those.

b) Should a new version be created and we should work on the new version?

[p_espinar]

But the very best option is to upgrade to Orlando, so you will be able OOTB to clone preserving in progress update sets!!

Un saludo,
Pablo Espinar
Consultant at Econocom Spain

Please mark this response correct if I've answered your question. Thanks!

[Mark Roethof]

Just to add, here's an article which might be interesting for you which I wrote a while ago:
System Clone Preserve Update Sets [Orlando]

Pre-Orlando

Pre-Orlando backing up Update Sets would mean for example:
1) Changing the state of the Update Sets to Complete;
2) Exporting the Update Sets to XML;
3) Importing the Update Sets after the System Clone has been executed;
4) Review and commit the imported Update Sets;
5) A best practice is not to reopen the Update Sets, so new follow-up Update Sets with a suffix "(2)", "(b)", etcetera would occur.

Another way could be:
1) Changing the state of the Update Sets to Complete;
2) Retrieving the Completed Update Sets on your production instance (uncommitted);
3) After the System Clone has been executed, review and commit the Update Sets on your development instance;
4) A best practice is not to reopen the Update Sets, so new follow-up Update Sets with a suffix "(2)", "(b)", etcetera would occur.

Orlando

When scheduling a System Clone (System Clone > Request Clone), on the System Clone record under the "Options" section there's a new field visible called "Preserve in Progress Update Sets". Options being "None" and "Last 90 days". This option basically "Preserves update sets during the clone process which eliminates the need to export in-progress, global update sets before you initiate a clone. The default is none. You can select the latest 90 days to preserve the in-progress update sets during this time."

Read more about this on the ServiceNow Product Documentation page:
Request a clone

If my answer helped you in any way, please then mark it as helpful.

Kind regards,
Mark
2020 ServiceNow Community MVP
2020 ServiceNow Developer MVP

---

LinkedIn
Community article list

[ServiceNow SA]

Thanks for the suggestions.

I am facing one issue while committing the update sets- It kept on committing from past 1 hour so i cancelled that and the status shows "Partially committed".

However now, i am not able to commit any other update sets as getting this error:

In the progress worker it is showing in running state:

Can we cancel from here? is it recommended?

[BryanS413339635]

Can you back it out and then retry? Also to add since nobody mentioned it yet....Batching is your friend, use it often and whenever multiple update sets are being moved. I would never try to move more than 3 update sets in order manually or merge update sets; batching all the way. Here's a great article that sums it all up perfectly: https://developer.servicenow.com/blog.do?p=/post/update_set_management/

If my reply has helped in any way, kindly mark it correct/helpful. Thanks!

[Prasant Kumar 1]

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