Overview
Feature flags are a core concept of Unleash. Feature flags allow you to release, test, and manage features and functionality across your application without changing the source code.
Feature flags exist within a project and have distinct configurations and activation strategies for each of the project's active environments. Activation strategies determine if a feature flag is enabled in a specififc environment.
Feature flags have the following properties:
- Name: URL-friendly string between 1 and 100 characters; must be unique per instance.
- Type: The feature flag's type;
Releaseby default. - Project: The project that contains the feature flag.
- Description: A description of the feature flag's purpose; optional.
- Impression data: Whether impression data is enabled for the flag; disabled by feault.
Environments and activation strategies
Feature flags have different activation strategies for each environment to allow you manage feature rollouts per environment.
To activate a feature within an environment, assign it at least one activation strategy. If you don't specify a strategy, the deafault of gradual rollout to 100% is used.
Activation strategies determine if a feature flag activates for a specific Unleash context, such as a particular user or segment. When multiple strategies are in place, the flag will activate if any one of them evaluates to true.
Stategy variants
You can enhance your feature flags with strategy variants. Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see. For example, you might use variants to run an A/B testing experiment.
Variants are defined by a name, weight, which determines the likelihood of each variant being shown. Stickiness ensures that users consisteny see the same variant based on predefined parameters. Variants also support payloads like JSON, CSV, or strings to provide additional context to users.
Feature flag types
Version: 3.5+
Feature flags have a type to indicate their use case and help you manage and sort your flags. A feature flag's type determines its expected lifetime, and it's visual apprearance in the Admin UI.
The following are the list of feature flag types:
| Feature flag type | Used to | Expected lifetime |
|---|---|---|
| Release | Manage the deployment of new or incomplete features. | 40 days |
| Experiment | Perform multivariate or A/B testing. | 40 days |
| Operational | Transition between technical implementations with minimal risk. | 7 days |
| Kill switch | Gracefully degrade system functionality. | Permanent |
| Permission | CControl feature access based on user roles or entitlements. | Permanent |
To learn more, visit Types of feature flags.
Expected lifetimes
A feature flag's expected lifetime is an indicator of how long Unleash expects flags of that type to be around. Some feature flags are meant to live for a few weeks as you work on new functionality, while others stick around for much longer. As a part of good code hygiene, you should clean up your feature flags when they have served their purpose. This is further explored in the document on technical debt.
Each feature flag type in Unleash has an assigned expected lifetime, after which the system will consider this feature potentially stale. The reasoning behind each type's expected lifetime is detailed in this blog post on best practices for feature flag lifetimes.
With Admin access, you can configure the lifetime of a feature flag type. In the Admin UI, go to Configure > Feature flag types and edit the flag type you'd like to change.
Deprecating feature flags
You can mark feature flags as stale. This is a way to deprecate a feature flag without removing the active configuration for connected applications. Use this to signal that you should stop using the feature in your applications. Stale flags will show as stale in the "technical debt dashboard".
When you mark a flag as stale, Unleash will emit an event. You can use an integration to integrate this with your systems, for instance to post a message in a Slack channel.
Additionally, with some extra work, you can also use the stale property to:
- Inform developers that a flag is stale while they're developing.
- Break a project build if the code contains stale feature flags.
- Send automatic PRs to remove usage of flags that have served their purpose.