Is anyone using trunk-based development at work with success? Coming from a world of GitFlow and it's associated problems, I like the idea of constant issue-granular merges behind feature flags but having trouble finding someone who is using this in practice.

My team has recently started using this, but I can say that feature flags are a huge pain and make the codebase an absolute mess. We prefer working on separate feature branches, but starting moving toward feature flags when we had to do several roll-backs of features at the 11th-hour. Gives us protection from that kind of situation, but it definitely makes it take longer to add features, harder to test, and makes it harder to do necessary refactoring. It certainly solves a problem, but it causes just as many, and I’d recommend other approaches if you can

@Casey Brooks can you elaborate what kind of feature flags setup you use and what pain points you have? I’m planning on introducing them to our codebase and moving to trunk-based development as well. My idea was that provided most feature flags need to be checked at one place only, they’d be relatively easy to manage. I did consider difficulties testing (testing of both branches will be quite annoying) but I’m curious about some specifics

We have a configuration API that returns the flags to enable/disable. Our situation woudln’t be any different if we used Firebase Remote Config or something else. Having a single flag at the injection setup (dynamically providing a Module containing all definitions for that Feature), or features that are completely isolated from the rest of the app, then it might not be so bad. But the reality is that it’s actually pretty difficult to accomplish that. You’ll be tempted to share code among the different versions of a single feature, or else copy a bunch of code into an isolated feature, and neither one is ideal. If you start your app expecting to use feature flags you could probably get a good pattern going and make it work decently well. But if you introduce them later (like my team did), then you’re likely going to have multiple places throughout your app where you are going to need to check that flag. Things like multiple entry-points to a screen that lives behind a flag, portions of screens that contain data coming from behind that flag, etc., can all become pretty messy. Not to mention that some Features may contain methods that need to be exposed in its common interfaces that other versions of the feature don’t use. This is what you expect it to look like: https://tinyurl.com/uoad5fd This is more likely how it will play out: https://tinyurl.com/upues87

Thanks, I totally see how ff look great on paper but are tougher to execute well 😕

GitFlow has been my bff for a while, I think feature flagging makes it work pretty well

@Cody Engel the whole point of https://trunkbaseddevelopment.com is that you don't have feature branches like in GitFlow. Its not just a few flags for A/B testing but quite a different approach to development.

Ah I misread, none the less, feature branches on my teams usually stick around for about 3 days at most before merging to develop and then develop is merged to master every two weeks. Feature flags allow for those “feature branches” to be incomplete and still synced with develop.

Square has been using trunk based for years, w/hundreds of developers. Can’t imagine any other way.

Any signature blog posts on specifies? 😋

Manual testing is on whatever flags are in the release config.

@Ray Ryan I didn't know! That is awesome. Does square mostly use it on the frontend (feature flags on frontend seem really "easy" to implement), but I'm doing a bit of server dev and it seems like a completely different beast there. Not sure how we would do it there since a lot of changes require db changes, etc.

It also worth noting to say, that FF is just a first piece of the puzzle. IIRIC, it only works when all 4 metrics are respected: 1. Lead time for changes 2. Deployment frequency 3. Time to restore service 4. Change failure rate For example, trunk based development increases the lead time for changes (1) and deployment frequency (2) but also because failures are expected now, the whole pipeline should be super fast in order to have a short time to restore (3). Also, there will be little time for the manual QA in this setup, so automation becomes even more important, to keep the change failure rate low (4). You can't make an omelette without breaking eggs, by picking just one metric and pushing straight to master because hey, now it's allowed (!) it's a good way to shoot yourself in the foot.

I’m strictly a mobile (Android) dev. I don’t know our server practices very well, but I’d be surprised if long-lived feature branches are common.

I'm all for automation but I don't see how trunk based dev means lilmited manual QA time. You're trading "should I merge this?" to "should I turn the feature flag on for this". Either one can be gated by as much QA as you see fit

supposedly manual QA is simply too slow for

elite performers

😒imple_smile: . According to the DORA Report (people behind all this trunk based development movement):

Elite performers have a deployment frequency of multiple times per day and Low performers have a deployment frequency that is between 1 week and 1 month.

I guess in order to click, it supposed to come in a package. If you don't need high deployment frequency and QA time is acceptable than maybe why bother at all, good ol' GitFlow will serve you well. Of course you can have something in the middle but I think there is truth to the reasoning they provide.

Oh God 🤦‍♂️

com'on mate, don't want to be an eLiTe PerFoRmEr? Just fire QA and start pushing to master! 😄

Whatever, you asked and I answered.