JFrog Help Center

Our new portal is coming soon!
Documentation + Knowledge Base

JFrog Help Center - A new knowledge experience is coming your way soon!


The HelmBlueGreenRoleSwitch step flips the roles played by the Helm releases deployed by a HelmBlueGreenDeploy step.

This role switch can be used to either make a new release available to users or to roll back a previously published release.

Page Contents

Blue/Green Deployment Strategy

Blue/Green deployment is a strategy of releasing new software that uses two production environments, as identical as possible, that take turns on serving users requests while the other one is used to perform the final stage of testing.

The HelmBlueGreenDeploy step refers to those two environments as blue and green. Those environments can be either playing Idle or Live roles, depending on which environment the users' requests are being forwarded to. The environment that is currently handling user requests is considered Live while the other one is considered Idle. To rollout a new release, we first deploy it to the environment playing the Idle role. There we can validate the new version to check if it is good to become available to users. If that is true, we can flip the environment roles so the previously Idle environment becomes Live and starts to handle user requests, while the previously Live environment goes Idle. One of the main advantages of this strategy is that rolling back new releases is as easy as flipping the environments roles again.

Both blue and green environments are represented in the context of Helm as two individual releases that co-exist in the same namespace. The HelmBlueGreenDeploy step assign Idle or Live roles to those releases by creating copies of their public Services dedicated to each role. By doing that we can easily change the releases role by updating those Services to be a copy of the Services from a specific environment. Those role Services created by Pipelines can be used to provision additional entrypoint components like DNS Records, Ingress Rules or Service Meshes.

To implement the complete Blue/Green deployment strategy workflow, Pipelines provides three native steps:

  • HelmBlueGreenDeploy discovers from runtime which release is playing Idle role, deploys the chart to it and creates or updates Idle role Services.
  • HelmBlueGreenRoleSwitch discovers from runtime which release is playing each role and flips them by creating or updating the role Services.
  • HelmBlueGreenCleanup discovers from runtime which release is playing Idle role and uninstalls it.

YAML Schema

The YAML schema for HelmBlueGreenRoleSwitch native step is as follows:

  - name:   <string>
      - name: <string>
        type: HelmBlueGreenRoleSwitch
          #inherits all the tags from bash; https://www.jfrog.com/confluence/display/JFROG/Bash
          deployStep:       <string>
            - name:         <kubernetes integration>      		   # required          

            - echo "Preparing for work..."
            - echo "Job well done!"
            - echo "uh oh, something went wrong"
          onComplete: #always
            - echo "Cleaning up some stuff"



An alphanumeric string (underscores are permitted) that identifies the step.


Must be HelmBlueGreenRoleSwitch for this step type.


Specifies all configuration selections for the step's execution environment. This step inherits the Bash/PowerShell step configuration tags, including these pertinent tags:


Description of usage



Must specify a Kubernetes Integration.


In addition, these tags can be defined to support the step's native operation:

Tags derived from Bash

All native steps derive from the Bash step. This means that all steps share the same base set of tags from Bash, while native steps have their own additional tags as well that support the step's particular function. So it's important to be familiar with the Bash step definition, since it's the core of the definition of all other steps.


Description of usage

deployStepHelmBlueGreenDeploy step name that deployed the Helm Chart and where the blue/green strategy was configured. The referenced deploy step must be declared in the same Pipeline. Required


Declares collections of shell command sequences to perform for pre- and post-execution phases:


Description of usage

onStartCommands to execute in advance of the native operationOptional
onSuccessCommands to execute on successful completionOptional
onFailureCommands to execute on failed completionOptional
onCompleteCommands to execute on any completionOptional

The actions performed for the onExecute phase are inherent to this step type and may not be overridden.


The following examples show how to configure a HelmBlueGreenRoleSwitch step.

Example 1

This pipeline shows how to deploy a Helm chart using the blue/green strategy and promote it to the Live role.

  - name: helmBlueGreenDeployPipeline
      - name: helmDeployStep
        type: HelmBlueGreenDeploy
          helmVersion: 3
          namespace: app-namespace
          blueReleaseName: app-blue
          greenReleaseName: app-green
            - blueReferenceName: app-blue-service
              greenReferenceName: app-green-service 
              idleName: app-idle-service
              liveName: app-service
            - name: kubernetes_integration
            - name: helmChartResource
     - name: helmRoleSwitch
       type: HelmBlueGreenRoleSwitch
         deployStep: helmDeployStep
           - name: kubernetes_integration
           - name: helmDeployStep   

How it Works

When you use the HelmBlueGreenRoleSwitch native step in a pipeline, it performs the following functions in the background:

  • restore_pipeline_files (restores referenced HelmBlueGreenDeploy step configuration)
  • kubectl get service (fetch Live Services to read annotations and discover current role played by the environments)
  • kubectl get service (fetch reference Services deployed by helm to create or update role Services) 
  • Cleanup and update role Services definition (uses jq on Bash nodes and jq and ConvertFrom-Json on PowerShell nodes)
  • kubectl apply (create or update role Services)

Pipelines Managed Services

The role Services managed by Pipelines can be identified by the following labels and annotations metadata:

pipelines.jfrog.com/pipelineAnnotationPipeline name
pipelines.jfrog.com/deploy-stepAnnotationStep name
pipelines.jfrog.com/runAnnotationNumber of the last run to update the Service
pipelines.jfrog.com/referenceAnnotationReference Service name
pipelines.jfrog.com/environmentAnnotationEnvironment currently playing that role
  • No labels
Copyright © 2023 JFrog Ltd.