HACKER Q&A
📣 mightymosquito

Does trunk based development work?


Ok so here’s the thing, the more I read up stuff on making a team more effective, the more I see benefits of trunk based development(continuous deployment, faster feedback times etc)

However I’ve only seen it once and it was a shit show honestly.

I’d like to understand if anyone here is using trunk based development on their prod system, I.e someone does a small patch, writes some code and deploys it prod directly(maybe behind a feature flag).

How’s your system stability? How thorough are your tests, is is worth doing?

Why am I pursing this: My team unfortunately has VERY long drawn out release cycles and too many manual checkpoints(from release meetings to figuring out what should be release and what shouldn’t be) and its becoming a big problem.

  👤 roncohen Accepted Answer ✓
Trunk-based development works.

In fact I suspect most people working in SaaS are doing some kind of Trunk-based development - some unknowingly.

There are tons of misconceptions about _what it is_. I wrote a blog post on common misconceptions about trunk-based development here: https://bucket.co/blog/trunk-based-development-crock-of-shit

👤 gregjor
Like so many things, it depends. You have to consider risk, to the data, to the user experience, to the other work going on. Changing some text or a button, adding a new report, sure, push to master and deploy. Low risk. Other kinds of changes might corrupt the database, confuse users, expose the application to a security vulnerability, or bring the business to a halt.

As another commenter said you can roll back a bad deployment, but that only matters if the bad deployment didn’t break things. You can pull a knife out of your leg but that doesn’t roll back the damage.

Thinking in absolutes, calling a cautious workflow “cancer,” doesn’t help developers make good decisions. For a change that might cause significant or irreparable damage I want a feature branch, a pull request, and reviews.

👤 coolguy4
Yes, it works. The "git flow" blogpost is cancer.

The faster you can deploy, the faster you can deploy fixes. Also note, you can always roll back bad deployment.

But, using a trunk branch (eg master, main, whatever you want to call it), doesn't mean you can't support a variety of release schedules. You primarily just feature flag the elements that aren't scheduled for release.