The Trunk Based Development website says “[…] a source-control branching model, where developers collaborate on code in a single branch called “trunk” and resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.”
That sounds great… but what exactly is it, and why should you care about it? For a bit, let’s forget about code and branches and use an analogy that is easier to understand — the transit system of a city.
Imagine a city with lots of different train stations. The network can run using lots of trains at different frequencies. Let’s consider three different scenarios:
What will be the effect of the three different possibilities on the people living in the city?
In the first case, if a person misses the train there is no other way to reach the destination until the next train, which unfortunately will arrive on the next day.
In the second case, if a person misses one train they can catch another train in a few hours and won’t have to wait for an entire day to reach their destination. This means people don’t care about the schedule of the trains as much as they do in the first case. It is possible to reach the destination in a few hours — late, but possible.
In the last case, if a person misses a train they can easily catch another train in a few minutes. It’s easy to imagine that people will stop caring about the train schedule altogether and focus on what they want to do at the destination. The transit system becomes an artifact that recedes in the background, letting people concentrate on what they actually want to do — living their lives and getting things done!
Now let’s go back to building and delivering software.
In a lot of teams, the frequency of releases is determined by “when this Important List of Features is completed”. That leads to unpredictable releases with large delays between deployments. Although such teams try to “fix” a release date and try to cut scope so that the Very Important Date can be met, it rarely works.
Engineers working on different feature branches rush to get their tasks done before The Date. Merging all of those feature branches becomes a painful ritual as people discover all sorts of changes that have happened in the repository over the past few weeks that they were working on their own branch. Merge meetings are scheduled and a War Room is created to tackle issues that stand in the way of meeting The Date. Inevitably, The Date starts to move. Seven “medium priority” bugs that customers have been complaining about need to be fixed. The CEO’s personal favorite feature request has to be part of this release even though the team heard of it a week ago.
Every little thing is important because who knows when the next release will go out? The entire team — nay, the organization — rallies around The Date even though it has changed three times and the original date has been forgotten.
There are some themes that emerge in this familiar scenario:
So what is the solution to this problem? We need to increase the frequency of the trains, of course. Hundreds of them every day!
For software engineering, that implies that…
All of this sounds great in theory and it makes sense. How about in practice?
All of this comes together to ensure the codebase is releasable on demand. Bug fixes are deployed as soon as the fix is available on the trunk. Teams stop coordinating releases to figure out which commits are “safe” to release.
Developers go back to focusing on what is important — building features and eliminating bugs — rather than being burdened with a release date.