Understading the connection between branching models and delivery pipeline

Should I have one branch for each environment?

I’ve seen a lot of companies that designed a branch for each environment stage. So if there are three stages, DEV (ALPHA)→UAT (BETA) →PROD, there would be three branches too.

If we would automate the delivery pipeline for this model, it wouldn’t be sequential.

In this model, the new features are integrated on DEV branch, and deployed on DEV environment for validation and feedback. When they are ready to be delivered, DEV branch is merged into BETA branch, which will generate a deploy to UAT (BETA) environment. After it’s approved, BETA branch will be merged with PROD (master), generating a deploy on production. The code is being promoted, not the artifact. Notice that at each stage, a new artifact version is generated and deployed!!!.

If you have a branch for each environment, you won’t be able to create a single sequential delivery pipeline. It’s a problem because at each validation stage, you have to generate a new artifact, so your team is validating different artifacts (in this example, #v1, #v2 and #v3). The whole point of having validation stages is broken, since the artifact is not the same, and what you have approved on the previous environment may not work on the next.

You should promote the artifact, not the source code. So the answer is no, you shouldn’t have a branch for each environment.

The Continuous Delivery pipeline should reflect the environment stages, not the branch model.

This approach guarantees you the integrity of the artifact and enables you to isolate environment issues, making troubleshooting easier: if a bug is found only in a specific environment, it’s probably related to the environment itself — a misconfiguration, or a problem with one of the connected services or dependencies.