This article is written after an evaluation of trunk-based development and feature toggles for my project. It might be opinionated, but I tried to present a holistic explanation of why you might want to move from feature branching to trunk-based development and how you can do that using a set of different techniques and best practices.
Feature branching is an approach where you create a branch in your repository for every task or feature. Depending on the size of your features, implementing them may take weeks and even months. Supporting such feature branches requires resolving merge conflicts coming from the
main branch and is therefore costly and error-prone.
If you work in a large team, then a siloed process of working on the feature code means the other developers don’t share a significant part of the implementation until you drop a heavy chunk of changes to the
main branch at once, causing cognitive overload and adaptation overhead for your teammates.
If you adhere to the infrastructure-as-code approach, then the deployment of a new feature includes not only new code but also infrastructure changes, configuration changes, and database migrations. Merging everything at once may also incur an uneven load for other teams, like Infrastructure, QA, or Operations.
Avoiding long-living branches
Why you would like to avoid long-living feature branches:
- avoid support costs due to merging of the
mainbranch into feature branches;
- have a faster and lighter turnaround of code between the developers and teams;
- move towards releasing and deploying small steps instead of “big bangs” for safety and confidence reasons;
- make smaller changes available for smoke testing or even partial feature testing.
main branch, or trunk, I mean the branch where all developers integrate their work. This is usually the branch you use for releases and/or deployment. You should have enough automated tests to make sure this branch is always green and deployable.