Ask HN: Does trunk based development work?

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

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.

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.