| > If you are going to activate a new feature in prod, surely you test it first? Yes, my teams test features before pushing to master regardless of branch strategy. What I meant is that the prod/master/nightly tests stil run the prod config as-is. Teams run tests, but features under toggles aren't tested using the master branch's automation tests until the feature is turned on. Exactly like how a team branch won't get tested in the nightly run until merged. The QA dept. is typically running the staging branch, which is whatever got pushed to master, but hasn't gone live yet. When I turn on a toggle, it's just like I merged a branch, so QA starts testing the new features at that point. When we want extra testing, we set the feature toggle so that QA is exposed and the public is not, then if it passes, the code goes live with the feature toggle turned off. > A team can not be responsible for testing only their own development work When we test feature toggled code, my team runs all the automation tests with my team's features turned on. Similar to how we'd run tests as if our branch was merged into master, but without pushing the merge. What we don't do is speculatively run tests with other teams' feature toggles turned on. Exactly like how you wouldn't run tests against someone else's unmerged branch. Their features are tested against ours after one of the teams turns their own toggle on, once one of the features is made public -- to at least our teams if not everyone. > The Microsoftie called it "if-statement" hell I've heard first hand accounts about their branch hell too. And it's a worse hell than I've ever seen personally. From about 10 years ago, not today, so I don't know how different it is, but someone in Research said it took a full month of merging and conflict resolution for a code merge in any given dept. to propagate to the rest of the company. If that's happening, feature toggles definitely won't fix it. There is a chance it could make things worse. I'd tend to agree if you strictly feature-flagged all commits as a complete replacement to branching, it would probably be ugly. Git is useful, and branches are a nice workflow for most dev. My criteria is to choose the one that makes sense. Feature toggles are currently better IMO for long-running feature dev or very large features, branches are better for medium sized features. Adding, merging, then removing a feature toggle during a single sprint is more overhead than it's worth. What we did in games before git was everyone pushed to master at all times (or whatever they called it in Perforce, or the lovely SourceSafe before that.) Most people did not wrap their features in toggles. We lost a ton of developer velocity due to someone checking in a bug that broke the build for everyone who pulled after that. More often than not people would hurry to try and fix their bug rather than revert, occasionally checking in further bugs. Company-wide breakage was a weekly occurrence. Those were dark days, it was ridiculous. Feature toggles were the only safety mechanism we had, which is maybe why I see them in such a positive light. I would not recommend going whole hog with feature toggles and eschewing branches. But I do recommend trying one or two and feeling out exactly how the whole process would work for you from start to finish. They are still useful in a branch environment, especially for features that would cause lots and lots of branch noise. |