For example, you're developing a new version of the checkout page for your company from scratch (it can be a store selling physical goods, or a subscription service, or anything that requires payment). It means that for a while it will not have feature parity with your existing checkout page.
So first you implement feature parity with, say, German payment options (credit cards and Sofort). Then you set up a feature flag saying "for 5% of German customers display the new checkout", and monitor it. Then you bump it up to 10%, then to 50%.
Meanwhile you're working on accepting payments via Swish in the new checkout in Sweden. Once it's ready, you add a feature flag saying "for 5% Swedish customers display the new checkout" (and in parallel, you're probably already displaying the new checkout to 50% German customers).
And so on.
In their core feature flags are not really more than a glorified if statement, but:
- you want to view them, and handle them in a single place so that you can adjust the various parameters or quickly shut down a feature if it misbehaves
- this single place has to be scalable enough that it survives an influx of customers potentially triggering dozens of feature flags across your software
Hopefully that helps!
I'll happily accept a "no you're crazy".
Roll out feature to test client, slowly roll out feature to each client.
Something to wrong? It’s incredibly fast to update the flags.
For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back.
Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature).
Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment.
Like anything else in software, feature flagging can incur technical debt if not properly maintained.