Flags

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.

Variations

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.

Default Variation

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 off.

In practice, this means developers must always handle the off variation case.

Flag Variations

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.

Kill Switch

All flags have a kill switch which turns a feature "off" for everyone. It takes precedence over all other targeting rules.

Archiving

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.