Feature flags have a wide variety of uses. You can leverage them to allow your users opt-in for early releases of new features. Further, you can use them to facilitate A/B testing, where you show different features to different groups of users in order to see which ones perform better with your actual userbase. In this article, we will discuss three of the most common use cases for feature flags.
Before feature flags, developers had only two choices. They could focus on rapid deployment and basically wind up testing in production with all the errors and problems that come with that. Or, they could focus on reliability, and perform endless testing to ensure nothing was broken before pushing to production, but have to accept slowing down deployment to only 1-2 feature releases per year. Developers of smaller applications tended towards the former, while teams of developers working on larger applications tended to favor the latter.
Now, though, thanks to the recent advent of feature flagging, you don’t have to make this difficult decision: by wrapping all new features in feature flags, you can test in production and push to production regularly without breaking your app.
So What are Feature Flags?
Feature flags are if-statements with a special condition that allows you to toggle off whatever code is inside them. They give developers the ability to instantly kill a feature that they’ve found is buggy, and re-deploy it whenever it’s ready.
Testing in Production Safely
Fundamentally, feature flagging is about testing in something as close as possible to the real production environment, while still ensuring your users always have an unbroken application. One very common way to do this is to implement dark launches: you release a new feature to production without users knowing, but otherwise utilize all parts of your infrastructure that would normally be involved in serving the feature. Dark launching is particularly useful when providing large-scale deployments. The other advantage of using feature flags for dark launches is that you are basically testing in production on a limited subset of your real userbase, but without the risks of a larger or more publicly announced formal deployment.
Let Only a Subset of Users See a Feature
You can use feature flags for either temporary or permanent userbase restrictions. Temporary uses include canary releases and phased rollouts, wherein you deploy your feature to a small percentage of your users before releasing it to everyone. In some circumstances, users opt-in to get early releases of new features. Like the canary kept in a coal mine to let the workers know whether they would suffocate from the coal dust, this small sample of your userbase will let you know whether the new feature is broken or buggy.
There are also several permanent uses for feature flags. You could use them to prevent certain users from accessing unbaked features. You could put certain features behind paywalls to tie them to subscriptions. You could use them to gain visibility into which features are still in use and retire features which are old, outdated, or conflicting with more recent ones.
Use the Power of Feature Experimentation
The final feature flags use case is probably the most important: feature experimentation. Since you now have the ability of testing in production with real users, you can implement all kinds of experimentation driven development. For example, you can use A/B testing or split testing in order to iteratively refine the optimum user experience. Further, you can measure the difference between different versions against engineering KPIs, such as page load time, performance of machine learning models, or support ticket count. And if a feature is ever breaking anything, it has an on/off switch: you can simply kill it, no harm done.
While a developer not using feature flags would test and test to try to make sure nothing was broken before pushing to production, a developer using feature flags has more flexibility. After all, if something is broken, the developer can just turn off the feature flag, fix the bugs, then re-deploy it. If you’d prefer to have the new developer’s peace of mind, you can sign up for a free trial of Split right now.