The HelmBlueGreenDeploy step implements a Blue/Green strategy to deploy a Docker image to a Kubernetes cluster using a Helm chart.
The Helm chart used to deploy the image through this native step can be either:
A HelmChart resource that identifies a Helm chart stored in an Artifactory repository by HelmPublish.
A Helm chart in a source code repository identified by a GitRepo resource.
When properly configured, the HelmBlueGreenDeploy step also performs a replace_envs operation on all files specified under the blueValueFilePaths or greenValueFilePaths tag to replace all environment variables in those files with their values. This enables the step to derive information from a resource, such as the image name and tag from an Image, and use it to perform the deployment.
The HelmBlueGreenDeploy step uses the helm upgrade command to perform the deployment.
Blue/Green Deployment Strategy
Blue/Green deployment is a strategy for releasing new software that uses two production environments, as identical as possible, where they take turns in serving user requests and performing final stages of testing.
The HelmBlueGreenDeploy step refers to those two environments as blue and green. Those environments can play either 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, it is first deployed 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, the environment roles can be flipped so that the previously Idle environment becomes Live and starts handling user requests, while the previously Live environment becomes 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 release's 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: From runtime, this step discovers which release is playing Idle role, deploys the chart to it and creates or updates Idle role Services.
elmBlueGreenRoleSwitch: From runtime, this step discovers which release is playing each role and flips them by creating or updating the role Services.
HelmBlueGreenCleanup: From runtime, this step discovers which release is playing Idle role and uninstalls it.
The following topics provide more information on HelmBlueGreenDeploy Pipeline steps: