from Hacker News

Ask HN: Does trunk based development work?

by mightymosquito on 2/14/25, 3:42 AM with 3 comments

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.

  • by roncohen on 2/14/25, 7:03 AM

    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

  • by gregjor on 2/14/25, 5:13 AM

    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.

  • by coolguy4 on 2/14/25, 4:25 AM

    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.