Feature flags, the conditional statements around application feature code, are key to the CloudBees platform and can encompass many different types of logic and code.
Flags are defined as boolean, number, or string types.
You can control application feature deployment separately from code releases by toggling a flag configuration on or off.
Each flag has its own configuration, the set of conditions for which the flag is enabled or disabled.
The flag configuration can be as simple as the value true, or as complex as nested condition sets matching finely targeted groups.
To learn more, refer to Configure feature flags.
A flag has specific relationships to other elements of the platform. An organization or sub-organization is the top level of the feature management (and platform) resource structure.
How flags relate to environments
For the purposes of reusability and scalability, a given feature flag is shared among all environments within a top-level resource (a single organization or sub-organization). For example, the MySubOrg sub-organization contains two environments, QA and Prod. A flag MyExampleFlag created in MySubOrg is thus available to both QA and Prod.
However, some flag characteristics are not applied across environments. The flag configuration, the SDK key, and the stickiness property for a given flag can be different for different environments. To continue the above example, MyExampleFlag can have unique configurations in the QA and Prod environments.
| Shared/Not shared across environments | Flag characteristic |
|---|---|
Shared |
Required flag settings (flag name and type) |
Shared |
Optional flag settings |
Shared |
|
Shared |
|
Not shared |
|
Not shared |
|
Not shared |