Feature Flag

When working in Small Development Tasks, you realize that some tasks might not represent a complete feature. This pattern describes how to avoid exposing functionality that is not ready for consumption.

Small Steps, Each Incomplete

Working in small increments has many advantages. Before you make a new code path widely available, there may be dependencies beyond the development work. You also need a way to integrate code without exposing end users to its effects.

You can hide functionally in higher layers, which might expose a security risk and lead to a waterfall development dynamic, where a UI or API is built last.

You can hide sections of code in certain contexts, but making that possible requires added work and incurs some Technical Debt in terms of maintaining the code to hide the features.

You want a way to conditionally expose certain code paths based on whether it is safe to execute in a given environment.

Configurable Integration

** When developing a feature that will take multiple commits to complete, hide the functionality behind a feature flag.**

A Feature Flag is a conditional check in code that enables or disables a code path based on a runtime or startup configuration setting. A Feature Flag can remove the temptation to have work lingering on feature branches until it is “ready.”

A feature flag is essentially an if statement that hides functionality based on some application state value.

Feature flags can be:

• Static, requiring a restart of the application to change. For example, configurations that enable a feature on a dev or test environment
• Dynamic, this includes:
  • Role Based (a test user can see a feature while a production user can’t)
  • System-Wide: A configuration service or a database query sets the flag. This allows feature testing and incremental rollout in addition to feature hiding

The choice of approach depends on infrastructure cost and use case:

• Per Environment, enable a feature for local development or only in test environments
• Role Based enables a feature for a certain user, allowing testing to occur in various environments with the feature on or off

Since some features can spans layers in an architecture, for example, you might not want to expose an option to a UI if a backend does not support it. Allow for feature flags to have a single source of truth, either dynamic or a shared configuration file.

Treat feature flags as medium-grained, short-term entities. Too many feature flags will add to code complexity.

Remove the feature flag and the logic around it promptly.

Cautions

• Ensure that Feature Flags are removed once the work is ready to release.
• Each feature flag is a form of technical debt, as you need to:
  • Track it
  • Remember to Remove It
  • Ensure that it is accounted for in test development Feature Flags are similar to mechanisms used for user experience testing, and they could be used for this in limited circumstances, but they have distinct use cases. In particular, A/B testing usually involves dynamic configuration to switch between features that are ready to be accessed by end users.

Next Steps

• A Modular Architecture will make feature flags easier