Trunk-based development

When it comes to software delivery speed and quality, trunk-based development is the way to go.

It took me a while to realize this myself. I used feature branches with pull-request as the main way of working (writeup of an experience of using pull request), so well aware of the advantages and disadvantages. But switching to Trunk based development felt very counterintuitive to me. For sure, the build would be broken all the time, and the quality would be horrible, especially with a larger group of people? Then I started reading research on Trunk based development that claimed it to be one of the key practices for high performance in technology organization ¹ and did hear from experiences. So I decided to give it a try.

The results are astonishing. Trunk based development (combined with pairing or mob programming) is a lot faster, is better for the team spirit, and delivers high-quality software.

Helping you on your way

There are many articles out there trunk-based development. But in my journey, I noticed struggling to find a good set of references that helped me along the way. So I created this (heavily curated) list of articles to get you started, focussing on the following subjects.

• Overview video
• Why?
• Working on larger pieces of functionality
• Ensuring quality

Feel free to contact me through twitter if you have a fantastic reference you feel is lacking, or if you identify another blocker to get started and lack a reference to help you.

Overview videos

Thierry de Pauw does a superior job giving a good overview in 45 minutes of why trunk-based development is important, what techniques to use to make it work, and answering typical objections. If you start with anything, start with this one.

The associated slides can be downloaded from speaker deck, and there is an associated blog series On the Evilness of Feature Branching.

Another introduction video by Dave Farley also does an excellent job to explain Continuous integration vs Feature Branch Workflow.

Why trunk-based development

This is my go to list for why trunk-based development is so important. Some are backed by research, some focus on explaining why through argumentation.

• Research
  • State of DevOps report 2016 (pages 30 and 31)
  • Accelerate (Chapter 4: Technical practices). Actually, I encourage you to read the whole book. But chapter 4 contains the most focussed part on trunk based development.
• Argumentation:
  • https://mrdevops.io/trunk-based-development-8376fe577c11
  • https://techbeacon.com/devops/how-trunk-based-delivery-key-faster-more-reliable-software
  • https://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/
  • https://martinfowler.com/bliki/FeatureBranch.html
  • https://blog.newrelic.com/culture/long-running-branches-considered-harmful/
  • https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

Working on larger pieces of functionality

One of the typical objections against trunk-based development is that one cannot release half-finished parts of the code to customers, so unfitted parts must be on branches. The key learning in this area is that there are other mechanisms to achieve the same goal, with some key examples listed below.

• Branch by abstraction
  • https://www.branchbyabstraction.com/
  • https://paulhammant.com/blog/branch_by_abstraction.html
  • https://www.martinfowler.com/bliki/BranchByAbstraction.html
  • https://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
• Feature flags
  • https://www.martinfowler.com/articles/feature-toggles.html
  • https://www.infoq.com/articles/feature-flags-gone-wrong/
  • https://featureflags.io/
• Strangulation pattern
  • https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
  • https://martinfowler.com/bliki/StranglerFigApplication.html

If you did not find yet what you are looking for, the website dedicated to trunk-based development might contain what you are looking for: https://trunkbaseddevelopment.com/.

Ensuring quality

Another typical example is that switching to trunk-based development will deteriorate quality because there is no peer review process and that there will be less sharing and learning. Again, the clue is to understand the peer reviews can be done in another way.

• Pairing
  • https://tuple.app/pair-programming-guide/the-case-for-pair-programming
  • https://www.wikihow.com/Pair-Program
• MOB programming
  • https://www.youtube.com/watch?v=SHOVVnRB4h0
  • https://mobprogramming.org/mob-programming-basics/
  • https://thecuriousdeveloper.com/2013/09/15/get-a-good-start-with-mob-programming/
• Mob code review on mainline
  • https://grrava.blogspot.com/2017/10/review-of-our-code-review-process.html

See also

• Architectures that enable shared code ownership and collaboration across many teams.
• A zero bug policy - how to get there? (2/n)
• A zero bug policy (1/n)
• Code katas for selecting technical talent
• Organizing architectural katas