So I’m curious how people here with production grade apps deal with having say a test/prod version of the app especially if you have a database, etc. I’m trying to think of the best way to add updates/enhancements to the site without screwing up the existing site, not sure if I should just clone the app and then update it that way and only bring back over modules and not the db or what.
Curious how others approach this.
Thanks
Search the Forum for the term “Publish” or “Published”. You’ll see that you can “freeze” the app (as seen by users) while still working on improvements, step by step.
This leverages Anvil’s use of the Git version control system. Each app has its own independent repository of files, with a history of prior versions. You can mark any version as “Published”, and that’s what end-users will see. (Only one version can be Published at a time.) Meanwhile, you can continue to improve the code, creating new Development versions step by step.
As I understand it, this use of Git applies only to the app’s code, user interface, permissions, and services. Changes to your database structure (tables and columns) and content (rows) take place immediately, and are visible to all versions of the app, including the Published version.
Thus, if you need to make backwards-incompatible changes to database structure, then you’ll need to make them in a clone of the original app. As a distinct app, the clone can have its own, distinct set of tables, columns, and rows.
After you’ve done this a few times, you may discover a stable set of subroutines and/or data, things that absolutely don’t (or shouldn’t) change from one app to the next. You may then want to make a “library” out of them, usable from all the apps. This gives you a single point of maintenance for these routines.
Again, this applies only to code and user interface. Library code does not inherit the library app’s tables, permissions, or services. Those must be provided by whatever app uses the library.
See also:
One more thing to say: If you’re using the same code in different environments, you can make two apps (your “development app” and your “production app”), and use Git on your machine to pull code from one and push to the other. That way, you have separate environments with separate data tables.
(Note: Beware that this will break App Secrets. By design, an App Secret created in one app cannot be accessed by another app. However, you can access your dependencies’ App Secrets, so if you want secrets that are available in both environments, put them in a dependency they both share.)
I attempted to implement this idea: performing testing in a separate Anvil app and using git to move code between them, but I found it very awkward at first. In the process of writing this post, though, I came to see a more sensible workflow.
Here is what I did in my first attempt:
A post I found subsequently seems to suggest this (less involved but still clunky) alternative, after steps 1 and 2 as above:
3. Clone with Git my development app to a separate local repository.
4. For each commit to the development app, pull it down to my local development repository, copy the changed files to my local production app directory and commit the change to my local production app repository.
5. Repeat step 4 for each commit.
6. When ready to make a change to the live production app, push my local repository up to Anvil.
In a different place, meredydd speaks of “force-push,” which suggests:
That sounds like a good workflow. Once you’ve done the first 3 steps, it’s just
And you could automate step 4 with a Bash script…
#!/bin/bash
##
# Anvil local repository watcher.
# Syncs with the cloud version of the app.
# Just commits; you need to add a push and a pull, but it's a start.
# Also, if you modify both the local and cloud version during the watch
# period, you might get merge conflicts. So don't do that.
#
# Where the app is checked out
APP_DIR="$1"
# The message to use for the autosave commits
AUTOSAVE_MESSAGE='Local autosave'
# How many seconds to wait between autosaves
WATCH_PERIOD=5
cd "$APP_DIR"
while true; do
LAST_COMMIT_MESSAGE="$(git log -1 --pretty=%B)"
if [[ "$LAST_COMMIT_MESSAGE" == "$AUTOSAVE_MESSAGE" ]] ; then
# If the latest commit is an autosave, overwrite it.
git commit -a --amend -m "$AUTOSAVE_MESSAGE"
else
# If the latest commit was done manually, make a new autosave commit.
git commit -a -m "$AUTOSAVE_MESSAGE"
fi
sleep $WATCH_PERIOD
echo "."
done
cd -
(how did you do that expanding code block?)
[details="Isn't this cool?"]
Your words go here.
[/details]
Your words go here.
I wouldn’t use it for anything crucial though, because it’s easy to mistake it for a static triangle next to some static text!
Thanks to @hugetim for popularising that tag!
We use the two app approach for development and production, but we don’t use any fancy git commands.
On your step 2 you mention the loss of history as a problem, we consider it a feature!
Initial setup
Everyday workflow
We never use git commands directly, we only use PyCharm pull and push buttons (and create change lists and commit them inside PyCharm too).
At this point the history of App Prod is clean and only shows the intended commits.
Access to tables via Anvil ‘app_tables’ will work seamlessly as long as the apps either share the same tables or use different tables with the same name. Access via SQL requires a line at the beginning of the module to set the correct table name.