Feature Flags 🚩
The unsung heroes of continuous delivery.
Much of modern software engineering is about shipping fast and often.
Studies like Accelerate and the State of DevOps demonstrate that teams that ship the most often are also the most likely to meet or exceed business goals.
Highest performers are twice as likely to meet or exceed their organizational performance goals — Nicole Forsgren, Jez Humble, Gene Kim
One of the key insights about shipping fast is that it doesn’t hurt stability.
Rather, it’s the opposite.
Shipping fast and often enables 1) shipping smaller changes, and 2) recovering faster from mistakes. These both reduce risk and bring stability.
When you think about it, this is both wildly counterintuitive and entirely unique to software.
When you build a bridge, building it faster doesn’t make mistakes less catastrophic, nor allows you to better recover from them.
In regular engineering, the waterfall approach pays off. In software it generally doesn’t, but it took a while to figure it out.
🚩 Continuous Delivery & Feature Flags
Following this principle, many practices became popular today to help release in production asap, while keeping the risk low. These include trunk-based development, gradual rollouts, kill switches, and more.
A surprising number of such practices are made possible by feature flags.
Feature flags are a simple idea: enable / disable features without deploying new code. This idea, however, has vast ramifications, and over the years flags turned into a swiss army knife used in the most disparate scenarios.
This article covers everything you need to know about feature flags:
📋 How do feature flags work? — principles and implementation.
🎯 What do you use them for? — the most useful scenarios.
🌟 Best practices — naming, maintenance, coupling, and more.
⚖️ Build vs buy — should you build your own system, or buy one?
🔨 Tools — the best ones to implement feature flags properly.
All the advice is based on my direct experience and on real-world case studies brought by tech leaders from the Refactoring Community (quoted in the article).
Let’s dive in!
📋 How do feature flags work
At their core, feature flags are variables stored in some system and checked in real-time to verify whether a feature should be active or not.
The simplest implementation in your code is an if / else statement:
show_feature = ff_client.get_flag("your.flag.key")
if show_feature
# application code to show the feature
else
A separate panel usually displays your active flags, their status, and allows you to add/remove them.
From here, things can get more complex, in two ways:
Rather than simple on/off values, flags can store sophisticated rules about when to display features.
Rather than passing just the name of the flag, you can pass additional information about the user or the session, that contributes to the decision.
This way, you can use feature flags to implement more granular use cases, like feature targeting based on user attributes, % shutdown/rollout, A/B tests, and more.
Let’s see the most popular, and useful, use cases 👇