Hey everyone! I'm working on setting up Continuous Deployment (CD) for a Gitflow branching strategy. I'm trying to clarify when deployments should be triggered for the different environments: dev, QA, UAT, and prod. Here's what I have in mind so far:
1. Any type of merge to the /develop branch should trigger a deployment to Development.
2. Creating or pushing to a /release branch should trigger a deployment to UAT.
3. Merging from /release or /hotfix into /main should trigger a deployment to Prod, but with manual approval required.
Does that sound right? I'm also pondering how to handle QA—should it be done with tags on /develop or perhaps with a qa/* branch?
1 Answer
I think you might want to check out the "Note of reflection" in the original Gitflow post. Personally, I find Gitflow a bit cumbersome for web apps and APIs because teams usually manage their environments directly. They typically use a trunk-based development approach, which allows for quicker merges and rollouts to lower environments for testing and QA. If your development process takes longer, using release branches could be beneficial for applying bug fixes across maintained versions.
I get that, but for us, trunk-based development isn't feasible since our releases have to go through security reviews and scheduled downtime. That's why I'm looking for a more strategic deployment plan that accommodates multiple environments.