Set completed update sets on the production instance to Ignore?

[shank1]

as per this LINK - https://docs.servicenow.com/bundle/paris-application-development/page/build/system-update-sets/task/create-select-update-set.html

below is what it says

"You should always set Completed update sets on the production instance to Ignore. This state ensures the update set is not committed again when cloning the instance."

Are people following this?

What happens when I dont follow this?

[Allen Andreas]

Hello,

The point of that is so when you clone Production down to these other instances the update sets don't try to apply itself again as is standard behavior after a clone. Default is never marked as complete and remains in progress, else the others, on Prod, should be marked as ignored after they're "complete" from committal.

Yes, this should be standard behavior to set those to completed sets on prod to ignore.

If not, it could cause issues on the target instance as the completed sets are again committed amongst the very same environment, which is now a cloned copy of Prod and those updates are now already there and were previously committed.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[shank1]

Hi @Allen A 

Say I have an update set "TEST A" in DEV, moved to UAT, then moved to PROD where its committed in PROD.

Now if I clone from PROD over DEV, the same update set "TEST A" will appear in the Retrieved Update sets is it?

and to avoid this, we need to set the state of update set to IGNORE in PROD?

[Allen Andreas · Accepted solution]

Hi,

Yes, basically.

If you have an update set that has moved up through ALL the environments and is now on Prod and committed, but left as Complete. If/when Prod is ever cloned somewhere else, that update set will show in the retrieved update set list and appear as if it has not been committed, when it really had. It can cause confusion and people to recommit sets, when they aren't needed. And if recommitted, cause issues within the instance.

Having them set as ignored, prevents them from loading back in to the retrieval process.

Repeated explanation here though just in case you want to see it from others, like SN staff: https://community.servicenow.com/community?id=community_question&sys_id=852c4365db9cdbc01dcaf3231f96...

Please mark reply as Helpful/Correct, if applicable. Thanks!

[shank1]

Thank you @Allen A  🙂