LaunchDarkly empowers teams to control the behavior of their code and their product. Many teams work on a small part of that process, but may not have an overall view of how feature flags are created, managed, and removed. This is a high-level overview and our Guides website has more information on each of the pieces.

When you create a new flag, the first question is whether it is a temporary or long-lived flag. Is this control going to be a part of your infrastructure, or is it designed to be removed?

Some temporary flag types:

• New feature rollout
• Branch by abstraction
• Testing/hypothesis
• Conversion/migration

Some permanent flag types:

• Entitlement/permissions
• Rebranding
• Infrastructure control
• Accessibility
• Support tools
• Geographic restrictions

Creating a flag

When you create a flag, you decide what kind of flag it's going to be. Is this a flag for rollouts or an infrastructure kill-switch? Is the flag defined as part of the code specification/story, or is it added as the software gets closer to release?

You create a flag in the LaunchDarkly application and use the flag key to identify the variant that the code will execute. This is a very simple example:

if enableFeature(on.click.checkout, {...}) then  
  /* show the new feature */
else  
  /* show the old feature */

Once your code is wrapped in the flag, you can control the behavior of that code by changing the flag state and the targeting rules.

Naming, tagging, and standards

We recommend setting standards for flag names and tags, just as you would for any other significant part of your code environment. For more on naming, see our best practices on setting flag identifiers. 

Targeting

Flag targeting rules are how a flag determines where code is delivered or executes. Targets are a combination of the rules that a flag is designed with and the evaluation context of their delivery. Both temporary and long-lived flags understand targeting the same way.

Users

“User” is a catch-all description for any addressable object. A user might be a person represented by an email, a server, a hash, an Active Directory group, or a container. When LaunchDarkly evaluates rules, it does so based on “user context”, which is everything that is relevant about the user and how it is defined, which may mean one or attributes.

Groups

Groups can be created in LaunchDarkly manually, or imported from an identity provider or file. Groups can also be represented by reference to an outside source of truth. 

Attributes

Attributes are metadata associated with a user or group that affects the targeting rule evaluation. Attributes are frequently configured in LaunchDarkly as a way to take advantage of data that your organization is already collecting. An attribute can be anything that you know about a user or group. Attributes are used to write rules that include and exclude users from receiving new variations.

You can learn more about how to set up rules and targeting in the Rules and Targeting Guide

Interactions/dependencies

Rules don't always operate in isolation. You can read more about this in the Flag Hierarchy Guide. When you are writing a rule, you can set it to be dependent on a prerequisite flag. The prerequisite flag must be on and evaluating to true before the dependent flag can go through its own rule list.

Temporary/short-lived flags

Temporary flags have an implicit lifespan. They are designed to be removed once you have rolled out the feature, completed the migration, or finished the user testing. If you leave temporary flags in your code base, you incur unnecessary technical debt and increase your testing complexity.

Purpose

Here are some patterns for using temporary flags:

• New feature rollout - percentage or regional rollout to check for system or acceptance problems
• Branch by abstraction - use a monorepo, and use flags to create virtual branches until the code is ready for release
• Testing/hypothesis - A/B testing, testing user acceptance
• Conversion/migration - database migrations, cloud provider transition

Removal plan

Temporary flags are meant to be removed, so it's best to have a plan for it. 

One of the patterns we recommend is writing the “final state” of the code as it will be after the flag is removed, and then using git-stash to store it without committing it. When the time comes to remove the flag, you will be able to commit the code that you wrote when it was fresh in your mind.

LaunchDarkly flags can be sorted based on their age, and whether they are fully-deployed. You can even set reminders to remove flags that are over 30 days old and fully deployed. Setting standards for removal as a team promotes conversation that can then lead to automation. When you decide to remove a flag you can use the LaunchDarkly Code References feature to identify all the places in your code that are affected by that flag.

Long-lived flags

Long-lived flags have an indefinite lifespan. We sometimes refer to them as “load-bearing flags”. These are flags that are around to support business logic or infrastructure operations and safety. 

Purpose

Here are some patterns for using long-lived flags:

• Entitlement/permissions - VIP members, paid accounts
• Rebranding - one set of code that can be branded for many different clients
• Infrastructure control - circuit breakers and kill switches for microservices and data streams
• - ensure accessibility for different kinds of needs by presenting options
• Support tools - allow support staff to change log levels or activate troubleshooting settings
• Geographic restrictions - make sure you are respecting geographical requirements such as GDPR

Removal plan

Most long-lived flags are not built to be removed quickly. Before removing a long-lived flag, turn it off and ensure that you have covered all the resulting conditions. Use the Code References feature to find all the places the flag is used and be sure that you will not be removing key functionality.

Conclusion

When you are planning a flag, it is worth your time to consider what you intend the flag to do, who it will affect, how long it should persist, and how you plan to remove it. The more people and team members you work with, the more important it will be to set standards and abide by them. A feature flag is not a shortcut, and it will not always save you work, but it increases the safety of the work you do and allows you and your organization to release quickly and safely.