will github replace update sets?

treidfrb · ‎02-22-2022

I thought I had read on a recent Developer post "as we move away from update sets...", and of course now I cannot find it. Does that ring a bell with anybody? I am training in my developer instance to help guide my team as we prepare for San Diego. The question is generic, is this the strategy, to use Github exclusively to administer and deploy developer team work product to a large existing customer instance that has been using update sets for many years? Or will it remain a hybrid choice for developer teams?

Thanks for your thoughts

Tim

WORKFLOW-COWBOY · ‎02-24-2022

Finally! A question I can answer!

TL;DR -> Update Sets have a place, but there are other ways to deploy things...

There are three ways to promote things to Production:

Update Sets
Application Repository
Source Control

There are pros and cons for each depending on what environment you are in as well as whether you are updating something in Global or a scope as well as is this your app or a ServiceNow or Store app. (So many combinations!)

The opinions I offer here are my own based on my experience as a customer, partner, consultant, and employee of ServiceNow.

Update Sets

Update Sets have been around for a LONG time so the pros and cons are already documented everywhere. They are not going anywhere anytime soon and you can continue to use them to deploy code.

If you are still doing lots of work directly in the Global scope OR if you are making changes directly in a ServiceNow scope or Store scope, then you're going to be using Update Sets to promote your changes.

PRO TIP: Use Update Set batches, especially for Stories that span multiple App Scopes.

Source Control

Source Control was introduced many releases ago and has improved over the years. In Paris, a feature was added so that your app is not deleted before importing a new version from Source Control. This made it so that you could technically use Source Control as a deployment method to Prod if you wanted to.

While this might be possible, I would position it like this -> If you were writing traditional code (Ex. Java, C++), you would not deploy from Source Control directly to a Prod environment. You would package up your code into some kind of binary and declare a version to release. (Ex. v1, v2.2, etc.)

Having a packaged up binary version of your software makes testing and deployment easier.

If you want to "package" up a binary-like version of your app in ServiceNow you would publish your app in Studio to the...

Application Repository

App Repo is a gold-mine of a feature that has been around for years and is often underutilized or completely overlooked. It will NOT work in your PDI and will ONLY work in your company's instances so don't get frustrated when it is grayed out in your PDI.

I would refer to the diagram and Professional Developer Guide below to help demonstrate where you might use all three of these technologies when working on a scoped app or a Global application.

In the first box below "Dev 1 instance", you would either start a new app or import it from Source Control in the "App A Loaded" box.

During the "App A Teamwork" phase, an Update Set will automatically get created for each person working in that scope on that Dev instance. (See Application Collaboration and Delegated Development)

Once everyones Stories are completed for that Sprint (or halfway through), someone will commit that version back to a branch in Source Control. The branch will probably be named after the instance name. (Ex. "sn_instances/InstanceName")

Next, you would deploy this new version of the app (Ex. 1.1) to the App Repo using the "Publish" menu item in Studio.

Next, you would go to your QA environment and go to "My Company Applications" where you would install or upgrade the app to the latest version. Complete your ATF tests and then repeat the same steps in Prod if ready to deploy that version.

That's great stuff! It sure would be cool if some of this were automated!

This is where an App Engine subscription with App Engine Studio comes in. It utilizes everything I just said, but in an automated fashion. And instead of completing the Publish step manually, it is done automatically via a "Deployment Request". That way you can give people "App Engine User" access to build apps in SubProduction and they can request you to deploy the app to Test and Prod. Your approval of the request then triggers automated Flows to move the app around the environments and complete testing automatically for you.

I hope some of this helps answer your question.

Reference Links

Application Repository Documentation -> https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/app-...

Professional Developer Guide for the Now Platform - Deploy -> https://developer.servicenow.com/dev.do#!/guides/sandiego/now-platform/pro-dev-guide/pd-deploy

--------------------------------------------------
Workflow Cowboy
LinkedIn: https://www.linkedin.com/in/dalestubblefield/
YouTube: https://www.youtube.com/@starlordnow

View solution in original post

WORKFLOW-COWBOY · ‎03-21-2022

Can you provide further insight into use cases where update sets may be a preferred option of promoting code for scoped applications?

Sure thing. If you are making changes in a ServiceNow provided scope, Global, or an app from the Store, then continue using Update Sets to promote those modifications.

If you are in a Scope that your organization created, then my recommendation would be to use Source Control and App Repo to promote the changes. Bonus points if you have an App Engine subscription and can use App Engine Deployment Requests to promote the app versions.

Are there other use cases or potential benefits for using update sets instead of app repo to deploy/install/update scoped applications?

The main use case is the one stated above. If you are making changes in a ServiceNow provided scope, Global, or an app from the Store, then continue using Update Sets to promote those modifications.

IMPORTANT NOTE: Pick a deployment method for an app or scope and stick with it. Do not try to switch from App Repo back to Update Sets or vice versa. You may have unintended results and create a mess.

ONE MORE THING: This is my personal implementation preference so take it with a grain of salt -> If you are deploying a Global app for the first time (Ex. Incident Management), consider creating a new scope for all of your changes to the app instead of making all changes in the Global scope. Consider calling the new scope something like "My Company's Incident Management". This will allow you to utilize Source Control and App Repo right out of the gate and pretty much avoid the need to promote Update Sets all together.

This will also keep your Incident Management (or other) app basically untouched out of box. This makes your upgrades easier. You then have have an untouched app that you can use to extend for other departments all over again if needed. Or you can extend your new "My Company's Incident Management" app into new apps so they get your customizations. The sky is the limit!

But Dale, we already have thousands of changes in Global for that "app"?! In that case, you can create a "Global" app. This looks like a scoped app, but is technically still in the Global scope. Then, you move files from "Global" to "The new Global app". From there, you can start using Source Control and App Repo with "The new Global app". You won't be able to leverage Delegated Development since it's not a true scope, but it's a nice middle ground so you can use new tools with your old code.

Reference

Allow global application development in Guided Application Creator
https://docs.servicenow.com/bundle/sandiego-application-development/page/build/guided-app-creator/ta...

Global application file management
https://docs.servicenow.com/bundle/sandiego-application-development/page/build/applications/concept/...

--------------------------------------------------
Workflow Cowboy
LinkedIn: https://www.linkedin.com/in/dalestubblefield/
YouTube: https://www.youtube.com/@starlordnow

Daniel Draes · ‎06-13-2022

Just found this thread here... and great work on @Dale on collecting and summarizing.

I would a two litte bits... 😄

Working on applications delivered from baseline (i.e. Incident, Problem,...) in global scope:

I would still recommend to create a global application to capture your changes. Read careful, global application, not scoped! When you start to scope changes to a global app you get into the deep weeds of cross-scope privileges which can be daunting. Working in a global application though works just as good and gives you all the AppRepo & Source Control features.

Working on applications delivered from baseline (i.e. HR, CSM,...) in a scope:

My advise configuring these applications would be to stick with what that applications brings. Either work inside their scope (i.e. create an application extension) or use constructs like Case Types in CSM with their own scopes. Some applications have been designed to support extra scopes, some not. In all scenarios though there is no need to stay on update sets. Source Control and App Repo can still be used and provide the same benefits as for net new scoped applications.

SaschaWildgrube · ‎07-27-2023

IMHO update sets are dinosaurs - on a clear path to extinction.

How to build a robust development and deployment process based on source control?

Check this out:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf

JT8 · ‎07-08-2025

This is an awesome guide - thanks Sascha!

SaschaWildgrube · ‎07-09-2025

a pleasure! 😄