Trunk based development is where all developers commit to the trunk, there are no branches. A team following TBD will pull from the trunk many times a day, knowing that the build passes. If you are developing a feature there are various ways such as feature flags or toggles to keep it hidden until it is ready to be presented to users.
You need:
- Small story sizes: devs will break up a story into smaller sub-tasts so that when working on a change, it should only take a few hours before committing and pushing. Therefore commits are typically small.
- Small build times: If build times are too big developers will be discouraged from committing often.
The benefits:
You will no longer encounter the problems with working on branches, those being:
- Merge conflicts - imagine a team of developers each having their own branch, perhaps even more than one branch. This could easily result in merge hell. Merge conflicts means the developer needs to focus on the code of another developer as well as their own code.
- Less visibility and communication. When working on branches you do not see the code that other developers have been working on until you merge your code in, leading to possible work duplication and/or you could break something unexpected once code is merged. Your code could even be incompatible with the code of another developer.
With TBD you are always release ready and this up-to-date state encourages more refactoring.
TBD goes hand in hand with continuous integration/ continuous deployment. In contrast to big stressful releases by frequently pushing to master this means that small improvements are continously being made to your live app. Smaller changes means smaller bugs that are easier to fix.
Top comments (0)