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.
Last week, I spoke about the foundational idea of decoupling deployment from release. This week, let’s answer the question, “Why would I want to?” At a high level, there are really just two reasons: #1: You want to prevent code that’s still a work in progress from being exposed to users…
Recently, there was a very active twitter thread that started when John Cutler asked whether everyone knew about the idea of decoupling deploy and release: From the replies, retweets, and likes, it was pretty clear that not everyone knew about decoupling deploy from release, and how feature flags make that…
How do you know if your rollouts are going well and should be ramped up or are surfacing issues that need to be fixed before you ramp up? That’s the focus of today’s post and video.