Rollback changes through Application repository

[Viswanatha Red3]

Hi All,

I liked the concepts of Source control and Application repository which were brought in Service-now, to help the developers to manage and migrate the code across the instance easily.

However, I see some scenarios are not handled. Is there a way to handle below use case ?

I have 3 instances. (DEV, TEST, PROD)

An application App1 is created and moved to production, through publishing to Service-now App repository.

DEV instance is connected to Source control.

The current versions of individual instances are below:

• Prod : V1 -> Stable version tested and signed and finally deployed for production.
• ITT: V2 -> New enhancements/features ready for next production drop, which are undergoing testing.
• DEV: V2.2 -> Minor bugs of V2 testing and other small enhancements.

Q1) if there is defect identified in Prod, how to fix it, with the above changes in multiple instances.

Q2)     Is there a quick way to rollback DEV to V1 and fix the bug and commit as V1.1 without moving any code of V2 related?

Q3) And how Testing team too can stop V2 testing and deploy V1.1 test and resume V2 testing ?

Q4) How to commit finally to Prod?

Q5) How to merge the V1.1 fixes to V2 ?

In the standalone GIT, we can rollback to specific Tag, create a branch and fix the issue and move that branch to higher instance.

Later merge the new branch to main branch. However, I didn't see these options in the current source control integration functionality.

Can anyone help me in building the development strategy to address the above queries.

Thanks in advance

Regards

Viswa

[andrew_venables]

Hi Viswa,

ServiceNow source control has implemented Tagging and Branching this should allow you to manage your application in a familar way as per the steps you have outlined.

In order to use Source Control in ServiceNow you must open your application in Studio and use the Source Control menu:

This can be used in conjunction with publishing your application to the repository. Each publish must have a unique version number but the version numbers to not have to be linear or ascending. So you can publish a v1.0.0 then 1.2.0, then 2.0.0 and then back to 1.0.1 or 1.2.1. On the receiving instance you can then choose which version to install using the "All versions" option (only present when there is more than one version).

[Viswanatha Red3]

Hi Andrew,

Thanks for the reply.

I have not identified any option to move to a specific tag under the "source control"

Would you please explain how we can revert to V1 tag using the Source control (Assuming, tagging is done in regular interval).

Regards

Viswa

[andrew_venables]

I don't believe you can switch to a tag. Tags are just there to mark a release (e.g. to Source Control).

If you want to switch to a version at a given point then i think you want a branch.

When you publish to the repository i believe it automatically creates a tag.

[Jagadeesh Sand1]

I have enabled tagging but i cant find All Versions option, I do have four versions