Trunk-Based Development: a love & hate story
A few months ago I started working on a brand new project with a (kinda) new team and one day, as we always do here at Comparethemarket, we sat down to define our ways of working. Part of the discussion was around which development style we wanted to adopt going forward and trunk-based development was suggested by the two senior engineers in the team.
What is TBD
TBD is an extreme programming technique developers can use to collaborate on code. In a nutshell, trunk-based development, as opposed to branch-based development, is done when developers collaborate on a single trunk (usually master) and they push their code as frequently as possible. If the build fails at any point, it is the responsibility of the person who last pushed to fix the code quickly by using a roll-forward strategy.
Why would you do that?
Because TBD helps with:
- Merge conflicts: by frequently committing small changes to master, developers reduce the number of merge conflicts
- Continuous Integration: again, by committing small incremental changes to the code, developers don’t end up being isolated on their own branch and they quickly get feedback on the code they just pushed. Their commit kicks off the CI and if a build fails, it is the responsibility of the person who last pushed the code to make the build go green quickly.
- Code review: even code reviews become easier and quicker, as developers don’t have to review large pieces of code all at once anymore.
What we used to do before TBD
In my first team here at Comparethemarket, we had feature branches that could be kept open until the feature was completed, and good old Pull Requests where we had to get at least two reviews before merging into master.
So something that wasn’t quite git flow and wasn’t quite TBD (it could have been if only our feature branches were short-lived — i.e. less than a day).
How we did TBD
There are a few ways of doing TBD and we decided to go down, in my opinion, the most extreme road.
In what we call our ‘developer agreement’, we defined the terms and conditions:
- Push straight to master
- No branching
- No committing code without it being reviewed on the author’s local machine
- Minimum 3 pairs of eyes on a commit
- Show passing tests to reviewers
- Prioritise fixing master if commit breaks the CI build
What didn’t go quite well and how we overcame those issues
During the first couple of weeks trialing TBD, the first problems started to arise.
At first, we decided to get a review before committing any code, which was mainly dictated by the fact that it’s hard to review a bunch of commits on a local machine.
Soon enough we realised how inefficient that was, as people had to wait around to get a code review on a single commit, which sometimes was as little as refactoring a line of code or importing a new package.
We therefore started making commits without pushing to master and only when a meaningful piece of work was done, we would get a code review by showing the diff for each commit on local.
But having everything in local led to other issues.
Since we couldn’t push to remote, it would happen that someone working from home had a hard time getting the code reviewed and maybe reached the end of the day without having pushed the changes.
And I’m sure everyone agrees that it is a huge risk, as that person could win the lottery or get the laptop stolen or broken and all the progress made will be lost forever.
So, as we went on with TBD, people started creating short-lived feature branches to avoid these issues.
What I didn’t like about it
The main thing I was missing, as a Junior Software Engineer, was having a place where I could review the team’s feedback as comments, giving me the time to reflect on solutions before implementing the suggested change. I sometimes like to revisit pull requests I opened some time ago to remind myself how I implemented a feature or revisit suggestions from the commented feedback I received on it.
Also, I didn’t like the fact that we had to do so many tweaks to how we did TBD in a really short period of time. I think sometimes it’s best to take a step back and admit the failure, instead of trying to make it work.
What I liked about it
Regardless of all of the above, there were certain things I liked very much about TBD:
- We were committing to master often, more than once a day, which made the feedback loop quite fast. We never ended up doing a big piece of work before realising it was breaking our pipelines.
- Not having big Pull Requests to review (or better, not having Pull Requests at all) made code reviews really frequent and quick.
- We hardly ever incurred any merge conflicts
- We were doing real Continuous Integration, as opposed to doing ‘CI theatre’
What I learned
There are a few takeaways I got from this TBD experience.
- Trial a new process first
First of all, I learned that, when trying a new process, it’s good to give the team two to four weeks to trial it and then get together to discuss how it’s working out and if substantial changes to it are required.
It’s important to frequently review your team’s processes to avoid chaos. - Choose the right tool for the team
Another thing I quickly realised is that a process should be chosen based on what works best for the kind of team you’re in:
If you’re in a team of mature developers that have been working together for a while, trunk-based development is definitely a great way of contributing to code.
If you’re in a ‘junior-heavy’ team, TBD might not be the best choice, as it implies a certain level of trust and confidence in the code that gets committed/reviewed.
In TBD, code reviews should happen in a matter of minutes. If the review becomes one or two hours long, then you are negatively affecting cycle times.
We shouldn’t blindly choose a process just for the sake of saying we’re doing extreme programming. It is a continuous growth path.
You get to refine your ways of working and practices as you get coding experience, and you should trust your gut and speak up if you think a process you’re using is not working out well.
It’s kind of the same when your team gets to decide which language, framework or database to use in a new project. While it could be tempting to go for the newest thing just because it’s new and cool, I have learned that taking time to do some research, making a proof of concept or investigating existing projects/teams making use of it are great ways to make a real informed decision.
Would I do TBD again? Yes, once I become a more experienced engineer and if I find myself working in a small team of (no more than 3–4) equally experienced engineers. As for now, my team agreed that branch-based development works best for us.
I hope you enjoyed reading how I dealt with trunk-based development for the very first time.
Thanks for reading,
Mary
