Managing Feature Flags

Chapter 1. Introduction

Feature flags (aka toggles, flips, gates, or switches) are a software delivery concept that separates feature release from code deployment. In plain terms, it’s a way to deploy a piece of code in production while restricting access—through configuration—to only a subset of users. They offer a powerful way to turn code ideas into immediate outcomes without breaking anything in the meantime.

To illustrate, let’s assume that an online retailer is building a new product carousel experience for customers to easily view featured products. Here is a quick example of how it could use a flag to control access to this feature:

if (flags.isOn("product-carousel")) {
    renderProductImageCarousel();
} else {
    renderClassicProductImageExperience();
}

Here flags is an instance of a class that evaluates whether a user has access to a particular feature. The class can make this decision based on something as simple as a file, a database-backed configuration, or a distributed system with a UI.

The Past, Present, and Future of Feature Flagging

The fundamental concept behind feature flags—choosing between two different code paths based on some configuration—has probably been around almost as long as software itself.

In the 1980s, techniques like #ifdef preprocessor macros were commonly used as a way to configure code paths at build time. They were primarily used for supporting compilation to different CPU architectures, but were also commonly used as a way to enable experimental features that would not be present in a default build of the software in question.

Although these preprocessor techniques supported only the selection of code paths at build time, other commands like command-line flags and environment variables have been used for decades to support runtime feature flagging.

Continuous Delivery

Around 2010, a software development philosophy called Continuous Delivery (CD) was beginning to gain traction, centered on the idea that a code base should always be in a state that it could be deployed to production. Enterprise software teams were embracing Agile methodologies and using CD concepts to support incremental deployment into production. Companies that had been releasing software every quarter were beginning to release every two weeks, with huge efficiency gains as a result. Around the same time, startups like IMVU, Flickr, and later, Etsy had been taking this idea to its logical conclusion, deploying to production multiple times a day.

To achieve these incredibly aggressive release cadences, teams were throwing away the rulebook, abandoning concepts like long-lived release branches and moving toward trunk-based development. Feature flagging was a critical enabler for this transition. Teams working on a shared branch needed a way to keep the code base in a stable state while still making changes. They needed a way to prevent a half-finished feature going live to users in the next production deployment. Feature flags provided that capability, and became a standard part of the CD toolbox.

Experimentation

Around the same time as this revolution in software delivery practices, folks like Steve Blank and Eric Ries were sparking a parallel revolution in product management. The Lean Startup methodology brought a heavy focus on rapid iteration (powered by CD, in fact) along with a scientific approach to product management using A/B testing.

Software delivery teams quickly realized that they could use the same feature flagging techniques that they had been using for release management to power their A/B tests. Though this was a great enabler for rapid product development, it also led to some growing pains as product managers suddenly became heavy users of home-grown feature flagging systems that had been built as an internal tool for engineers. These growing pains continue today as the wave of modern product management sweeps through our industry. Later in this book, we discuss how to mitigate some of the issues that arise.

Today, feature flagging systems are seen primarily as a tool for feature management. This is evidenced by the fact that most modern feature flagging systems are oriented around which users are exposed to a given feature. Previously, the primary axis would be around which environment or cluster of servers get a given feature.

What’s Next?

For many product delivery organizations, it has become the norm for any change to be managed by feature flags. Product changes are no longer “launched” or “released”—they are incrementally rolled out. As we’ll discuss later on, this might involve an initial “champagne brunch” rollout to internal users, followed by a canary release to 5% of regular users, followed by an incremental ramp to 100%.

Rolling out a change involves monitoring the impact of that change. When feature flags were mostly the domain of engineers, the metrics being watched would be technical in nature—CPU load, request latency, database transactions per second. As feature flagging has moved into the domain of product management, the nature of these metrics has shifted toward higher-level business key performance indicators (KPIs)—active users, conversion rates, and business transactions per hour.

Today, pioneering organizations are using that feedback loop to automate the rollout (and rollback) of features. This will become more mainstream as more organizations improve their ability to tie feature releases to business metrics, closing and tightening the feedback loop that powers product delivery.