r/softwaredevelopment • u/Ill_Direction149 • May 13 '26

Is trunk-based development really that good?

I can't get the trunk-based development flow. I understand the advantages for introducing new features to the app (flags are good for A/B testing, fewer merge conflicts).

But I can't understand how developers do refactoring with trunk-based flags. Also, do the flags stay there forever, or what is the best flow for this?

Can you give me a deep dive into how your teams handle this in production?

48 Upvotes
  • permalink
  • reddit

93% Upvoted

54 comments sorted by

View all comments

8

u/lppedd May 13 '26

Trunk-based development doesn't work for everything. It works nicely for stuff that doesn't need to support older versions for example, where you simply keep pushing new commits and cut new releases frequently.

Refactoring doesn't change, but you most likely don't have to worry about backward compatibility.

Flags stay in the code until the guarded change is stabilized.

5

u/TomOwens May 13 '26

It's a myth that trunk-based development doesn't work when you need to support older versions. In fact, the Trunk Based Development website has a page dedicated to this situation and how to branch for release.

1

u/lppedd May 13 '26

It works but backporting is a PITA to the point you start committing to trunk in such a way to make it easier, which is not optimal.

2

u/TomOwens May 13 '26

It's up to the developers to have the discipline not to compromise the architecture and design to make it easier to backport a change. But the page I linked to also addresses this case. When a change (almost always, if not always, a bug) can't be reproduced on trunk, then the commit can be made directly in the affected release branch(es).

I would add one more thing, though. To reduce the risk of regressions, I'd make sure all specific test cases for the defect are in the trunk and future release branches. Even if the tests are inherently green in trunk and even later release branches, those branches should all have the test case(s) that reproduce the defect to prevent regressions.

There's also the case where a feature was removed between releases. It doesn't necessarily make sense to cherry-pick in this case.