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)<p>However I’ve only seen it once and it was a shit show honestly.<p>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).<p>How’s your system stability? How thorough are your tests, is is worth doing?<p>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.
Trunk-based development works.<p>In fact I suspect most people working in SaaS are doing some kind of Trunk-based development - some unknowingly.<p>There are tons of misconceptions about _what it is_. I wrote a blog post on common misconceptions about trunk-based development here: <a href="https://bucket.co/blog/trunk-based-development-crock-of-shit" rel="nofollow">https://bucket.co/blog/trunk-based-development-crock-of-shit</a>
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.<p>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.<p>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.<p>The faster you can deploy, the faster you can deploy fixes. Also note, you can always roll back bad deployment.<p>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.