Question: Deploying hotfixes for custom scoped applications

[Quinten]

Hi everyone,

I have a specific question in regards to the best practice approach of deploying hotfixes for scoped applications. The use case is the following:

We have multiple custom applications being live in Production. All these applications have been promoted to
Production using Application repository. These applications are actively continuing development by a different
team supporting the application (Managed Services).

It does happen that issues (including major issues) are identified for the currently live application and thus requires urgent fixing. As per the statement of ServiceNow, we should not mix update sets with application repository, so the only way to push any hotfix to production would be to publish a new version of the application.
This however would also include any other changes being done as part of that application scope.
Now the question remains, what options do we have knowing that branches are not really working in ServiceNow?

Knowing the vision of ServiceNow and opting for going more and more towards Scoped application development, I'm really wondering if anyone has already raised a similar question to ServiceNow or is applying a specific practice to achieve it.

Some additional challenges:
- Even when using update sets, configuration in DEV will be miss-aligned with Production and the support team being unable to deploy fixes.

[Quinten · Accepted solution]

We have received confirmation from ServiceNow regarding the practice of mixing local Update Sets with deployments managed by the Application Repository (App Repo):

1. General Rule: It is confirmed that combining standard Update Set deployments with App Repo artifacts can lead to integration issues and is generally discouraged.
   
   
2. Emergency Exception (Hotfixes): In the event of an emergency hotfix, you can make and deploy immediate changes using a local Update Set.
   
   
3. Critical Mitigation Step: To prevent long-term divergence and ensure the application reverts to the official App Repo version, the hotfix changes must be flagged appropriately. You must set the "Replace on upgrade" flag on the related sys_update_xml record.
   
   
4. Outcome: The next time the artifact receives an update from the App Repo, the system will automatically overwrite the hotfix, reverting the component back to the managed application version.

This approach allows for quick emergency fixes while maintaining the integrity and compliance of the main application repository source.