ServiceNow Update Set Batching - Best Practices & Lessons Learnt

[The SN Nerd]

Hi Community,

ServiceNow introduced Update set batching in Jakarta.

This is our experience so far:

Usage

At this stage, we have used it for Releases, where we create an empty Parent Update Set and relate Update Sets to be included in the release as children.

Pros

• Can remove individual items from the release at the last moment.
• Similar to merging, except you can essentially unmerge but unrelating a child at any time
• Easy to deploy, only need to commit Parent Update Set
• More Granular Update Sets makes it easier to tie changes to requirements and documentation

Cons

???

There isn't much information on it at the moment, especially around Best Practices, so I thought I would reach out and see what the Community Experience is so far.

Will you keep merging Update Sets, or will you start batching? Is this the way forward?

[The SN Nerd]

It would be interesting to see if there is a difference in how it is deployed.

I would never do that. though, as Update Set batching comes with the following advantages

• You can decouple or add additional Update Sets at any time
• You don't lose the original update set when deploying, so you can create granular update sets that link to requirements for a self-documenting system. 

[The SN Nerd]

As a side note, there is never a need to merge.

Batching follows a Hierarchy, so if you want to "merge" two batches, you can just create an empty Update Set & relate them both.

[charliesdev]

Would you take a look at my posted question from the other day?  You seem to have a good amount of experience with Update Set management.  Thanks Paul!  Marking a Batched Update Set 'Ignore'

[charliesdev]

1. Daniel Billing - I believe batching and merging serve the same purpose, why would you want to do both to a collection of Update Sets?

2. Paul Morris - what circumstances would you deploy Update Sets from a scoped application?  Our team is pushing for the opposite (only create Update Sets that are in the Global scope).  If a change needs to be deployed for a scoped application, we publish the app to our repository.  The only time we do create a scoped US is when development of a new feature for that app has started and a critical bugfix is needed for it.

[The SN Nerd]

We often need to move scoped updates too.

We create an empty master Update Set in global, and relate scoped sets as children, as well as other global sets. Haven't encountered any issues doing this.