Isn’t "trunk based development" just a complete crock of shit?
A more descriptive title would have been “Common misconceptions of Trunk-based development.” But when you search Google for Trunk-based development, this is the title of a Reddit post which is one of the first results that shows up.
I didn't realize it, but Trunk-based development can be a divisive topic. I published an introduction to Trunk-based development which got on the front page of Hacker News and this is a representative snippet of the comments:
The first comment says it pretty well, and the next two comments back it up. People are either thinking “Trunk-based development is what I’ve always been doing” OR they think it’s a horrible idea.
The takeaway is that there are a bunch of misconceptions about what trunk-based development means and after addressing those, I believe most people will find the idea enticing, or realise they are unknowingly already doing trunk-based development.
So, for those of you thinking “Isn’t trunk based development just a complete crock of shit?,” this article is for you.
“Trunk-based development means pushing directly to main”
While pushing directly to main can work in very small teams if you don’t yet see the value in code reviews, in practice, code reviews quickly become necessary to ensure the quality and maintainability of the code.
The biggest misconception about trunk-based development is that it requires that you and your team push directly to main. To many, this sounds horrible.
And rightfully so. Particularly in large teams, pushing straight to main is a recipe for disaster. And if trunk-based development means pushing directly to main, then how can there be code reviews?
However, it’s important to know that trunk-based development doesn’t mean that you have to push directly to main. You can do trunk-based development and still have branches and pull requests.
As with any mature development methodology, there is a sea of variants - and if anyone tells you their way is the one true way it will usually end in tears. There’s no one way that works for all team sizes, cultures, deployment environments, and so on. This is also the case for trunk-based development.
A variant, sometimes called “Scaled trunk-based development” [1], prescribes short-lived branches that serve the purpose of collecting a cohesive set of changes that can be reviewed together. As long as branches are relatively short-lived and there’s no policy requirement for a big feature to be merged in one fell swoop, but can instead be merged piecemeal in chunks that makes sense - you’re still doing trunk-based development.
“Trunk-based development means you only have a production environment”
A staging or pre-production environment is a useful way to ensure your changes are not breaking anything unexpectedly. Sometimes your code will behave slightly differently when it’s running in a production-like environment, than when it’s running on your local machine.
Another common misconception is that you cannot be doing trunk-based development and still have a staging environment where things get tested before hitting production. There’s nothing in the way of having your main branch be deployed to a staging environment where you can test it out before promoting your changes to production.
“Trunk-based development means you review incoherent pieces of code”
Yet another misconception is that with trunk-based development, you end up reviewing a bunch of separate, internally incohesive pieces of code. If this was the case, you’d have a really hard time understanding the changes as a whole and the review would probably end up pretty useless.
As always with code, scoping is key. And I don’t mean variable scoping. Scoping the size of a change is paramount to getting a good review. This is the case even disregarding trunk-based development.
This evergreen tweet says it succinctly:
As with most other things, doing small short-lived branches of coherent chunks takes practice but it’s very possible. Along with that comes the importance of writing really descriptive pull-request descriptions. If you’re submitting a PR that is a piece of a bigger feature, try to make sure the reviewer can put your change set into the context of the bigger piece and describe a high-level outline of the pieces that are still missing - which you plan to add in follow up PRs.
[1] - https://trunkbaseddevelopment.com/#scaled-trunk-based-development