Feature Flags

Audience

Programmers

We deploy and release independently.

For many teams, releasing their software is the same as deploying their software. They deploy a branch of their code repository into production, and everything in that branch is released. If there’s anything they don’t want to release, they store it in a separate branch.

Allies

Continuous Integration

Continuous Deployment

That doesn’t work for teams using continuous integration and deployment. Other than short-lived development branches, they have only one branch: their integration branch. There’s nowhere for them to hide unfinished work.

Feature flags, also known as feature toggles, solve this problem. They hide code programmatically, rather than using repository branches. This allows teams to deploy unfinished code without releasing it.

Feature flags can be programmed in a variety of ways. Some can be controlled at runtime, allowing people to release new features and capabilities without redeploying the software. This puts releases in the hands of business stakeholders, rather than programmers. They can even be set up to release the software in waves, or to limit releases to certain types of users.

...to continue reading, buy the book!

In this Section

1. Feature Flags
   1. Keystones
   2. Feature Flags
      1. Application configuration
      2. User configuration
      3. Secrets
   3. Prerequisites
   4. Indicators
   5. Alternatives and Experiments
   6. Further Reading