Configuration as code reference

Folder structure

The folder structure is organized to support consistent management across environments. At the top level, the main folder acts as the root directory. Inside this root, the .cloudbees/casc folder contains subfolders dedicated to various aspects of feature flag configuration. The system processes files according to this structure, validating YAML files located in the .cloudbees/casc/feature-management/flags subdirectory and creating them as flags in the system. These flags then appear in the UI for easy management.

Figure 1. Example of the CasC folder structure

While the YAML files include a type field, this field has no functional impact and is intended for informational purposes only.

View more about each of the main folders:

A. feature-management

Folder name and description
feature-management: Contains all flags and configuration-related details.

Folder name and description

feature-management: Contains all flags and configuration-related details.

B. flag-configurations

Folder name and description Example content

Folder name and description	Example content
feature-management/flag-configurations: Contains a subfolder for each environment, containing the details of the defined flag configurations.	Produces environment sub-folders. For example: Dev Production Staging Example file name: `default.score.yaml` `flag: default.score conditions: - property: propertyConditions: - operator: is-true property: isBetaUser - operator: is-true property: Loggedin value: true value: false` ▼

feature-management/flag-configurations: Contains a subfolder for each environment, containing the details of the defined flag configurations.

Produces environment sub-folders. For example:

Dev
Production
Staging

Example file name: default.score.yaml

flag: default.score
conditions:
  - property:
    propertyConditions:
    - operator: is-true
      property: isBetaUser
    - operator: is-true
      property: Loggedin
    value: true
value: false▼

Deleting an environment in the UI will delete the corresponding environment folder under feature-management and all files within it. However, deleting an environment folder directly in an SCM only deletes the flag configurations associated with that environment, and does not delete the environment itself.

C. flags

Folder name and description Example content

Folder name and description	Example content
feature-management/flags: Contains details that are consistent across environments, such as names, descriptions, labels, variations.	Example file name: `default.score.yaml` `flag: default.score description: the default score labels: - backwards-compatible-configuration` ▼

feature-management/flags: Contains details that are consistent across environments, such as names, descriptions, labels, variations.

Example file name: default.score.yaml

flag: default.score
description: the default score
labels:
  - backwards-compatible-configuration▼

D. properties

Folder name and description Example content

Folder name and description	Example content
feature-management/properties: Contains a list of the available properties that can be used in flag configurations or target group definitions.	Example file name: `properties.yaml` `apiVersion: v1 kind: flag-properties name: orgId type: String description: "orgId description"` ▼

feature-management/properties: Contains a list of the available properties that can be used in flag configurations or target group definitions.

Example file name: properties.yaml

apiVersion: v1
kind: flag-properties

name: orgId
type: String
description: "orgId description"▼

E. target-groups

Folder name and description Example content

Folder name and description	Example content
feature-management/target-groups: Contains definitions for target groups, which are consistent across environments.	Example file name: `BetaUsers.yaml` `type: target-group name: BetaUsers conditions: - operator: is-true property: isBetaUser - operator: is-true property: isLoggedin` ▼

feature-management/target-groups: Contains definitions for target groups, which are consistent across environments.

Example file name: BetaUsers.yaml

type: target-group
name: BetaUsers
conditions:
  - operator: is-true
    property: isBetaUser
  - operator: is-true
    property: isLoggedin▼

inheritance.yaml [Deprecated]

Folder name and description
inheritance.yaml: [Deprecated] This file was previously used to reference inherited entities from parent organizations. Inheritance is no longer needed - feature management entities are now independently scoped to the organization in which they are created.

Folder name and description

inheritance.yaml: [Deprecated] This file was previously used to reference inherited entities from parent organizations. Inheritance is no longer needed - feature management entities are now independently scoped to the organization in which they are created.

Root configuration schema

The flag value is controlled at runtime for all CasC flags.

Select the link below to show the inputs for the base, or root, schema for CasC in CloudBees Unify Feature management.

View details about the root input schema:

Table 1. Input details
Input name	Data type	Required?	Description
`version`	Semver	No	The CloudBees Unify API version. The default value is `1.0.0`.
`type`	String	Yes	For a flag, must specify `flags`. For a target group, must specify `target-group`.
`flag`	String	Yes	The name of the flag controlled by this flags definition.
`name`	String	No	The flag name.
`description`	String	No	The flag description.
`availableValues`	String, Boolean	No	The available values for the flag.
`enabled`	Boolean	No	Whether the flags status is enabled.
`labels`	String	No	The flag labels.
`stickinessProperty`	String	No	The stickiness property that controls percentage-based flag evaluation. The default value is `distinct_id`.
`platforms`	String	No	The code language or framework name. For example, `Python` or `Gradle`.
`conditions`	Array	No	An array of conditions having a logical `AND` relationship between them. Refer to Multiple conditions to learn more.
`value`	String	No	The value when no condition is met. The default value is `false` for Boolean flags, and `null` for enum flags.

Conditional configuration

A condition is an if/else statement. An array of conditions is processed in order, with a logic gate between each condition statement. There are the following four types of condition statements: dependency, group, property, and version.

View details about the four types of condition statements:

dependency: Expresses flag dependencies by indicating a flag name and expected value.

Table 2. Dependency nested inputs
Input name	Data type	Required for a dependency?	Description
`flag`	String	Yes	The flag name.
`value`	String Boolean	Yes	The expected flag value.

group: Lists target groups and the operator that indicates the relationship between them.

Table 3. Target group nested inputs
Input name	Data type	Required for a target group?	Description
`name`	Array / String	Yes	The list of target group names.
`operator`	Logical operator	Yes	The type of relationship between groups: `and\|or\|not`.

property: A single property that includes an operator and an operand; multiple conditions are possible.

Table 4. Single property nested inputs
Input name	Data type	Required for a property?	Description
`name`	String	Yes	The custom property name.
`operator`	Logical comparison operator	No	The first operand of the condition; accepts `is-undefined\|is-true\|is-false\|in-array\|eq\|ne\|gte\|gt\|lt\|lte\|regex\|semver-ne\|semver-eq\|semver-gte\|semver-gt\|semver-lt\|semver-lte` operators.
`operand`	String Number	Required only if `operator` specifies `is-undefined\|is-true\|is-false`.	The second operand of the condition.

version: Compares the version value of one to another.

Table 5. Version nested inputs
Input name	Data type	Required for a property?	Description
`semver`	Semver	Yes	The version to compare to.
`operator`	Logical comparison operator	No	The operator to compare to the `semver` version; accepts `semver-eq\|semver-ne\|semver-gte\|semver-gt\|semver-lt\|semver-lte` operators.

Specify the value when the condition is met with the value input.

Multiple conditions

Create multiple conditions using and|or logical operators between any of the above types of condition statements. Specify the operator in acrossTypesLogicGate.

For example, if a dependency is met and a user matches a target group, then a Boolean flag serves true. Otherwise, the flag is false (default).

Split release schema

Specify a percentage of web traffic to split across different flag values.

Table 6. Input details
Input name	Data type	Required?	Description
`percentage`	Number	Yes	The percentage for which the flag value is true.
`value`	Boolean\|String\|Number	Yes	The flag value delivered to the `percentage` of app users.

Scheduled value schema

Enable/disable a feature for a percentage of app users at a specified date and time. The flag value is either true or false.

Table 7. Input details
Input name	Data type	Required?	Description
`date`	Date	Yes	The date and time when the flag value is switched to the specified `value`.
`percentage`	Number	Yes	The percentage of users served the flag `value`.
`value`	Boolean	Yes	The flag value delivered to the `percentage` of app users.

Configuration as code reference

Folder structure

Root configuration schema

Conditional configuration

Multiple conditions

Split release schema

Scheduled value schema

Related topics