LaunchDarkly allows your team to manage the entire lifecycle of your feature flags, from creation to cleanup. We make it easy for teams to manage feature flags and mitigate technical debt throughout the entire development process, from local to QA, staging, and production.
You can access all of your feature flags on the Dashboard. When you create a feature flag, it will appear on the Dashboard across all of your environments within a single Project. This will allow you to set environment-specific targeting and rollout rules for each flag. If you delete a flag, it will remove the flag across all of your environments.
Moreover, you can find flags easily by using the search bar to filter by flag name, tag, key, or description.
A cornerstone of effective feature flag management is the ability to know when a feature flag is active or safe to remove from your code. LaunchDarkly makes this easy with flag statuses.
Every feature flag has a status that reflects the state of a flag in each environment. For example, if the flag is listed as "Active" in your Production environment, LaunchDarkly is currently receiving requests for that flag using your Production SDK key.
Here are the colors, names, and description of the flag statuses.
This flag is new and has not been requested yet
LaunchDarkly is receiving requests for this flag
This flag has not been requested for 7 days.
All users have been receiving one variation of this flag for 7 days. You may be able to remove it from your code.
LaunchDarkly provides rich ways for you to identify each feature flag, allowing both technical and non-technical users to locate and understand flags quickly.
Every feature flag has four editable descriptors: name, description, tag(s), and maintainer. You can modify these descriptors in the Settings tab of the feature flag.
Here is a brief overview of the flag descriptors:
- A human-readable name given to each flag, like "Checkout Flow" or "Signup Page"
- A human-readable description that provides richer context for the flag's purpose, like "Manages the checkout flow for the product store."
- One or more labels to help you categorize each flag. This is especially helpful for managing flag permissions using custom roles. For example, you can tag a flag as "Marketing" and "DevOps", and then use these tags to determine who has read or write access for the flag.
- This is the individual who is primarily responsible for the flag. By default, the maintainer will be the individual who created the flag. You can assign any member of your team as the maintainer for a particular flag.
Flag keys can't be changed
In addition to the descriptors, every flag has a unique key which you set during flag creation. The key cannot be edited after the flag is created.
Each feature flag has a set of targeting and rollout rules for each environment. This means that you can create a different set of rollout rules for QA and production, allowing you to test a feature in QA before beginning a production rollout.
You can manage all of your user targeting by navigating to a feature flag via the dashboard or a direct URL. You can also manage whether your targeting rules are on or off by toggling the flag's kill switch.
The Variations tab lets you edit your feature flag's variations.
For boolean flags, you can edit each variation’s name and description. For multivariate flags, you can edit any variation’s value, name, and description. You can also add and delete variations for a multivariate flag.
When you add, edit, or delete a feature flag's variations, the change will impact all environments within the project.
After a feature flag has been created, you cannot change the type of its variations. For example, a feature flag that returns numbers cannot be edited to return strings.
When you delete a variation, custom rules that return that variation will be deleted. If a custom rule has a percentage rollout, the rollout for that variation will be set to zero.
Finally, if the default rule returns the deleted variation, it will be changed to return the off variation.