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
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
