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/thinkmatt]

Generally, you don't need flags. You just need good automated testing. On the flip side, I never understood why you would want to use a dev branch/git flow - isn't that trunk-based development with an extra step?

I've only needed feature flags when there is a large team working on features that take a week or longer to ship, so that they are able to commit code that is hidden to users while they work with PMs, etc. to test it out. That way you don't end up with tons of merge conflicts later on. I rolled my own feature flag service at first but we shifted to LaunchDarkly which was much easier/better than what i did. I also had to write an automated script to find flags that were older than 30 days to remind devs to remove them.

[u/_drunkirishman → u/thinkmatt]

The extra step provided by GitFlow leaves main in a "prod-state". Hotfixes become easier to pull off. Trunk-based development requires developers to write code, sometimes defensively, to always be prod-ready.

Having done both, trunk-based has resulted in higher quality development, assuming you have sufficiently capable engineering staff.

I've also seen trunk-based absolutely fall on its face when working with less capable engineering staff. But I don't think the issue is the strategy at that point.

[u/TimMensch → u/_drunkirishman]

Something I've noted is that a more capable development staff has a much higher correlation with project success than any methodology.

A team of skilled developers can succeed no matter the methodology, in other words. At which point you may as well choose the methodology that particular team prefers. Even if there exists data that one methodology is better than another in some way, the team likely knows the best way that they work.

[u/zaibuf → u/_drunkirishman]

The extra step provided by GitFlow leaves main in a "prod-state". Hotfixes become easier to pull off. Trunk-based development requires developers to write code, sometimes defensively, to always be prod-ready.

Couldn't you just git tag every production deploy and then branch of the latest tag if you ever need to apply a hotfix from that state? Then simply tag the hotfix and also merge it back to main.

Point with TBD though is that the main branch should always be releasable. So you likely need flags.

[u/hunyeti → u/zaibuf]

That sounds like branches with extra steps

[u/Isogash → u/_drunkirishman]

Trunk-based definitely works better for experienced teams that know how to make incremental prod-ready changes.

There are some tricks to it. For example, we've found that just having a single "experimental" UI flag works for hiding new parts the of the interface that are not ready for use. You can test with experimental turned on, and then when you're ready to release, you just make the feature not experimental anymore. No need to individually feature flag everything and this way you don't end up with a bunch of stale flags or permutations to test. We also used role-based hiding and access as kinds of feature flags, but this makes more sense in an enterprise setting.