According to how I understood it, incase i would copy my current application (google sheets as a source) and do some changes in it such as adding sheets, tables, new views, columns to existing tables, VC, edited the expressions, changed formats and colours,… I can then navigate in the app builder / Manage / Versions / App Upgrade / Enter the copied application full name in the “Copy app upgrade from” and get all the changes i have made into the Version i am currently using ?
When you use app upgrade, only the app configuration is copied, not changes to the data sources. If you’ve added, removed, or moved columns in the spreadsheets you used for development, you’ll need to reproduce those changes in production as part of your app upgrade process.
Having a latest vs stable version is an enterprise feature, but upgrading an app is not.
I prefer to have 3 versions, Dev, Testing and Stable. These are copies and I move progress from Dev to Testing to Stable by upgrading the apps.
Dev points to a Dev database. Testing and Stable to the final database.
When upgrading from Dev to Testing you need to point the tables to their corresponding database
I’m using upgrade for the first time for a client that is on Core, finding it a awkward.
I used the same model as you, but then bumped into the source remapping issue when upgrading. If there’s a better way than having to manually remap all the table sources I would love to know.
Do you make a copy of Dev, change all the source pointers in Dev(copy), and then upgrade Testing with Dev(copy)? Or remap Testing after the upgrade?
The better way would be to use partitioned tables, but that’s an enterprise-level feature.
Using app upgrade, consider having a staging copy that exists solely to remap your tables. Copy dev to staging, remap staging, copy staging to prod.
No matter what approach you use always verify you’re working on the copy you intend to. I check the URL itself rather than trusting myself to update the app name. (I wish app upgrade didn’t carry over the app name!)
Yeah, this is for a Core deployment, Enterprise is not an option per client.
I’ll write the process out, see if this is correct:
DEV points to dev_database
PRODUCTION points to prod_database
Copy DEV to new app STAGING, copying data (“make a copy of data”).
STAGING points to staging_database, but AppSheet will have chosen the name for you.
NB copied files names: the new copies of Sheets files will all be named to “the name of the first table you added to AppSheet, from that file”
Any tables in STAGING app that match tables in PRODUCTION (ie you’re not changing) should have their sources changed to prod_database now. Otherwise, PRODUCTION will have sources changes to STAGING’s, and you’ll need to change them after the Upgrade, which could have strange effects.
If any STAGING tables are updating the schema of an existing PRODUCTION table, make sure the data in STAGING is current to what is live. Otherwise, you’ll need to update this data after Upgrade.
Any new tables will be created during Upgrade.
PRODUCTION name will get renamed to STAGING’s name when you Upgrade. This is odd. Rename STAGING to same name as PRODUCTION before the Upgrade, or fix PRODUCTION afterwards.
Update PRODUCTION with STAGING app.
NB file locations: Any new or updated tables will be pointing to their source file in STAGING. If you want all the files in one folder, you’ll have to move them from STAGING to PRODUCTION folder.
If PRODUCTION has a table that was “replaced” (ie source points to STAGING file now), the original table is still in it’s same location in PRODUCTION. I would purge these tables once the Upgrade is complete, otherwise you have legacy table names scattered across old files.
Exhale.
Did I miss anything?
STAGING is now a clone of PRODUCTION, with all the tables mapped to the same sources.
You can use it for non-schema development/testing/deployment, but be aware that STAGING is pointing to live data.
Rename STAGING to TESTING/? if you want to use it for non-schema development.
I wouldn’t copy dev to staging. Instead, I’d just have a generic staging that contains configuration of whatever app I’m staging. I’d use app upgrade to then upgrade staging from dev.
Ok, after some testing I understand your workflow now. I was operating as if Upgrade was closer to merging changes, but as I see it is really just an over-write.
For configuration changes, that’s no problem now that I understand the function.
For schema changes it seems to me safest to:
Manually sync the schema in Production to the new schema in Dev/Staging
Point Staging to the Production sources.
Upgrade.
I’m going to go to client’s address and put red tape directly on their screen where the Update button is, just in case.
