Introduction
Architecture
Onboard
Introduction
Teams
Users
Introduction
IntroductionPromote an image in Amazon ECRDownload a file from JFrog ArtifactoryMove or copy an image from JFrog ArtifactoryUpload a file to JFrog ArtifactoryStore an object on Amazon S3Retrieve an object from Amazon S3
IntroductionCreate or update a functionInvoke a function
IntroductionRun an AWS CodePipelineRun a Bamboo projectRun a Bitbucket pipelineRun a CloudBees CI jobRun a CircleCI workflowRun a GitHub Actions workflowRun a GitLab pipelineRun a Harness pipelineRun a Jenkins® jobRun a JFrog pipelineRun a TeamCity project
Check out a Git repository
IntroductionAWS credentialsECR credentialsEKS credentialsGit global credentialsOCI credentials
IntroductionRun Argo WorkflowsCopy a remote image with CraneDeploy a binary with EC2Deploy to ECSRender an ECS task definitionBuild a container image with KanikoDeploy with OctopusDeploy with SpinnakerRun Ansible Playbook
Publish evidence items
IntroductionHelm chart installHelm chart packageHelm chart publishHelm chart uninstall
IntroductionCreate a Kubernetes namespaceCreate/update a Kubernetes resourceDeploy to a Kubernetes cluster
IntroductionVerify with NewRelic
Execute remote commands via SSH
IntroductionAnchoreAquasecJFrog XraySnyk ContainerSonatype (Nexus) ContainerTrivy
IntroductionStackhawkZAP
IntroductionCheckmarxFind Security BugsGitHub Security ScannerGosecMendNexus IQSnykSonarQube bundledSonarQube
IntroductionMendSnyk
IntroductionTruffleHog ContainerTruffleHog CodeTruffleHog S3
Publish test results
CI insights for Jenkins

Learn about feature flags

2 minute read

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 (org or sub-org) is the top level of the feature management (and platform) resource structure.

How flags relate to environments

For reusability and scalability, a feature flag is shared among all environments within a top-level resource (a single org or sub-org). For example, the MySubOrg sub-org contains three environments, Dev, Stage, and Prod. A flag myFeatureFlag created in MySubOrg is thus available to all three environments.

Flag is shared among environments
Figure 1. An example feature flag called myFeatureFlag is shared among environments.

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. As in the above figure, myFeatureFlag can have unique configurations in the Dev, Stage, and Prod environments. The flag in the Dev environment is configured to expose the feature to only external beta testers, whereas the flag in the Stage environment is configured to share the feature with all users with the Firefox browser. The flag configuration status is also independently controlled in each environment.

A flag created in a specific environment of an org or sub-org is listed as Original under Source in the flag overview. The flag is also available for configuration in other environments, where its source is listed as Inherited.

Table 1. Flag characteristics that are shared/not shared across environments.
Flag characteristic Shared across environments?

Required flag settings (flag name and type)

Optional flag settings

Custom properties

Target groups

Flag configurations

SDK keys

Stickiness property

Create flags in code