Is it just me, or are Update Sets kind of a pain in the posterior? Sure, at first they seem convenient in the way they magically record what you change so you can apply them to your other instances. But the more I use them, and the bigger my team gets, the longer my list of grievances against them grows. This post is about just one of my gripes. But lest you think I'm here just to complain, know that I offer a (partial) solution as well.

Traditional code source control typically offers the ability to lock code and other virtual objects in a way that encourages no more than one developer to work on them at a time. That way, if Jack is working on a form layout and Jill attempts to change the same view, Jill will have to wait until Jack is done. Nobody tumbles down, and everyone's crown remains intact.

Some source control systems also allow branching of code, which is an explicit exercise in allowing multiple versions. Once a branch is formed, there are only 3 possible outcomes: 1. it is eventually carefully merged back into the main line of code, 2. it becomes a permanent alternate version, or 3. it is abandoned.

Update Sets, in contrast, allow multiple people to work on the same objects with no requirement nor even warning that someone else may have pending changes. Further, and scarier, update sets store a version of the objects that have changed, essentially automatically and transparently creating branches.

Egad.

ServiceNow is, to their credit, slowly embracing source control. But to date, it can only be used from Studio, which can only be used for scoped (not global) applications. In addition, I don't believe there is any way currently nor in their safe harbor statements to truly lock objects from being modified outside the scope of the studio/Git integration. So, until they offer a better solution, here is something I've put together to help my team, and I hope you will find it useful as well.

This does not stop someone from creating branched versions of code, but it at least helps developers and release managers clearly see when it's happening.

Side note: my first attempt at this was to put an insert business rule directly on sys_update_xml to print a addInfoMessage immediately when an object already is in an "open" update set. It seems that business rules are not run by the subsystem that records changes to update sets, so that did not work out. Until someone smarter unlocks that option, this is my workaround.

The messages in these screenshots come from the attached code and are based on comparing the current update set to all other update sets that are not in an Ignore state, and have no Release Date. This is my team's definition of "open" (as in not yet released). Yours may differ and you can change the code accordingly.

The update sets are named to indicate which was created first, and, in theory, which should be released first. Note that the error message indicates an issue with this sequence. The object in both update sets is a business rule called "Clear On Hold Reason."

As you can see, the first update set indicates that the second contains a version of the object. However, since it's last update date is earlier than the one in FirstOne, the message is purely informational. The message in SecondOne is more dire. It indicates that FirstOne contains an update to the object that is more recent than the one it contains. This means that if we were to release these in a sequence of FirstOne and then SecondOne, the change in FirstOne would be reverted to whatever is in SecondOne.

Before you point out that we get similar messages when committing update sets, note that this message comes early enough to intervene. In this example, I would be inclined to force the current version of the object into SecondOne to make sure that the last update set deployed contains all the changes from both update sets. It's not nearly a perfect solution, but when life gives you lemons, put on a lemon smile!

Update set attached. To load, navigate to System Update Sets > Update Sets to Commit. Then click Import Update Set from XML. Open the imported update set, preview (please do review the code) and then commit. If you're in a domain separated instance, make sure you're in the global domain.