Update Sets, we love them and hate them at the same time. As you maybe already heard, ServiceNow wants to slowly move away from Update Sets. They will of course always be there and have still a lot of value, but for releasing new versions of a customisation or a custom app, there are, in my humbled opinion, better ways! :)
In this post I want to describe how you can transition from using update sets or Git to deploy to production to using our Application Repository. Most of the time, we are not starting from scratch or greenfield and you may already started developing custom extension of the OOTB workflows or even custom applications. You even created your custom extensions or apps in scopes, great, this is good practice!
An architecture could look like this:
In this example here, I'm using two instances. The application was developed on my dev instance and then I used GitHub for the first deployment of the app to my Prod Instance. (I could have done the same thing with Update Sets.)
The app on PROD is now also stored in the "sys_app" table. As we now want to do new deployments via Application Repository, we need to convert our application. You can go to the sys_app table and click on the application you want to convert and in the related link list you will find the link "Convert to application Repository Mode"
THIS YOU ARE ONLY DOING ON YOUR PRODUCTION INSTANCE!! Very important!
What this is doing, is moving the application from the "sys_app" table to "sys_store_app" table. New upgrades will now only be pushed via the application repository.
Lets go back to our development instance and add something to our application. This can be done in Studio or App Engine Studio (AES), that does not matter. You will also see that the app on DEV is still in the "sys_app" table.
I added a new business rule in studio to my application:
I can now publish my change to the App Repo via Studio or if I want to use the pipeline functionality of App Engine (shown in the architecture picture above) I can go into AppEngine Studio and do a Submit there.
Publish in Studio:
Submit in App Engine Studio:
If you are using App Engine Studio, it will use the pipeline capability and will also show up as a deployment request in App Engine Management Center. If you are not using AES and only using Studio, it will directly deploy it to the App Repo.
On you production instance you can then install the update via the "My Company Applications":
If you are using AppEngine Studio and the App Engine Pipelines, it will do that automatically, as soon as you approved the deployment request (uses the CI/CD APIs).
Some important information about deleting, as this question comes up quite often. Until New York we did not ship delete operations, so you had to deactivate if you for example had a business rule that you were not using anymore. After New York we now use the author_elective_update folder to ship deletes. Some more information here:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0794114
In short, you have control over how the author_elective_update folder is handled. You can turn it off totally by setting com.glide.apps.include_my_deletes to false. You can set the specific level of records you want to apply (everything, everything except schema changes, or only Choice Sets) for your company instances only. You can also make sure that the apps you develop will ship Deletes in the author_elective_update folder, but you skip all incoming changes from any vendor app's author_elective_update folder by setting com.glide.apps.disable_elective_skip_history to true and also setting com.glide.apps.force_skips to true.
Top comments (0)