Trunk Based Development is no free lunch!
During some instances in my career, “Trunk-Based-Development” usually referred to a code integration process that meant:
- No Pull Requests
- No Feature-Branching
- Always Pair-Programming
I believe that this is a very naive way of looking at Trunk-Based-Development, and often times, teams miss the forest for the trees.
To do Trunk-Based-Development right — a team must not overlook the following:
Discipline is key
Trunk-Based-Development as practice demands discipline from individuals.
- Task out their work and develop in small batches
- Ensure quality checks and safe-guards are in place for new features (TDD is a must!)
- Document enough for the next person working on that code
Teams adopting Trunk-Based-Development in name but not practice, I usually see:
- Massive code-commits encompassing changes from a day or more
- Code or new features often tested by-hand or manually, which implies lack of safety nets for the future.
- Severely under-documented code and very unhelpful git-commit messages.
If your team is struggling with these problems while doing Trunk-Based-Development, maybe it’s time to think of falling back to a Pull-Request-Model. Use the technique as a learning-tool.
Culture
Be very aware of team-dynamics and culture when introducing Trunk-Based-Development.
Take for instance collective code-ownership.
In some teams, members would often get offended when some-one changed an area of code they considered “their own” without sending over a pull-request first, or asking for something akin to ‘permission’.
Maybe take the opportunity to fix those issues before diving into Trunk-Based-Development.
Can we use Trunk-Based-Development to build up culture? I think “it depends” on the ground situtation.
Technical Excellence
If a team is lacking good infrastructure and tooling, Trunk-Based-Development will make it stick out even more like a sore-thumb.
Take, for instance — build-times.
If a complete end-to-end deployment cycle takes about 15–30 minutes, multiple commits coming in at the same time will quickly bog down the build-system.
Another aspect that can stand in the way is the testing strategy used in the project. For instance — if there are no automated tests to cover the most important business flows, Trunk-Based-Development would actually slow you down instead of making you faster.
I would always say that this needs to be fixed before you do Trunk-Based-Development.
Continuous Improvement
I believe that a team does not automatically produce high-quality code on the first go just because of pair-programming (or) a having a working pull-request model in place.
Having a high-quality code-base is the result of continuous review and improvement.
I take some time of my day day going over commits of my colleagues over the past couple of days. I do it not because I might be a playing the role of a technical-lead or a senior developer, but to understand what’s happening in the code-base.
If I were to find areas of potential improvement, I usually pair with the original author(s). This is also an opportunity for me to understand the original intention of the code and to see if I missed something.
Another practice I would recommend for the team are code walk-through sessions to makes sure that all team-members are “on the same journey together” when it comes to coding practices, standards or how tests need to written with respect to the code-base.
Trunk-Based-Development without such a practice of continuous code-review will give rise to inconsistent code-bases, which gets in the way of long term maintenance.
Conclusion
On a personal note, I think Trunk-Based-Development is a fantastic way to work. But like every sharp tool, one must also be aware of the ways things can go wrong.
If you are going to adopt Trunk-Based-Development, set things up in the project right first so that such a move can be a successful.
