I'm trying to set up a good git workflow so that I can manage automatic deployments to multiple environments (dev, prod).
Typically the way I would do that is:
1. Have a feature branch for new work (in this case, its our flutterflow branch)
2. After a PR, it gets merged into dev branch, and automatically deployed to the development environment.
3. After passing more tests and getting final approval it gets merged into prod, and automatically deployed to the production environment.
My issue is that in FlutterFlow, the configuration of dev vs prod is managed by changing it within the UI and pushing to the flutterflow branch. This is at odds with merging flutterflow -> dev -> prod.
The only two options I can think of are:
1. After committing, merge flutterflow -> dev if the code is pointing to the dev environment, or flutterflow -> prod if the code is pointing to the prod environment. The problem here is that another team member could modify the project while were testing dev, and then when we went to push to prod, they've introduced issues (yes, I've tried the dev branches within flutterflow, and IMO its still unusable for significant development). We really should be merging the tested dev branch to prod instead of going from flutterflow directly to prod.
2. Do the typical workflow, flutterflow -> dev -> prod, but when deploying to prod, use a custom script to modify the related project files to use prod values. The problem here is that we have to maintain our own copies of the dev and prod files outside of FlutterFlow, which is redundant and error prone (ie, we add a new environment specific variable but forget to add it to the custom prod code in the repo).
Seems like this should be easier. Am I just missing something? Is there a better way of changing build target and values directly in the project files?
I know the FlutterFlow CLI lets you specify the environment, but that seems designed for checking out the entire project (which could introduce untested code, like approach #1).