Why you should set your completed update sets to 'Ignore' on production

[Nia McCash]

In their official docs, ServiceNow recommends the following practice:

Set completed update set on the production instance to Ignore. This state ensures the update set is not reapplied when cloning the instance.

Why would you want to do this?

To prevent the Update Sets from being pulled to Production again when you clone over your Dev instance (assuming you are pulling update sets from your Dev instance to Production).

To explain why this happens, here's what happens when you work with update sets and clone...

On your Dev instance, Update Sets that you create and complete are stored in the sys_update_set table.

Let's just say you're working with update set name 'My first update set' with a sys_id of 6a31d3973b331300bcc36da0a3efc4f5.

When you pull from your Dev instance to your Production instance, the update sets are staged in the sys_remote_update_set table.

The sys_remote_update_set record will have a reference to the 6a31d3973b331300bcc36da0a3efc4f5 sys_id in your dev instance so it doesn't pull the same update set again if it's already there.

When you commit that update set, the platform creates a sys_update_set record in production BUT with a different, new sys_id on production.

So now you have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

When you clone over your Dev instance, your Dev instance will then have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

The one with sys_id of 6a31d3973b331300bcc36da0a3efc4f5 is now gone because you cloned over it.

If you hadn't set this update set to Ignore, then when you pull for update sets from your Dev instance from production, you will pull this update set back to production as one to be committed.

It doesn't matter that there's already an update set in the Retrieved Update Set [sys_remote_update_set] list that is called 'My first update set' because there is another one with a new sys_id.

You wouldn't commit the duplicate so it's probably harmless but it makes your system messy and more prone to errors if the Update Set is there and can be accidentally committed.

[Bill Ye Zhang]

@Nia McCash Hi Nia, thank you so much for the detailed explanation and the diagrams! 

Can you please clarify, in the diagram for the scenario if the update set had not been set to 'Ignore', should the box with the update set sys_id 0bb291601bc28910277b33f3cc4bcb3a be on the Development side? 

My understanding from reading your explanations is that a 'Complete' update set will be cloned down onto two tables in the target instance - 1. sys_update_set as 'Complete'  and 2. sys_remote_update_set as 'Previewed'.

[Nia McCash]

Hi @Bill 

The update set with sys_id 0bb291601bc28910277b33f3cc4bcb3a is on production and will be copied to development (regardless of the state) if you clone. By default, a clone would copy every update set in the sys_update_set table on Production to Development no matter the state.

A completed update set in the sys_update_set table on production would NOT clone down to create a sys_remote_update_set record.

[Bill Ye Zhang]

Thanks Nia. I'm still trying to understand, if an update set is not set to 'Ignore", how can it be created on the  sys_remote_update_set table in Production as 'Previewed'?  I'd think it'd make more sense to be created in the target instance. 

This Community article says the update set will appear on the Retrieved update set table in the target instance.

[Nia McCash]

Hi Bill,

You are correct in that an update set on Development set to 'Ignore' will not be created (pulled) into the sys_remote_update_set table on Production as 'Previewed'. This is typically why you want to set committed update sets to "ignore' on Production so that when you clone down to Development, they are already set to 'Ignore' and will not be pulled again to Production again, a second time.

[Chinmay Batra1]

One more aspect of state of the update set @ state="IGNORE" .
1- After the merger of two or more update set the state of that pervious two or more update set automatically changed to "ignore".
Ex: If, I can take "A" and "B" update sets then I want to merge these two update sets.
After the merger of these two update set ("A" & "B") the new update set is ("C") after merger.
and the states of ("A" & "B") update set is automatically changed to "IGNORE".

I am attaching screenshots of it for your reference.

[kevclark]

Shamelessly posting a script that @Kieran Anson posted to another shadowy part of the internet related to this topic so that I can find it again in future 🙂 

This script will go through all your retrieved update sets one by one and set them to "ignore".  If you're in a different scope, it will switch your scope before setting the state to ignore.

Thanks Kieran!!

var localSetGR = new GlideRecord('sys_update_set');
localSetGR.addQuery('state' , '!=' , 'ignore');
localSetGR.addNotNullQuery('remote_sys_id');
localSetGR.orderBy('application');
localSetGR.query();
while(localSetGR.next()){
    var currentScope = gs.getCurrentApplicationId();
    var updateSetScope = localSetGR.getValue('application');
    if(currentScope != updateSetScope){
        gs.setCurrentApplicationId(updateSetScope);
    }

    localSetGR.setValue('state', 'ignore');
    localSetGR.update();
}

[Matt Heger]

Hi guys, 
i am try to understand this and follow it. The graph is nice and all but we have never done this and our now in our third clone back and push to dev cycle. So as we have never done this I would have expected our first updates set (by name) now exists two or three times in the remote update set table. I just checked and this is NOT the case. So not sure if ServiceNow did something in the clone process to change it but I couldn't reproduce the problem. If anyone else also "doesn't have it" or has some more detail on the issue I would greatly appreciate a comment. 

cheers,

matt

[Josh Pirozzi]

Hey @Matt Heger ,

We're in the same boat as you. Pre-clone, we usually set any In Progress Update Sets to Complete and then migrate them into our Prod Instance so we don't inadvertently lose work started, but have never had to go through the process of setting anything to Ignore unless it was no longer needed.