How do you rollback or backout of a scoped app version

danpatino
Tera Expert

This is the desired scenario: I want to be able to develop and publish app version 1.0.0 to my company's internal repository and install that in production.  Then, if I develop version 1.0.1 and promote that to production, I need the ability to roll back to version 1.0.0 if we feel things aren't working out.

Does anyone know how that is done?  I realize we could also use a git repository but that seems like a pretty basic capability that all methods of applying releases should have.

3 REPLIES 3

Pradeep Sharma
ServiceNow Employee
ServiceNow Employee

Hello Danpatino,

 

Unfortunately, Rollback to a specific version (Uninstallation of an app) is not supported in Scoped Application.

If you feel strongly about this requirement, I invite you to open an enhancement request! Our product managers DO listen.
 
Thanks,
Pradeep Sharma

 

danpatino
Tera Expert

Hi Pradeep,

Thank you for taking the time to respond.  I know it's not easy confirming a shortcoming in a product you are passionate about.  I'll make sure to submit that enhancement request.

However, I just thought of something this morning.  Here are the steps I took:

  1. Setup an application in Dev (Instance A) and Test (Instance B)
    1. Created a new scoped app in Instance A
    2. Created a table with what we'll call Original Config
    3. Published the application to an update set 1.0.1
    4. Export update set 1.0.1
    5. Applied the update set to Instance B
  2. Modified the application
    1. Modified the table on Instance A with New Config
    2. Published the application to an update set 1.0.2
    3. Exported update set 1.0.2
    4. Applied update set 1.0.2 to Instance B
    5. Confirmed New Config was applied to Instance B
  3. Rolled back the configuration
    1. Exported the update set 1.0.1 containing Original Config from Instance A again
    2. Uploaded that to Instance B
    3. Confirmed all conflicts about having "A newer update exists...."
    4. Committed update set
    5. Confirmed Original Config was applied to Instance B

Essentially I was able to rollback by retaining a history of exported update sets.  The reason I had to reimport update set 1.0.1 is because you cannot commit an update set you have already committed.

This is not a perfect test.  Since I'm working in sandbox environments I had to use update sets as opposed to publishing to the internal repository.  If someone can reproduce these steps by using the repository in steps 1.5 and 2.4 and copy/paste these steps in a reply along with a few screenshots, I will mark their solution correct.

 

danpatino
Tera Expert

I realized immediately after posting that lengthy reply why this approach won't work.  All of the application files that exist in update set 1.0.1 will be reverted to their previous state.  However, any new application files in 1.0.2 will not be deleted because there is no 1.0.1 version of them to mark as deleted.

If someone is willing to test this and prove me wrong, I'll happily award you the correct answer.  In the mean time, I'll accept the limitation.