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!
ABn Testing
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.
Access Control
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.
Agile Development
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.
Albatross Launch
Launching an upgrade for all but a few customers, who need to stay on an earlier version for compatibility reasons.
Attribute
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).
Beta Testers
Users who have opted in to help test features before they are turned on for the general public.
Canary Launch
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.
Champagne Brunch
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.
Chicken Bit
“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.)
Circuit Breaker
An automatic script to trigger a kill switch or a throttle (for load shedding, etc.) in the event of traffic exceeding safe parameters.
Continuous Delivery
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.
Deploy
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.
Explosive Bolts
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.
Feature Flag
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.
Feature Management
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.
Kill switch
A way to turn a feature (or group of features) wrapped in a single flag off almost instantly, without redeploying or pushing.
Launch
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.
Multivariate Flag
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.
Operations Flag
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.
Percentage Rollout
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.
Permissions Flags
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.
Private Attribute
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.
Progressive Delivery
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.
Release
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.
Release Flag
A flag indicated to control how a feature is released. It is usually removed after full release.
Ring Deployment
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.
Roll-back
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.
Roll-forward
Using a feature flag kill switch to turn off one problematic feature in a deployment without replacing the other new features.
Safety Valve
An automatic script to trigger the necessary actions to manage scale in the event of traffic exceeding safe parameters.
Segment
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.
Targeting Rule
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.
Time Bomb
A piece of code designed to alert developers that the code is past the configured date and should be examined or removed.
Toggle
More commonly known as a feature flag. A way to turn a feature on or off.
Trunk-based Development
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.
Waterfall Development
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.
White-label
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.