When I hit the road and chat with people at shows and meetups, I’ll often ask, “Do you use feature flags?” More often than not, the answer is “Yes.” I used to think this meant feature flags had achieved near-universal adoption. Then I started asking follow-up questions and discovered a confusion we need to clear up.
I made a 1.5 minute video on this. Jump on into that, or read on in this blog.
It turns, out, some folks hear “flag” and think I’m referring to a compile-time flag that controls what gets built, a command-line flag that turns on a feature when a server boots, or a flag in a server configuration file. Those are all flags and they all lead to conditionally including or executing code but they are all global and fairly static: they impact every user that passes through that piece of software until it’s rebuilt, restarted or reconfigured.
“What if I could make a dynamic decision in my code (live) which way I’m going to send a user, without having to push new code, without having to change a config file, etc and for it to be a user by user, session by session decision?”
Feature flags (or feature toggles as they are sometimes called) refer to a more specific thing: dynamic control of code execution on a user-by-user and session-by-session basis.
In the graphic below, you can see users coming through the code and then there is a traffic cop:
That traffic cop is the feature flag.
In this case, 10% of the population is being sent to a new feature (that’s that blue box you see up top). The rest are being sent around that feature. They are not getting the feature. This is an example of a gradual rollout based on percentages. Other options are to roll out to internal users, beta testers, some percentage of free-tier users, folks who have opted in to get early updates or any other mix of attributes and random assignment within a target population.
With a feature flag, you put the flag in your code as a function call to your feature flagging service and once you’ve done that you control who goes where dynamically using rules that are edited externally in that service. Deployed code isn’t necessarily released, and released code can be shut off without a rollback or new deployment. That’s the first thing to notice if this coding strategy is new to you: feature flags separate deployment from release.
Using the feature flag design pattern unlocks a lot of power for you in terms of being able to gradually roll out individual subsets of your code (without the need for canary releasing to separate servers and routing traffic to them) and to conduct experiments. The idea in both cases is to send some people one way and some another and then observe the differences between them.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Great teams don’t run experiments to prove they are right; they run them to answer questions. Guard against wishful thinking and hidden biases with this shortlist of core principles for productive online controlled experiments. (Video, transcript and screenshots from talk given at Pinterest HQ on September 13, 2019)
At Split we believe in the power of metrics, and are always striving to improve the ways we help our users make more data-driven product decisions. In this previous post we talked about the importance of understanding the impact of a new feature release via key and guardrail metrics. With…
Find faulty features before your customers do One of the most common reasons, our customers tell us, for moving towards feature flags is risk mitigation: the need to make sure releases don’t cause errors for users. Given how frequently organizations are now deploying features, the ability to limit the blast…