Azure DevOps: Choosing a Branching Strategy for Your CI/CD Pipelines
A topic that I believe does not get enough discussion is that of branching strategies and how they can affect the CI/CD flow. There are pros and cons to a few popular branching strategies. Let's dive into release branching (trunk based) and gitflow.
Release Branching (Trunk Based): Pros & Cons
master rc/1.0 rc/2.0
- Allows you to work on multiple versions of an application at once very easily
- Makes it easy to create hotfixes off of a specific version of a release
- Ensures the latest release branch is an exact copy of master
- Requires a new branch following each release and delete the old rc/* branch
- If you have your CI/CD configured to run after every change to an rc/* branch, you need to be careful the development team doesn't accidentally deploy a newer version.
Release branching is best for larger teams who need to work on multiple releases simultaneously. It allows you to easily transition between versions of your codebase. It does add a marginal amount of overhead as it requires you to create a new rc/* branch following every release.
Gitflow: Pros & Cons
- Lower overhead when compared to using rc/* branches, you only work on the develop
- You don't have to create a new branch after each deployment
- Teams always know which branch to work in for non-prod changes
- It is more difficult to manage multiple releases being developed at the same time
- The develop branch can become out of sync with master if its not properly maintained
Gitflow is best for either smaller teams, or products that have infrequent releases as it offers less flexibility than gitflow. However, it does require less overhead as your team won't have to maintain transient rc/* branches after every release.
It's important to choose the branching strategy that works best given your circumstances. No strategy will be a silver bullet, but there is likely one (perhaps not even one listed above) that works best for your development team.