Flags allow you to insert a point in your code where traffic can be routed (or "switched") from one path to another.
In practice, they are used to grant access to features dynamically, separately from your code deployment process. You can use flags in Airdeploy for:
- Rolling out new features
- Running experiments or testing new features
- Managing customer feature permissions
This article describes the anatomy of a flag in Airdeploy, and all the relevant terminology.
Name & Codename
Every flag in Airdeploy has a name, which is a human-readable identifier that describes what feature it controls. A unique codename is autogenerated, which is how the flag is referred to in code when using the Flagger SDK to build feature flags.
The point of a flag is to route traffic from one path to another; these paths are called variations.
When using the Flagger SDK to integrate flags into an application, each variation can be handled differently.
Every flag has a special variation that serves as a default. Traffic, by default, all flows into this variation. This variation represents the feature being "Off" and has the codename
In practice, this means developers must always handle the
off variation case.
In addition, flags have their own variations. Flags in Airdeploy are created with simply one flag variation - called
on. However, you can create multivariate flags for features that have more than one variation.
All flags have a kill switch which turns a feature "off" for everyone. It takes precedence over all other targeting rules.
Flags also have an archived status in Airdeploy. When they are no longer needed or used, a flag can be archived which makes it invisible to code (and the Flagger SDKs) but preserves a record of it. Archived flags only serve the default variation (are treated as "off").
Archiving is an alternative to deletion that preserves the state and history of the flag.