The Now Platform® Washington DC release is live. Watch now!
Are you using Jakarta or a later version of ServiceNow?
Do you wish there was an easier way to keep your environments up to date?
Are you finding it time-consuming and difficult to backup and restore your development work when cloning during release cycles?
If you answered yes to any of the above, read on!
Version / Requirement |
| Preserve all In Progress Update Sets (Last 90 Days) |
Paris | Update Set Batching & Export Batch | Clone Preserve Update Sets |
Orlando | Update Set Batching & Export Batch | Clone Preserve Update Sets |
New York | Update Set Batching & Export Batch | Update Set Batching & Export Batch |
You would wait until your environments are so out of sync, usually triggered by the Change gone wrong, causing Incidents, days of fire fighting, and late nights, before thinking about Cloning all your environments from Production.
You have more "In Progress" Update Sets than you can poke a stick at - from Development Spikes to Enhancements put on hold indefinitely while the customer makes up their mind on the color of a button.
You filter your Update Sets by "In Progress" and painstakingly cycle each one as "Complete" and then Export them to XML. The default file name is something awful, like 1c223270dbed1fc07b337a9e0f961974.xml. You will need to remember the order in which these were created, as not to ruin some dependencies that may exist.
You might not even do any of the above and wait until there is absolutely no work in the pipeline, or have a mandatory Upgrade.
Regardless of your approach (or lack thereof), the whole process takes way too much time anyway and you wish there was an easier way.
Now there is! And it only takes 4 easy steps 🙂
In case you missed the news, ServiceNow introduced a new feature called Update Set Batching in Jakarta.
Update Set Batching allows Developers to relate Update Sets in Parent/Child relationships.
This essentially eliminates the need to Merge Update Sets.
When a package of work is ready for deployment to the next Upstream environment, simply close the 'Update Set Parent', which in turn closes all Child Update Sets.
When retrieving Update Sets from the Upstream Environment, you only need to deploy one Update Set - the 'Update Set Parent'.
Depending on the size of your environment and rate of change, it is not uncommon to have 5-20 Update Sets "In Progress" at a time.
You would ideally like to be Cloning over DEV after every release - but this is really difficult and risky when you have a number of In Progress items, generally reflected by the number of "In Progress" Update Sets that are open.
In your Development environment, prior to a clone:
In 4 steps, you now have a single XML file containing
After you have cloned over your Development environment, restoring your In Progress Update Sets is even easier.
You will probably run into some Preview Problems when restoring, which may seem like a painful process.
This may seem annoying now, but it is better to have these come up now, rather than when you are deploying these Changes into Production!
It is always better to highlight these issues in Development before going into Production. You'll thank your future self 🙂
Use the Clone Preserve Update Sets feature - available as of Orlando
Backing up your Development "In Progress" before a clone is only one of many uses of the new feature:
You could even write a UI Action and a Script to do the whole Backup process for you!
Please comment below on your experience with Update Set Batches and/or any cool uses/discoveries you have made.
Does the Merge function still have a purpose? Tell me what you think.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.