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.
Jump to the next episode of Safe at Any Speed: Are You Using Feature Flags for Controlled Rollouts, but Winging It for Observability?
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
In this tutorial you’re going to create a CoffeeBot app. The app will have a Vue.js client and a Spring Boot resource server, bootstrapped using JHipster.
At Split, we “dogfood” our own product in so many ways. Our engineering and product teams are using Split nearly every day. It’s how we make Split better.