Should we set the completed update set on the production instance to Ignore before clone?

Suggy · ‎03-09-2022

We want to clone PROD over DEV instance.

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

Is it really required to do so? If I dont do that, what exactly will happen?

Gets reapplied means what?

Nia McCash · ‎03-09-2022

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.

View solution in original post

shloke04 · ‎03-09-2022

Hi @Suggy

My suggestion would be to follow this as it is a good practice as it will ensure that changes/Update set which you have already moved to production is not reapplied back to lower prod instance.

Even if you skip it it should not affect the cloning process for you.

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

Suggy · ‎03-09-2022

Hi @shloke04

What exactly is "reapplied"?

Today I am not setting to ignored and I dont see any duplicate update sets.

shloke04 · ‎03-09-2022

@suggy

This means that if update set is present in dev instance then the same update set from production will not be copied to your lower instance

You can ignore this setting as well and should not harm.

Hope this helps. please mark the answer as correct based on impact.

Regards,

Shloke

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

james_kail · ‎03-09-2022

I have just read that article, never heard this in the 9 years we have been working in ServiceNow. But then, our process has not had any issues in all that time. We had no reason to question how we were doing it. I guess we will need to do some more research as to why they (SN) say that.

Also, found it interesting that there was no reference to "Update set Batching" that we have been using.