We all have been working with Update Sets over the last years and we probably have the things we like or don't like about them. It is not a secret that ServiceNow has moved an and provides newer capabilities to deploy configurations and changes between instances. The proposed method involves ServiceNow's Application Repository.
Now working with the repository has quite some benefits and maybe some quirks forcing us to change the way we used to work. I want to start collecting some of the common questions around using the Application Repository (AppRepo).
In this blog I will be explaining how you can work with instance specific settings. There are always areas where you have to modify a setting and need to make sure the next deployment will not simply overwrite it. With Update Sets you could quite easily manage that by separating the content in different update sets and use some rigid review of these before moving them. AppRepo on the other side takes away this selective deployment approach. So how can we achieve it?
Let's use two examples on how to act in this situation:
1. System Properties
A common part in a scoped application are System Properties to store some defaults for your processes. While some might be critical for your application to be setup correctly, some might also serve as configurable choices for your users / customers.
Properties have a flag to define them as private which is defined as 'Set this property to true to exclude this property from being imported via update sets. Keeping system properties private prevents settings in one instance from overwriting values in another instance. For example, you may not want a system property in a development instance to use the same value as a production instance.'
While this is specifically mentioning update sets it actually also works for deployment via the Application Repository as well. Private properties will be packaged with the application but only brought to the target instance if it is not yet already on that instance. So this helps to get the properties created initially with a default value, but protects them from future deployments. The install process will raise a low priority 'Skip Record' in case the repository does have a different value bringing this to the attention of the deployment user.
If this property is not enabled (aka non-private or public property), then the installation process will check if the property has been changed locally. If not, it will simply be overwritten with the new deployment. If it has changed locally it will also create a skipped record with a different Disposition of 'Skipped':
So we can conclude, properties are well protected and the install process via Application Repository will take care on the instance specific changes in a similar way like Update Sets would have done in the past.
2. Integration settings
Another place where settings typically change are integrations. Well, with newer implementations you should have moved to Integration Hub and use Spokes. These come with their own version of so called Credentials and Aliases which are designed in a way to be fully supported in AppRepo deployments. This means a credential will never be deployed, only an alias is. Integrations simply point to aliases and depend on someone setting up the credential in the instance before the spoke can fully function.
But how if you use the classic way of integration with Outbound REST Message? These tend to collect all informations like URL endpoints, user credentials etc. in your update set and deploy them. With Update Sets you probably where used to either exclude them from the Update Set (storing them in bespoke update sets) or handle preview collisions before comitting your update set.
So with Application Repository deployments you cannot exclude them from being packages and deployed. However, the install/upgrade process on the target instance will run a similar check like with public properties. If the record has not been changed on the instance since the last install, the version from the repository will be deployed. If you happen to have a change, a skip record will be created for your deployment operator to be checked. Like with any platform patch or release upgrade:
So instead of seeing the conflicts on a preview you will need to work more with the Upgrade Log in your target instance and check there for potential problems - skipped records.
Summary (TL;DR)
We can conclude that the application repository is working quite well when it comes to protecting your instance specific settings. It does it in a similar way like a platform upgrade (patch or release) would do it. The only change for your teams will be to not expect a preview collision but skipped records post deployment.
Which other scenarios do you need when it comes to instance specific settings? Let me know if they are unclear and I will expand this blog to cover them.
2 Comments
