Currently in this repository I see the following branches:
- dev (as default)
- master
- prod
To my understanding on a strategy where we have on env per branch, we make a change on dev, if everything if fine we then create a PR promoting changes to next env, in this case prod.
-
In this case why we have master ? What purpose does it serve in the workflow?
-
Besides that I'm curious in this approach:
How we update a value in terraform.tfvars for prod?
Because if we need to keep branches in sync to promoted changes I guess we cannot directly commit to prod. Instead my assumption is that even if we change just a value to prod we have to actually submit it to dev and "promote" it with a PR to prod so the branches remain in sync. Is my assumption correct?
Currently in this repository I see the following branches:
To my understanding on a strategy where we have on env per branch, we make a change on
dev, if everything if fine we then create a PR promoting changes to next env, in this caseprod.In this case why we have
master? What purpose does it serve in the workflow?Besides that I'm curious in this approach:
How we update a value in
terraform.tfvarsforprod?Because if we need to keep branches in sync to promoted changes I guess we cannot directly commit to prod. Instead my assumption is that even if we change just a value to prod we have to actually submit it to dev and "promote" it with a PR to prod so the branches remain in sync. Is my assumption correct?