It’s tough to make a one-size fits all recommendation, since every app is a bit different.
The complexities in my case came from having a single “app” that was composed of multiple Anvil apps. This is a pretty typical pattern used with Anvil. One of my apps, for example, was for authors, another was for customers buying things, another was for readers, etc. These apps all shared some data tables (Users, for example, among others).
Splitting this combined app into Dev/Prod versions (at that time I wasn’t thinking in terms of test versions, since publishing Dev in Anvil worked fine for my testing) highlighted the complexities really well for me.
When you clone an Anvil app, the clone gets copies of the data tables used by the project it’s cloned from. In the case of a multi-app Anvil app that shares data tables, that means every Production clone of the various apps has its own copy of shared tables. You have to go through manually and fix that up. Luckily, that’s a one-time thing, but it’s complicated especially if you have data in the tables already and have linking fields to other tables.
Since data tables aren’t stored in the git repo you download, though, changes to those don’t get copied when you update Prod from Dev. You have to manually update the Prod data tables with changes made in Dev.
Specific steps I identified are in Cloning apps and data tables for Production and Development Apps - #4 by p.colbert I can’t even say that’s all of what would need done.
Anyway, it ends up being a mess, and I don’t think it’s in the For Dummies category. It was enough of a mess that I kind of stalled on development because migrating to Prod would have been error prone and time consuming.
There have been some feature requests that Anvil handle the Dev/Prod split more natively. I’m really hoping something along those lines is adopted because of the complexities in doing it manually.