How To: Blue/Green Deployments with CloudBees Flow

CloudBees Flow was designed to enable teams to streamline and to simplify their DevOps processes – from the most mundane automation workflows to the most complex and large-scale scenarios. As part of that, we’ve set to revolutionize one of the most nail-biting parts of software releases: deployments.

Aiming to make this process as boring, repeatable and push-button as possible, CloudBees Flow boasts the industry’s most robust deployment automation feature set, providing several out-of-the-box ways to deploy applications that are designed to take the stress, guess work, and complex, one-off, scripting out of the equation. These include deployment options such as Smart Deploy, staging artifacts, and automatic error handling or process branching, as well as advanced deployment strategies and deployment policies - such as rolling deployments, blue/green, canary, and dark launch.

In this blog series, I provide step-by-step tutorials for each deployment pattern - which you can implement for your own application releases using our free community edition!

In my previous post I described some of the use cases for when you may want to use these advanced deployment strategies as a way to minimize risk and provided instructions for setting up Rolling Deployments  in CloudBees Flow. This week, I'd like to focus on another deployment strategy: Blue/Green Deployments.

What are Blue/Green Deployments

This deployment strategy reduces downtime and risk by running two identical Production environments, referred to as Blue and Green . The key difference between Rolling Deployment and Blue/Green Deployment is that there are two physically separate environments. At any given time, only one of these environments is 'live', serving all of the Production traffic. Let's say the currently live Production environment is the Green one. We will spin up a duplicate of that - the Blue environment - and deploy new versions of the application to that, which is currently not serving live traffic. Once the version deployed on Blue has been thoroughly tested and validated, and we see that it is stable and that the application is operating correctly, then all end-user Production traffic will be diverted to that environment, which is now live. After the switch, the Green environment becomes inactive, and can be either decommissioned, or used for deploying the next release that needs to be tested. Then the process is repeated when we're ready to make the switch in Production, again.

Blue/Green Deployment Strategy

Blue/Green deployment strategy is especially compelling when using cloud environment, where the resources can be dynamically spun up/decommissioned depending on the need. This is in contrast to on-premises data centers or physical hardware, where you would need to over-provision and keep the hardware for the duplicated environment, even when it is idle. The Blue/Green strategy is also useful when it is advantageous - and for some organizations even mandatory from a regulatory perspective - to maintain a separate mirrored environment for disaster recovery.

While Blue/Green deployments makes it much simpler to recover from unforeseen deployment errors, as there are two separate environments, it does come with a higher resource costs, due to the environment duplication. This may make it less feasible for extremely large Production environments/footprint.

---

How to set up Blue/Green Deployments in CloudBees Flow:

CloudBees Flow allows you to model and trigger Blue/Green deployments in multiple ways, depending on your processes and environment setup. For this tutorial, we'll cover the most straightforward option: creating separate Blue and Green environments in the product's GUI.

1. The separate environments we're creating are identical in every respect, and each is modeled and set up independently.
2. The environments can be created either prior to the deployment (if they are using static resources), or dynamically at the deployment runtime using environment templates .
3. Modeling Blue and Green as separate environments also allows us to keep track of the component inventory independently so that users can always know what is deployed to the Blue vs. Green environments at any given time.
4. Once the environment models for Blue and Green are defined, we will map them to the applications, and can then execute the Blue/Green deployment process, like any other deployments in CloudBees Flow.

In the below example, we’re using Blue/Green Deployment to deploy to Production the “shopping cart” application of an eCommerce site. The current deployment process requires that the application is tested in Dev and QA environments before it is deployed to the Production environment - where the Blue/Green strategy is used.

Here are the steps for modeling Blue/Green deployment for this use case:

1. Create four environments
2. Map the environments to the application
3. Create a pipeline with three stages
4. Create three tasks for the PROD stage
5. Run the pipeline

---

1Creating Four Environments (DEV, QA, BLUE, and GREEN)

Create four environments named DEV, QA, BLUE, and GREEN.

Model Your Environments

Note: DEV, QA, BLUE, and GREEN are names for the environments in this use case. You can use any names you want for them as long as it is clear how they map to BLUE and GREEN.

2Mapping the Environments to the ShoppingCart Application

Select the ShoppingCart application (comes seeded in the product), and then map the application tiers to the corresponding environment tiers in DEV, QA, BLUE, and GREEN.

Map application tiers to environments  

3Creating a Pipeline with Three Stages

Create a pipeline with three stages named DEV, QA and PROD.

Create a pipeline with three stages named DEV, QA and PROD.

4Creating Three Tasks for the PROD Stage

In the PROD stage, create three tasks, with the below details (the Task name is in bold ):

1. DeployShoppingCart -  This is another process task similar to what is in the DEV and QA stages with the environment name parameterized. The system will automatically switch deployments between the BLUE and GREEN environments.
2. CertifyDeployment -  This is a manual step to review and certify the deployment.
3. completePostCertificationTasks - This is an automation task to run any post-certification tasks, such as updating the load balancer and switching the environment in preparation for the next pipeline run (for example, update the TargetEnv parameter)

Pipeline tasks in Prod stage  

5Run the Pipeline

In a Blue/Green deployment, before you run the pipeline, the GREEN environment is serving all of the Production traffic, and the BLUE environment is ready to be upgraded to the new software version.

1. Before starting the deployment, set the RollingDeploy/TargetEnv  property on the project to the first environment to which you want to deploy.
2. RollingDeploy/TargetEnv   will be set to BLUE because the GREEN environment is currently catering to end-user traffic.

When the pipeline starts:

1. The pipeline will start at the DEV stage and continue to the PROD stage.
2. Once the deployment reaches the PROD stage, the application process task will deploy to the BLUE environment based on the property value $  , which was set to BLUE at the beginning of the run.
3. Once the deployment task has completed, there is a manual step to functionally verify the deployment.If there was a need for some automated testing, those tasks can easily be added to the pipeline stage.
4. Once the deployment completes successfully, switch the user traffic to the BLUE servers, and update the RollingDeploy/TargetEnv   property to GREEN . Setting the property value to GREEN will ensure that the next deployment will happen to the GREEN environment while the BLUE environment serves Production traffic.

---