Managing Update Sets

#Batching , #Release , #Update Sets

Andrew Barnes

4 minute read

Release Process

Properly managing your development work and how it is stored and released is often as important as the development work itself. None of us want to have the management of our update sets jeopardize successful releases. I will share some of the tips and methods for making the ServiceNow release process easier from my experience managing the release process at multiple companies.

Batching

With the Jakarta release, and improvement to update set management was introduced. The concept of batching updates sets via the parent field allows developers to group multiple update sets to be released all at once. This has replaced the merge update set methodology and improved upon it. When you batch update sets you are able to easily move and review them between instances. You are able to back out single update sets, or whole branches (sub-batches) instead of having to back out a whole release.

001-updateset.png

The most common scenario is: Developer gets a story to work. They then create an update set in their development environment Dev, marked STRY001 change color on Inc in graphic. Labeled 1, the update set STRY001 change color on Inc is completed in Dev. Labeled 2, the update set is moved and committed to the test instance Test where it is tested and validated.

001-updateset-fix1.png

When feedback causes the developer to make a new update set STRY001 change color on Inc Fix 1 in Dev, they can complete that update set, Labeled 3, and move it to the Test instance. Labeled 4, committing the 2nd update set for that feature to Test

001-updateset-parent.png

Labeled 5, Now the local update set STRY001 change color on Inc Fix 1 can have the parent field set to STRY001 change color on Inc. In this manner, we are able to ensure that the development work is captured and grouped together properly.

Release Batching

When the release is built, the release manager collects the stories and places them in that release. If you are using stories you can set the release field on the stories. At this point, we can create a release update set Release A in our Test instance and gather up all the batches for each of our stories and set their parent as the release update set Story A,B,C.

release.png

In our example picture, we can ‘How do we know which batches?’, you might inquire. That is where it is advantageous to have a link from the story and the top level update set. This can be done in several ways, but a simple URL type field can handle this to start. We now have in our Test a single batch that contains all the update sets for the release we are building and can preview/commit that in our QA instance if you have one available or just prepare it for the Prod release date.

Our release can now take advantage of the data available to it. You can build release notes from the short descriptions of each of the stories in that release. Then you can use that release record to display to your stakeholders what is in a given release in your service portal.

Improvements

This is a good foundation to work from. Once you have performed these actions 3 times consistently you can start to think about automating some of the parts of this process. I have previously covered building an update set tracker in In prior Live Coding Happy Hour. This is but one way to start automating your way towards easier update set management. I will continue to build on this update set tracker and release it to the Share which is a great place to get handy utilities and to help others in the community.

Managing releases is much easier with application versioning and updating but we are not able to use that method for many updates currently.

Comments