Scoped Application Release Process

Hardik Benani · ‎01-14-2021

I have come across this scenario with many customers where they want to develop code as custom applications but don't have a clear process or required toolset. e.g. Some customers have restrictions to git.

Below is the scoped application release process that has certainly worked for many customers and MSPs.

Scoped Application Release Process

Each release development should be done on single company DEV instance – i.e. baesdev.
Once development is complete publish an application to application repository.
You can set major / minor version of an app depending on type of release.
- Major Version -> 2.0.1 - First digit in number for added functionalities.
- Minor Version -> 2.0.3 – Last digit in number for defect fixes etc.
Ensure you add Dev Notes which explain what is new and changed in the version.
Before starting the development on new version of your application, ensure you update the version number on DEV Instance.
Once all your changes are done, click on “Publish to My Application Repository” related link.
Once a new version of application is available – go to target instance “My Company Applications” menu, this should now show a flag on the installed application to update the version.
You can review the application upgrade logs at the same place as system upgrade logs i.e. System Diagnostic -> Upgrade History
This will show you the files that were changed, skipped etc. and take necessary actions.

Publish an application to the application repository:

Navigate to System Applications > My Company Applications.
Open the In Development tab.
Open the application record that you want to publish to the application repository.
Click the Publish to My Application Repository related link.
Click Submit.

By default, after you publish an application to the application repository, all your company instances are entitled to the application automatically. Manage this using https://apprepo.service-now.com (Use your HI Credentials).

Preserving an Application Mid Development:

Publishing an application means that although the target instance will have access to all its features, continuing to edit the application from studio in that instance will not be possible as the version available will be the “published” version.

Normally, this works fine as the application should only be edited on the development instance, however in cases where the development instance is being cloned over, if the source instance of the clone already has the application, the clone will copy the application version from the source instance over the application version that exists on the target (developer) instance.

This means that the application will still be editable in studio on the target clone (dev) instance, but for example, if you have version 1.0.2 in Dev and version 1.0.1 in Production, the version in Dev after the clone from Prod will be version 1.0.1.

If the source instance does not have the application installed, it will wipe out the application from the target clone (dev) instance.

REF: https://docs.servicenow.com/bundle/orlando-application-development/page/build/applications/task/pres...

To preserve the application when cloning is taking place, the following two options are available:

(Recommended by ServiceNow) Link the application to a source control repository.Note: If the application is already linked to a source control repository, commit the latest version to it.
Publish the application to an update set.

NOTE: although ServiceNow recommends linking the application to the source control repository / Git Hub, BAE systems does not currently have one, so the workaround would be exporting the application to a update set before a clone and re-installing it.

KB0766009 - Preserve unpublished applications during a system clone

Linking an application to Source Control:

Open the application you want to link to source control in Studio.
Navigate to Source Control > Link to Source Control.
Studio displays the Link to Source Control dialog box.
Enter the connection details for the GIT repository.
Click Submit.

Additional consideration and limitations:

You cannot install an application from git on your production instance.
Installing an application from git using below methods will delete and re-create all tables and source code. This will mean any data on the tables will be wiped off unless they are added as a part of application via application files.
1. Switching a branch
2. Applying remote update
Deletions are not captured when you publish the application to application repository. If your newer version of application includes deletion of any source file, these needs to be captured as a separate update set in the application scope and moved through instance after new version of deployed.
Capture all configuration data for the application scope by navigating to the list layout and click on “Create Application File”.

IMPORTANT NOTES:

Use of Update Sets:

It is recommended to avoid using multiple methods of deployment on scoped apps.

When building a scoped application, if changes are made and moved into the target instance using update sets, on the next application install from the app repo, just like with instance upgrades, artefacts which have a version history or records on the sys_update_xml table are classed as customisations and are skipped. This causes issues as new changes will not be applied to the target instance.

Is it recommended to stick to one method of deployment: https://hi.service-now.com/hisp?id=hisp_ticket&table=sn_customerservice_case&sys_id=1af9ad111b965890...

Fix Scripts:

Whilst fix scripts are very useful, they are mainly built to run after an application is installed or upgraded. Fix scripts have a property called “Run once” which by default is ticked.

If / when this property is unticked, the fix script will run every time the application is installed or upgraded.

It is IMPORTANT to review and deactivate fix scripts that are not needed before deployments as there is a risk of them running on installation / upgrade and making changes to the application.

Useful tables for reviewing upgrades:

sys_upgrade_history: This allows developers to track upgrade history and view what changes have been applied or skipped when a new version of an application is installed
sys_execution_tracker: This table shows scripts which have run as part of installation processes. This will include the application install and any fix scripts.

Ramya30 · ‎11-14-2022

Hi Hardik,

Thanks for posting this information. It is quite similar to what we do in our organization, except that we don't publish from DEV instance. Publish action bundles everything, including half done stories, long term stories, etc. I'm quite curious to know how you handle such cases in the release model you explained. We use Source Control to move code between DEV and TEST, so we have an option to choose what we commit into GitHub - only completed stories. We apply remote changes in TEST and then publish from TEST to app repo.

Thanks

Ramya Ramadasan