I’m continuing with the journey of separating into a development app and production app for my apps. I’ve got the development and production versions cloned to my local machine.
Are the data tables stored somewhere in those files? If I make changes to the data tables in production and then copy the files over to the production repo, do those changes get propagated?
No, the repo does not contain data or table definition.
The two apps can work with the same tables if it’s ok to share test data with production data or with different tables. If you use different tables, the dev and prod tables can have the same name, so the same code will work on both apps.
When you clone an app you also clone the tables and their content, but that’s another story.
Okay, so when I’m trying to migrate changes from a dev app to a production app, I need to:
Copy the affected git repo files (making sure to not copy anvil.yaml, since that includes dependencies and server config that might not be the same between dev and production versions). Everything else looks safe to copy.
Make any data table changes (assuming dev and production apps are using different copies of the data tables, which I’d assume would be the case for most apps)
Update app dependencies that changed in the development version
Push the git repo changes to the production version
As long as #2 and #3 don’t break something in the production app, it should remain accessible throughout. And if #2 and #3 do break something, it’ll only be until #4 finishes.
Does that sound right?
If the dev and prod database schemas are documented in some manner (e.g., a text file), then you can use anybody’s DIFF to compare the two, and come up with an explicit list of changes. This helps make sure that comparisons go swiftly, and that no detail is missed.
While a schema is not in the Git-accessible per-app anvil.yaml file, there does appear to be a roundabout way to get one: Export your App to a .yaml file (IDE -> Gear -> Share -> Save).
You may already be doing this as part of an application backup.
When you look at the resulting file in an editor, there does appear to be a (minimal) schema in it, along with all of the source code (tightly packed). It should be possible to parse and extract the schema into a suitable document, for comparison purposes. (Comparing the file as-is is probably not useful, as .yaml data is not guaranteed to be ordered consistently.)
File formats are subject to change without notice, of course, so this should not be considered “good practice.” But for now, this is as close to an “official” (Anvil-produced) schema document as I know how to get.
While I’d love an automated migration for the data tables, it feels pretty fragile to parse the .yaml backups to get a list of differences. I’ll stick with keeping a detailed list of changes and making those manually, at least until Anvil itself provides better support for the prod/dev split.
I agree. I’m designing a set of formal data records for describing such situations. Where there are multiple tables, some of which may be shared by multiple apps, it’s important to get this design right (accurate).
Yeah, the typical complex Anvil “app” seems to be a collection of apps for different purposes, each sharing some subset of data tables. Making sure nothing gets left out of a migration is looking to be a fairly complex procedure.
It’d be difficult to get right, but I’d love to see built-in support for this sort of thing. Automatically spawning production versions of the apps on a first deploy, automatically copying over data table structure and changes, etc.
One difficulty is that there is no one-size-fits-all. For some apps, Production gets every table and every column from Development. For others, it’s selective (e.g., skip the “debug_*” tables and columns). To name just one kind of variation.
Still, where there are repeating patterns, automation is possible…
Agreed, I’d like to see something with a setup step where you can specify what the production app looks like relative to the development app. Provide some rules for the automation to follow.
Or hooks, to plug in your own transformations.