Feature Flags (also known as Feature Bits/Toggles/Flipping/Controls) are an engineering practice that can be used to change your software's functionality without changing and re-deploying your code.

In software, a flag is "one or more bits used to store binary values." So it's a Boolean that can either be true or false. A flag can be checked with an if statement. A feature in software is a bit of functionality that delivers some kind of value.

In it's simplest form a feature flag (or toggle) is just an if statement surrounding a bit of functionality in your software.

Feature Toggles are a foundational engineering practice and provide a great way to manage the behaviour of the product in order to perform experiments or safeguard performance when releasing fresh new features.

There are many ways feature flags are used:

• Canary Releases.
• Dark Launches.
• A/B Testing, and running experiments.
• Multivari Testing
• Turning things off with a kill switch.
• Migrations or upgrades to a service.
• Trunk Based Development and Continuous Deployment. Developers use feature flags to avoid long lived branches. Using a feature flag for functionality in development allows a developer to merge their code daily into the main branch.

Here is a simple example using pseudo-code (taken from the Rollout Guide to Feature Flags):

if(configFile["IsHoliday"] == true) {
  writeGreetingMessage("Happy holidays!");
}

Our code checks a configuration file, outside of the main program source code, to get the isHoliday variable and calls a function writeGreetingMessage() with the message Happy holidays! when the Boolean isHoliday is true in the configuration file.

The important thing about this example is that we are able to change the functionality of our software without changing and re-deploying our code, we can simply update our configuration file during runtime. Now every time we want to display the message Happy holidays! we can update our configuration file on the fly.

Effectively feature flags allow us to separate deployment of our code from feature deployment. In order to do this we might use a configuration file, a UI at runtime or dynamically per-request based on the current context (a specific user or organisation etc).

In Martin Fowler's article on Feature Flags two major dimensions are identified to categorise feature flags: how long the feature flag will live and how dynamic the toggling decision must be. The following four broad categories of feature flags are identified by Martin Fowler:

• Release Flags allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
• Experiment Flags are used to perform multivariate or A/B testing. Each user of the system is placed into a cohort and at runtime the user will be sent down one codepath or another.
• Ops Flags are used to control operational aspects of our system's behaviour. We might introduce an Ops Flag when rolling out a new feature which has unclear performance implications so that system operators can disable or degrade that feature quickly in production if needed.
• Permissioning Flags are used to change the features or product experience that certain users receive. For example we may have a set of "premium" features which we only toggle on for our paying customers. Or perhaps we have a set of "alpha" features which are only available to internal users and another set of "beta" features which are only available to internal users plus beta users.

These flag types can be summarised by the following image.

Why & How to combine it with other practices?

The Feature Toggles can greatly complement and make easier the implementation of practices like A/B Testing, Canary Release, Dark Launches in which the Feature Toggle is used to activate the “new” feature or version for a certain group/part of users. It is essential to the implementation of Design of experiments practice.