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?

[Tom Sienkiewicz]

Hi, I just stumbled upon this discussion and thought I would drop my 2 cents based on my recent project.

We are moving really big numbers of update sets there, from tens to hundreds of update sets at a time.

I believe the key to successful moving of Update Sets between instances is not within the tool, it is the way of work you adopt and how organized you are. If you define a good process for moving Releases, Sprints, Bugfixes, Changes, whatever between instances and make sure EVERYONE sticks to it, choosing HOW to do it is really secondary.

That being said, we have opted for Batching as opposed e.g. to Merging due to the reasons mentioned above but also due to the fact that Merges were buggy as hell. We don't get those issues with Batches. The last couple "go lives" we have had on the project (thousands of updates, mind you) - we've had 0 (ZERO!!!) errors when moving update sets to PROD. As far as I remember the amount of Warnings was also 0 or close to 0.

One reason is the above mentioned process being followed, the second reason is we have a great architect who makes sure it works, and the third reason is that we keep the structure of our Batch linear and avoid creating trees. If you add update sets in the correct order, it minimizes conflicts. A -> B -> C -> D -> E etc. Where A is the batch base, B is parent of C etc. We also have very high granularity, meaning a lot of small update sets as opposed to huge update sets.

I am starting a project soon where I will be working on an app which will hopefully automate the entire process. 

Cheers & stay healthy,

Tom

[simmons_andre]

Good Advice. We are using batch update sets as well. One task I am looking into now is automating the migration of batch update sets from one instance (e.g. DEV) to another (e.g. TEST). If you have made any progress or have any insight it would be much appreciated.

[The SN Nerd]

I've not personally done this, but I know some have tried.

Go onto the sndevs slack and someone can probably share some insights.