Of Death and Dying: A Journey to Trunk Based Development

Matthias Huttar tells the story of Nora and her Dionysus team. They're brave enough to try out trunk based development to address some of the issues they have with delivering quality fast. This talk is an entertaining story - in the spirit of the Phoenix Project - about a team that moves from Github flow to head based development. It covers the theory of the process from a technical, but also from a cultural stand point.

The global dev community meets at WeAreDevelopers, an event dubbed by many as the “Woodstock of Developers”. The WeAreDevelopers World Congress 2018 brought together 8,000 techies from 70 countries for 72-hours of pure dev-fun.

Visit the largest developer playground in Europe!

#WeAreDevs

©2018, WeAreDevelopers

[jakobfrei]

I always hear "drunk based development" and I'm like "this sounds like a jolly good idea"

[kristupasantanavicius]

At its core, trunk based development is about getting rid of the mindset that only "finished" and "fully working" code should be comitted into master. This is never the case. You don't know if your code is working until you release it to the hands of your users. The mindset that this model offers instead is that each commit must NOT be a breaking change. The key is to be making small atomic changes, which don't break CI and your functionality at runtime.
Trunk based development doesn't have to mean everybody pushing to master without any code reviews. What it means is that instead of making multiple small commits into your feature branch, you make pull requests for those same commits to master instead. This requires to break down your work into smaller increments, each of which is slowly working towards a completed feature.
Chromium (Google Chrome) have always been using trunk development, yet they still have extensive code reviews. They also have rigorous tests running on each pull request before they can be merged into master. This ensures that changes don't break anything in master. However, this approach requires a huge investment in infrastructure. Even a small number of people would be generating a lot of pull requests to master. A simple CI setup wouldn't suffice. You would need a network of bots to distribute the load.

[danielgilleland]

For the TLDW - Consider Trunk-based development if you a) favor speed over safety and b) have a high level of trust among all developers/contributors.


Generally speaking, if there's question about the trust in skill/competence in the contributors on your project/repo, then you automatically introduce risk and will need to likely favor safety over speed. In those cases, use a Git Flow/Pull-Request approach.


Note that these do NOT have be exclusive! You can have a "core team" of developers among whom you have high trust and can work so as to optimize speed, and you use Trunk-based development for that team. Other contributors can be put on a pull-request/Git Flow contribution model.

[HelmutGranda]

Fastest way to spread germs at a conference? Let's play a game of High-Five before the talk.

Just take the freaking commit off from the master branch and git push -f, guys. You're welcome.

[tomstorygo]

Love the stories, still, 17 minutes in im still waiting for the point - does it really need that much explanation?