Week 24: Update Sets, Source Control & ServiceNow DevOps

1. Update Sets: Capture, Complete, Retrieve, Commit

An Update Set is a container that automatically records every configuration change made while it's active — a new field, a Business Rule edit, a widget change — as an individual Update Set Record. The standard lifecycle for moving customizations between instances (most relevant to global-scope customizations, since scoped apps increasingly favor source control instead, next section):

conceptual Update Set lifecycle

1. Create and activate a new Update Set on the source instance
2. Make your changes (every change auto-records into it)
3. Mark the Update Set "Complete"
4. Export to XML, or use Update Set retrieval if instances are connected
5. On the target instance: retrieve/import, then "Commit" to apply the changes

Scoped apps changed this picture significantly

Update Sets were originally the primary mechanism for everything, including scoped applications. Modern scoped-app development increasingly favors Git-based source control (next section) instead, since it handles versioning, branching and merge conflicts far better than XML Update Set files ever could — Update Sets remain essential for global-scope customization, though.

2. Git-Based Source Control for Scoped Apps

A scoped application (like your capstone, from Week 21) can be connected to a Git repository directly from Studio — every file the app is made of (tables, scripts, widgets) gets represented as an actual file in the repo, committable, diffable, and mergeable the same way any other codebase is. This is the same Git workflow you already know from any other project: branch, commit, push, open a pull request, merge.

3. ServiceNow DevOps

ServiceNow's DevOps capabilities connect this Git-based workflow to external CI/CD tooling (GitHub Actions, Jenkins, Azure DevOps, and similar), giving visibility into which code changes are tied to which Change Requests, and letting a pipeline gate a production deployment on things like ATF test results (Week 23) and change approval status (Week 16) — connecting the engineering workflow back to the ITSM processes the platform itself manages.

4. A Dev → Test → Prod Promotion Pipeline

Putting it together, a realistic (simplified) promotion flow for the capstone app, if you were shipping it for real:

conceptual promotion pipeline

dev instance:  build & commit to a feature branch  →  push
                     |
                     v
        CI pipeline runs ATF test suite (Week 23)
                     |
                     v (tests pass)
        merge to main branch  →  deploy to test instance
                     |
                     v
        manual/UAT verification on test instance
                     |
                     v (Change Request approved — Week 16)
        deploy to production instance

5. Hands-on Exercise

Hands-on

Practice the Update Set lifecycle

Requirements:

Create and activate a new Update Set named "Capstone Prep."
Make a small, low-risk change (add a new field to a table you own, or edit a widget's CSS) and confirm it appears automatically as a record inside the Update Set.
Mark the Update Set Complete, then export it to XML.
Write a short comparison (a few sentences): for your scoped capstone app specifically, would you use an Update Set or Git-based source control to move it toward production, and why?

6. Knowledge Check

Four quick questions. Expand each to check your answer.

What does an Update Set actually capture, and how?

It's a container that automatically records every configuration change made while it's active — new fields, script edits, widget changes — as individual Update Set Records, without the developer having to manually track or list what changed.

Why has Git-based source control become the preferred approach for scoped applications over Update Sets?

It handles versioning, branching and merge conflicts far better than XML Update Set files, and represents the app's tables, scripts and widgets as real files in a repository — enabling the same branch/commit/push/pull-request workflow used on any other codebase. Update Sets remain the primary mechanism for global-scope customizations, though.

What does ServiceNow's DevOps tooling connect that wouldn't otherwise be linked?

It connects the Git-based development workflow to external CI/CD tooling and ties code changes back to Change Requests, letting a pipeline gate production deployment on things like ATF test results and change approval status — linking the engineering workflow to the ITSM change process the platform itself manages.

In a dev → test → prod promotion pipeline, what typically has to happen before a change reaches production?

The ATF test suite needs to pass in an earlier stage, the change needs manual/UAT verification on a test instance, and (per Week 16's change management process) an associated Change Request needs to be approved — all before the change is deployed to the production instance.