Feature Flag Glossary
One of the great things about getting to talk to people who use feature flags is learning how they use them and what they call them. Some teams call them toggles, switches, gates, or flippers. We’ve noticed that often how teams use feature flags is determined by the technology they have. And we’ve heard some great concepts around how teams are using feature flags. In one case, we learned about an “Albatross launch”. In this case, the team is using feature flags in the reverse of how we usually think about using them–to hide something that used to be public.
This isn’t an exhaustive list–no glossary or dictionary is–but I hope it’s enough to give you some insight into the phrasing that we’ve heard recently, and some ideas to get you started. If you have any additions or questions, please let us know!
Segmenting a group of users so that some get one version of a feature and others get a different version. The metrics are then compared to determine which version users prefer. A/B testing can involve more than two choices.
Limiting who can see or change a feature. This is often used with tiering or user accounts to keep end-users from changing things in ways that would cause problems.
A style of software development where specifications and requirements are agreed upon for each work cycle or “sprint”. Agile development emphasizes delivering small features and incremental improvements as quickly as possible.
Launching an upgrade for all but a few customers, who need to stay on an earlier version for compatibility reasons.
A variable that is associated with a user that can be used for targeting and segmenting. This can be a unique value or a standardized value (e.g. a unique user ID or a geo-location).
Users who have opted in to help test features before they are turned on for the general public.
Launching an upgrade for a few customers (commonly 1-10%) to test it in production and at scale without turning it on for all users simultaneously. Canary launches can detect problems with both scaling and features.
Offering new features to a selected group of customers before wider release. This is related to beta testing, but implies the feature is more mature and desirable.
“A bit on a chip that can be used to disable one of the features of the chip if it proves faulty or negatively impacts performance.” (Read more.)
An automatic script to trigger a kill switch or a throttle (for load shedding, etc.) in the event of traffic exceeding safe parameters.
Generating a working deployment many times a day, with no active human intervention. Most organizations don’t actually push builds continuously, but they are capable of doing so.
The act of putting code into an environment. Sometimes this is coupled with the act of releasing a feature to users–with feature flags these events can be separated.
A feature flag designed to kill third-party access to a system. This might be triggered if the third-party service is malfunctioning, so the core system stays protected.
A wrapper around a section of code that will allow you to change behavior (e.g. turn on/off or change behavior to a 3rd, 4th, etc variant) without redeploying.
The practice of deploying, releasing, and targeting features to benefit the greatest number of users while keeping monetary and cognitive costs low for both developers and users.
A way to turn a feature (or group of features) wrapped in a single flag off almost instantly, without redeploying or pushing.
Turning on or making a feature public The takeoff phase of the flight of a rocket. The moment in the lifespan of a startup in which a company goes from stealth mode to offering (at least) a beta product.
When a feature flag is non boolean and there are multiple variations available. For example: having an operational flag that varies based on region. Variation 1 = NA, Variation 2 = EU, Variation 3 = Aus.
A flag designed to stay in place and allow the operations team to turn off, throttle, or otherwise alter the flow of traffic to a feature.
Using percentages to determine how many people get a new feature. Many organizations use this to gradually release a feature to detect any problems and to avoid stresses on their infrastructure that might come from turning a feature on everywhere at once.
Using feature flags to determine who may access or experience a feature. Often these are tied to access control lists to control things like pricing tiers or other premium product offerings.
Personally Identifiable Information (PII)
Protected information that might uniquely identify a user. Obvious examples are social security numbers, medical data, biometric data, names, addresses, and birthdates. Other less obvious examples include behavioral fingerprints.
Elements of user information that an organization would like to keep private, often this is data that is considered personally identifiable information (PII). In LaunchDarkly data that is marked as a Private Attribute can be used to define feature targeting, but is not passed back to the feature management system.
The practice of delivering elements of a product with increasingly larger parts of the audience. Progressive delivery may also be knows as rolling release or ring deployment.
Turning on, launching, or enabling a feature. This is separate from the process of deploying a feature. Often Product and/or Marketing are responsible for a release, whereas Development and Operations teams are responsible for deploying code to production.
A flag indicated to control how a feature is released. It is usually removed after full release.
Releasing new features to increasingly larger groups of people. If a new feature is only tried by 100 people, the “blast radius” if something goes wrong is relatively small. As you gain confidence in the feature, it can be automatically released to increasingly large groups. See also: Progressive Delivery.
To undo a deploy by pushing out the version that had just been replaced. Ideally, that will replace the new broken version with the older stable version.
Using a feature flag kill switch to turn off one problematic feature in a deployment without replacing the other new features.
An automatic script to trigger the necessary actions to manage scale in the event of traffic exceeding safe parameters.
A group of users. For instance a segment might be users who are over 50, users who have registered with a hotmail address, or users on mobile devices.
An if statement that defines who should see a feature or variant.
Test in Production (TIP)
The practice of deploying new features to a production server and then turning them on only for a small group of people, typically internal developers. Because it is so difficult to replicate a distributed cloud architecture in a staging environment, it’s crucial to test new features in production, but it is not necessary or desirable to show those tests to all users. Feature flags can restrict tests in production to internal users, a defined subset of beta users, a percentage of users, or some other group that you define.
A piece of code designed to alert developers that the code is past the configured date and should be examined or removed.
More commonly known as a feature flag. A way to turn a feature on or off.
Allowing all developers to work in the same code, without branching. Continuous Delivery is a set of practices that ensure your code is always in a deployable state. Having short-lived branches is a key part of making this possible–when team members commit to trunk frequently, then the codebase will be in a deployable state. Many teams who operate in this way will use feature flags to keep incomplete features “off” or hidden until they are ready to turn them on for testing or release.
A style of software development where specifications and requirements are identified first and work is plotted out for the entirety of the project before it is begun. Waterfall development emphasizes understanding the whole scope of a problem and addressing it consistently.
Changing how your product is displayed to end-users so it looks like it comes from your client. This can include changing logos, fonts, colors, etc to match someone else’s brand. Used for VARs and also to make a tool feel “internal” to a customer.