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
Structure
master
rc/1.0
rc/2.0Pros
- 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
Cons
- 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.
Best For
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
Structure
master
developPros
- 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
Cons
- 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
Best For
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.
Summary
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.
Comments