Dev, Testing, Production Deployment

I have an app that depends on locally hosted uplink code to talk to an internal database and I’d like to create separate copies of that app for development, customer testing and production. There are separate internal databases and I have several copies of the uplink code running locally, one for each, so I’d like to have separate keys for the uplink connection.

I intended to use git to accomplish that by creating the three apps, cloning one of them locally and then adding the others as remotes.

However, having tried that, I can see the file ‘anvil.yaml’ has several entries which are specific to the original app (e.g. the name of the app or the tables it can access).

Has anyone else got this working or am I barking up the wrong tree?

1 Like

TL;DR you are doing the right thing. Anvil has a simple dev/production model built in, and supports arbitrarily complicated ones via the Git interface.

Anvil already supports the idea of a “Published” version (choose it from the Version History dialog). If you have a published version of your app, there will be a separate Uplink key for the dev and published versions of your app. They will, however, access the same data tables

A second approach is to have two entirely separate apps! You’re on exactly the right track - clone one locally, then add the others as remotes, and force-push as necessary. Each app has its own name (eg “My App Staging” “My App Production”), its own uplink key(s), and its own set of data tables. (Apps can also share data tables.)

You are very much barking up the correct tree - this is an architecture we have used ourselves, and it works quite well!

1 Like

If I want to use the ‘multiple apps/remotes/force push’ solution, how do I handle ‘anvil.yaml’?

If I force push it, it overrides the app name and sets data tables to those in the original app.
If I try to use a .gitignore file, it gets deleted each time the app auto-saves.

It really shouldn’t! (The name, perhaps - but I’m pretty sure it doesn’t update the data tables! That debris you see in anvil.yaml is the detritus of an import/export operation that should have been auto-cleaned.)

It did when I tried it yesterday. The file contains details of the data tables from whichever app I first clone. When I push it to a different remote, pointing to a different app, that file gets pushed and the new app attempts to access the tables belonging to the original.

It contains those table details (for hysterical raisins), but, as the author of our Git push-handling code, I very much doubt it takes any account of them!

I’ve just tried it again today and it seems to be working just fine. No idea what I might have done differently yesterday!!

~waggles fingers~ Myyyysteryyyyy…

As a note to time travellers: the information in this thread is obsolete I think.
ATM (jan 2021) the anvil.yaml file does contain data table information that is being used. In fact if you use git to sync a DEV app to a PROD app references to the PROD data tables will be overwritten by references to the DEV data tables, thereby losing all production data. Unless you find the table references in a backup and manually restore them.
Look at the discussion here for a workaround of sorts: Handling anvil.yaml in a git workflow

1 Like

Admin note: The information in this thread remains current: The data table specifications in anvil.yaml do not determine which tables your applications will run with. They are advisory (and used by the App Server). The workaround used in @mjmare’s link is entirely about avoiding awkward (and meaningless) merge conflicts.

1 Like