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.
We’ll talk a lot more about feature flags for gradual rollouts and feature flags for product experimentation in other posts and videos.
Jump to the next episode of Safe at Any Speed: Are You Using Feature Flags for Controlled Rollouts, but Winging It for Observability?
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.