Update Set Development Management

#Update Set , #Release , #Testing

Andrew Barnes

5 minute read

Development Management

I frequently get asked about managing development output when using Update Sets. Previous articles have covered individual aspects of update sets and batching before, but this entry will try to put the parts together. ServiceNow has update sets, application repository, plugins, store, share, and GitHub to hold and deploy application files. On top of development itself also contains best practices, code reviews, conflict management, manual testing, automated testing. I will use terminology that aligns with SN SDLC but don’t get caught up on story vs. enhancement vs. defect vs. epic.

If you are not using Update Sets this article is not targeting you.

Update Sets and Batching

Update Set batching is no longer new. If you are managing the order of update sets to be deployed or using the merge update set tool, follow along! Every development story a developer works on should have one update set at the onset. I personally link between the story (task) in production (could be any system) and the update set in development. For each update set created for the story after the first, the parent field on the update set is used to point to the first update set. Note: update sets in a batch don’t have to have the same scope.

This connection between story and update set allows for visibility and future automation. Each story is now a batch. The same strategy is applied to Epics and Releases. Every Epic & Release has an update set related to it. Each story in the epic has its first (batch) update set point to the Epic’s update set. Each Story or Epic without a parent set that is for a given Release has the parent field set to the Release update set.

Release / Epic / Story example

Task Example

Corresponding Update set for example

Update set Example

In the example above, Release 23 is the release to be built. It contains Epic 17 and Story 89. Epic 17 contains Stories 29&34. The hierarchy of the Release/Epic/Stories is identical to the update set hierarchy until we have more update sets for a task (Story 89) than we have task records. Story 89 ended up with three update sets and thus is a batch of its own. The alignment of the update sets and task records makes keeping track of update sets to tasks more comfortable and more transparent.

Moving between instances

Update set batches should be crafted at the earliest point possible. The location will depend on your local development process. The key is they should be done where the testing is performed. The reason for this decision is feedback from testing will drive if more work needs to be performed for the same development effort, thus creating more update sets. Care should be made not to update completed update sets, nor setting the parent field on an update set that has already been retrieved in the next level instance.

Example setup:

Dev -> Test -> QA -> Prod

Singular Dev instance - Testing performed in Test Update sets created in Dev. When groups of update sets have not been completed/retrieved, they can utilize the parent field. Batches for Release/Epic/Stories created in Test. When new update sets for an already retrieved story are added in Dev, they will be peer-reviewed and then moved to Test and have the parent field set to the Stories batch. When Release is marked complete - batch is closed and moved to QA, final testing applied, retrieved, and previewed in production to await release deployment window.

Dev->Prod

Singular Dev instance, testing performed in Dev. All update set creation is in Dev. Batches are created in Dev. If uncommitted update sets are retrieved into production before release is ready, they may need to be removed to ensure proper retrieval of the batch.

Dev -> Test/QA/Prod

Singular Dev instance - Testing performed in Test. Dev is the source for all Instances. Some development groups utilize this method. I don’t prefer it, as it leads to different processes between instances, including for completeness. All update set creation is in Dev. Batches are created in Dev. If uncommitted update sets are retrieved into any instance before release is ready, they may need to be removed to ensure proper retrieval of the batch. Update sets additions for stories already retrieved & committed in Test - must be retrieved singularly and then afterward have their parent field set in development.

Code review and testing

Any group with more than one developer should be utilizing peer/code review (CR). The CR process is well known in traditional development setups. You can read plenty of articles about the benefits over at Medium and other sites. In summary, the CR enables cross-training, mentoring, testing, different perspectives, and improves not just the code in question but the humans as well. For my setups, I build CR into the deployment process. Once a story is marked ready for peer review, another developer will review the update set(s) and ensure they align to the companies standards, contains what it should contain, and solves the story in question. If and once that is validated, they can then move the update set to the test instance, deploy it, and set the parent field as needed from the batching examples above.

Once the story has been reviewed, it can have automated and manual testing performed by the system (ATF), other automated systems, and manually by QA or the owning group. The review process, coupled with the deployment and batching, ensures separation of duties furthering the health and security of the system.

Conclusion

This article details processes you can implement when using Update Sets. Nearly all of the steps above can be automated once the process has been performed and tweaked to align with the development team utilizing it. Feel free to take the parts from here you find useful, and leave behind the rest! These practices are how I have run my development teams and shared them with our customers. It is not perfect, nor final. Leave me a comment if you have feedback.

Comments