The Agile Echo

Why are we so afraid of Trunk-Based Development?

TBD is a software development approach where code changes are committed directly to the master (trunk), rather than branching and merging them. Sound absurd? Then you should definitely take a read!

Cover Image for Why are we so afraid of Trunk-Based Development?
Dan the Dev
Dan the Dev
trunk-based-development

The fear of something new

Despite Trunk-based Development having amazing benefits once mastered, many developers are very afraid of adopting it.

The reasons are multiple, here are some of them:

  1. Fear of breaking the codebase: one concern with Trunk-based is that committing code changes directly to the trunk may increase the risk of breaking the codebase. This may be especially concerning for larger teams or projects with complex codebases. The fear probably comes from a history of issues during production release or the addiction to the false feeling of safety that Pull Requests gives us.

  2. Lack of understanding of the benefits: it’s hard to fully understand the benefits of Trunk-based before trying it; benefits like faster development cycle, improved code quality, no more Git conflicts, and debugging almost totally removed, are cool to say but you deeply understand how this improves your work only when you experience them.

  3. Refusing additional work: Some developers may view Trunk-based as requiring more work, as it involves continuously integrating and testing code changes rather than merging code changes in larger batches. And this is true! Working only with the master branch requires some additional coding that enables us to merge so frequently (think feature flags, for example) and some of us are not professional enough to accept that this additional work is required to have a quality outcome and will be repaid with all the reworks we are avoiding thanks to it.

  4. Resistance to change: I have to also admit that Trunk-based involves a different way of thinking about and approaching software development; it’s a complete shift in the way we think about software and plan to release it, with the same impact as the shift in using Test-Driven Development. In the end, software developers are human beings, and human beings are resistant to change by nature.

I’m not here to say that the concerns about Trunk-Based Development are not valid, they are, but this tool solves problems instead of creating new ones and the open mind that it requires to be understood is totally worth it!

Keep your mind open and your passion on the line

As always, the best way we have to learn something is to be open to changes and practice it: do Katas, any kind of exercises, read books and learn how to begin with this practice to see if it can be a match for you like it was for me.

Here are some of the main skills that you have to put on the table to overcome your fear of Trunk-based Development and learn it:

  1. Understanding the benefits of Trunk-based and trust it: with TBD, you can achieve better, cleaner software, released multiple times per day, avoiding GIT conflicts and moving to a real Continuous Integration and Deployment context.

  2. Familiarity with testing techniques and tools: the most important part and also the first step I suggest before being able to start doing TBD is to have a completely automated pipeline; pipelines typically do three main things: build the application, execute automated tests and static analysis to see if something is broken, and then release it to the environment. In TBD, we want that the test suite is so reliable that if tests are green we consider the code deployable, without additional manual tests. To reach this, we need to master testing techniques and tools.

  3. Adaptability and flexibility: being adaptable and flexible is always useful in the software development world, especially when we learn something new and even more when it’s something disruptive like TDD or, in this case, Trunk-Based Development; TBD involves a different way of thinking about and approaching software development, and being open to new approaches and willing to try new things is a necessary condition to achieve mastery in this kind of situations.

Careful!

The fact that we commit straight to master doesn’t necessarily mean we immediately deploy in production. A good approach that is typically used is to configure the pipeline to deploy on a test/staging environment when the code is pushed on the master/trunk branch, then release on production when the master branch is tagged.

Go Deeper

Here are some resources you can check if you want to go deeper and learn more about Trunk-Based Development and Continuous Integration.

Books

Online

Did you enjoy this post?

Express your appreciations!

Join our Telegram channel and leave a comment!Support Learn Agile Practices

Also, if you liked this post, you will likely enjoy the other free content we offer! Discover it here: