I’ve worked with feature flags before… in the end, we stopped using them. They were there purely as exposure control, rather than to lock users behind a paywall; and we became pretty happy with our processes to the point that the feature flags were an overhead we weren’t reaping the benefits of.
It was initially an appeasement tool to put the business at ease when implementing new features in CD. So we could implement something turned off, and the po + 1 or 2 users would have access to it in live. But, it meant that there are lots of “if” statements in the code, and more maintenance etc.
When we switched the flag on globally, we would also then raise a ticket to remove said flag from the codebase.
As a result, it also meant we had tests to cover scenarios for both the default configuration, and also for “beta” users (all flags on).
So an overhead on testing and development. Removing them cut the build time in half
My company uses both canary builds and feature flags. Canaries are great for being able to direct a small amount of life traffic to test a new experience out if you aren’t ready to rollout, which lets you tear down faster. Feature flags work well for our products so we can control experiences for users. We also use Optimizely for some A/B testing.
Another user added
We A/B test aggressively (if only to get an idea of how much an feature has improved/hurt over baseline) and use feature flags. (Shoutout to https://github.com/unleash/unleash which in full disclosure I’m a contributor to.)
From Twitter we also have