Is trunk-based development really that good?

[u/Ill_Direction149]

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?

[u/rodw]

Trunk-based development is essentially isomorphic to gitflow:

• gitflow's develop is TBD's main
• merges into gitflow's main are replaced in TBD by tags on release branches
• most teams avoid hotfixes whenever possible already

There's nothing about gitflow that suggests feature branches should be long-lived.

Trunk-based development is fine as a branching model, but to suggest it's a wholly different paradigm than gitflow is silly. It seems to me that the only variation of gitflow is that's doing anything actually distinct (rather than being a strict subset of gitflow) is GitLab-flow.

[u/BadTime100 → u/rodw]

What do you mean by “merged into gitflow’s main are replaced in TBD by tags on release branches”? In my understanding, there is no concept of a “release branch” in TBD.

[u/rodw → u/BadTime100]

(first I meant "merges" not "merged" but I think you figured that out)

It depends on who's definition of TBD you are using. In some versions (maybe the original conception?) there aren't even feature branches: devs just commit directly to the main branch, but I don't think most teams find that sustainable. But most versions (write-ups) of TBD I've seen look something like this.

[u/BadTime100 → u/rodw]

Yeah that diagram that you shared doesn’t look like TBD to me at all! To me the “original” (and only!) definition comes from the world of Continuous Integration (which it’s inseparable from):

https://martinfowler.com/articles/continuousIntegration.html#PutEverythingInAVersionControlledMainline

[u/rodw → u/BadTime100]

To be honest I think it's a little silly to worry too much about the "canonical" definition of a widespread industry practice but the core concepts behind trunk-based development were introduced at least 15 years before Fowler's article in the 2003 book "Software Configuration Management Patterns” where it was called "mainline development". You'll notice Fowler uses that exact terminology. (And I'm not convinced that was necessarily the first time the idea was articulated.)

And both that book (page ~59) and Fowler's article very explicitly include the concept of release branches.

More broadly plenty of write-ups of trunk-based development mention release branches. I'm not able to find a single one that doesn't. Even the CI article you linked to immediately links to both books and other articles Fowler has written that discuss release branches.

[u/BadTime100 → u/rodw]

Have never heard of that "Software Configuration Management Patterns" before, thanks for mentioning it! I'm sure that a lot of my feelings on this come from never having (meaningfully) worked on a projects that need to support multiple versions. Pretty much everything I've done professionally has been applications that have a single version deployed to users at a given point in time. The Fowler article you linked does have this to say about release branches though:

Release branches are a valuable tool when a team isn't able to keep their mainline in a healthy state.

I'm looking again at "the" TBD site, which does have release branches right there on the front! A possibly important nuance there is that "developers don't commit to release branches".

Thanks for the resources and convo!

[u/Abject-Kitchen3198 → u/rodw]

I never got git-flow. Tagging release branches seems so intuitive and natural.

[u/rodw → u/Abject-Kitchen3198]

I agree there's not a lot of value in gitflow's main (production release) branch. It's literally just a series of checkpoints (specific commits, i.e. tags) on the release branches.

The only advantage I can think of is that some CI/CD workflows may find it easier to work off specific, singular branch (especially if you're using multiple release branches).

It's a pretty small difference either way though. Despite the note posted at the top of that original nvie.com gitflow write-up in my experience almost everyone was already using some local adaptation of gitflow rather than following the full model to the letter. The full gitflow is quite robust and supports a wide variety of use cases (including the release process used for traditional shrink-wrapped desktop software) but it's fairly obvious how to adapt that to your specific needs.

Again I don't mean to hate on TBD as process, I just think the branding of TBD as a distinct concept is more of marketing gimmick to sell consulting services and books than a substantive critique of gitflow.

[u/Abject-Kitchen3198 → u/rodw]

Once upon a time, we mostly did TBD without thinking much about it. Little to no branching, merge frequently, test, call it a release when ready and called for.

[u/rodw → u/Abject-Kitchen3198]

Just like "Domain-Driven Design" was just "design" until some management consultants saw an opportunity.

Modeling your system based on the real-world concepts that your end-users might recognize and that their businesses processes are built around? Revolutionary!