After App Upgrade, the Google Sheet source used by the application is changed

[M_Felix]

Hello Community,

I am new to Appsheet. I would like to ask help on what is the best practice when deploying an update in my application using App upgrade.

I have a copy of my customer feedback application where I do my updates and other modifications. I call it Dev. Dev is copied from Live version which is used by the users.

When I am ready to push my changes from Dev to Live. I go to Manage > Versions > App upgrade. I just input the name of the app where to get the upgrade from then press Upgrade App.

The problem I encounter is after the upgrade my Live environment is now using the google sheet source of the dev.

To illustrate

Before App Upgrade

1. Dev > Dev google sheet source
2. Live > Live google sheet source

After App Upgrade

1. Dev > Dev google sheet source
2. Live > Dev google sheet source

I am able to verify this by going to Data > Tables > select a table > click storage > check source ID.

Is it possible to prevent the change in the google sheet source?

Also if I have changes on the google sheet structure itself example (new columns)
how should I go with the app upgrade.

My subscription is just a PRO/CORE version so I cannot use the stable version feature.

Thank you very much in advance for the help and sorry for the long description.

[Steve]

M_Felix:

Is it possible to prevent the change in the google sheet source?

Nope.

[M_Felix]

Hi Steve,

Thanks for the reply.
If the Google source will always change after App upgrade then I have to add the step of restoring the Google source ID to the original one. Is this correct?

1. Push updates to Live environment from Dev via Versions > App Upgrade.
2. Update the Live Google sheet if there are new columns or other changes.
3. Change the Google Sheet source path for the Live environment via
   Data > Tables > Source path. (This has to be done per table right?)

[Steve · Accepted solution]

M_Felix:

Is this correct?

Yep.

Here’s the process I use:

1. Save any outstanding changes to the development version.

2. Note the version of the current development version.

3. Update the development version to use the production tables.

4. Make any other tweaks to the development version needed to make it production ready.

5. Deploy the development version.

6. Upgrade the production version from the development version.

7. Restore the development to the version noted in (2).

This way, the production upgrade occurs in the shortest amount of time, greatly reducing the chance a user may sync while you’re upfitting the new production copy, and avoids any need to pause the production app.

M_Felix:

This has to be done per table right?

Correct.

[Florian_Noizet]

Hi Steve,

I don’t get your step-by-step.

What happens to your many “outstanding changes” when you update development version (step 3) ?
Because changes may need new columns in data source that you won’t have in Production version. Am i wrong ?

So from my understanding :

• either your process cannot be used when data source is modified.
• or you have to applky your changes twice (step 1 and step 4)

Seems odd to me, so I guess you meant something else entirely.
Could you clarify for me ?
Many thanks.

[Ksenia1]

Hi @Steve,

Thank you for the suggested step-by-step plan.

What if we are talking about two App Owners here - a developer updating the app in Dev and let's say a manager being the owner of Prod and the Prod table containing sensitive data, which the developer is not allowed see. In this case this approaches will not work... Is there any way to solve this as elegantly als possible?

Thanks in advance!

[Steve]

Is the manager qualified to change the app configuration?

[Ksenia1]

Well, the point here is that the manager, even if qualified, should not have do any configuration, but deploy the live app from his instance (and upgrade with an updated version if needed). So if your question implies that the manager makes the changes oneself and works with stable versions - that is not an option here.

The best solution I see is a checkbox when upgrading the app, similar to copying the app, where you can decide whether to keep its database (and app information) or overwrite it with the one from the app upgrade.

[Steve]

Unfortunately, there is no such option. You could look into partitions, which would allow the app to choose its data sources, but I believe the feature is enterprise-only.

Scale using data partitions - AppSheet Help