How To: Canary Deployments with CloudBees Flow

Aiming to make the most nail biting part of software releases - deployments - as boring, repeatable and push-button as possible, CloudBees Flow boasts the industry’s most robust deployment automation feature set. The platform provides 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 posts, I described some of the use cases for when you may want to use these advanced deployment strategies, and provided instructions for setting up Rolling Deployments  and Blue/Green Deployments in CloudBees Flow. This week, I'd like to focus on another deployment strategy: Canary Deployments.

What are Canary Deployments

Like the canaries used by miners in coal mines, canary deployments are used to deploy an application first to a small set of servers - for validation by a subset of users. After user validation, the application is rolled out to the larger set of users. This is an effective way to test new versions with live traffic and reduce the risk by containing the exposure. Canary deployments typically use two separate environments (like Blue/Green deployments ): One is the environment currently serving Production traffic, and the other is the 'Canary' environment, which is inactive at first. The new version of the application is first deployed to the Canary environment. Once it has been tested, then part of the Production traffic is diverted to this environment - using a load balancer configuration. The first environment runs the old version of the applications and bears the majority of the Production traffic, while the second environment runs the new version and handles a smaller part of that traffic. If everything looks fine, all traffic is diverted to the new 'Canary' environment. If the new version seems to be experiencing issues, the older environment can be kept instead and the Canary environment is taken offline.

Canary Deployments

---

How to set up Canary Deployments in CloudBees Flow:

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

1. Each separate environments 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 the environments separately 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 are defined, we will map them to the applications, and can then execute the Canary deployment process, like any other deployments in CloudBees Flow.

In the below example, we’re using a Canary 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 Canary strategy is used.

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

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

!  Note: If you're new to CloudBees Flow and the platform's object model and key areas of the application, you may want to start with this video  and our step-by-step in-product tutorials  (look for the Tutorials popup when you log in to the product).

---

1Create Four Environments (Dev, QA, Production-A, and Production-B)

Create four environments named Dev, QA, Production-A, and Production-B.

Create Four Environments (Dev, QA, Production-A, and Production-B)

2Mapping the Environments to the Application

Select the application and map the application tiers to the corresponding environment tiers in Dev, QA, Production-A, and Production-B.

Map application tiers to environments

3Creat a Pipeline with Three Stages

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

Create a pipeline with stages named Dev, QA, and Production.

4Create Multiple Tasks for the Production Stage

In the Production stage, create the tasks in the sequence and details listed below (the Task name is in bold ):

Pipeline tasks in Prod stage

1. Deploy Shopping Cart to limited users - This task deploys the Shopping Cart application to environments in the production stage. This uses a deployment process where the target environment is parameterized using a $  property that is set at the project level. The system automatically switches the target environments for each new release. For example, if a new version will be deployed to Production-A to test with a limited user base, the target environment would be Production-A.
2. Deploy ShoppingCart app to limited set of users
3. Certify Deployment - This task can run any test automation tool using plugins included with CloudBees Flow or can even be a manual step to review and certify the deployment. If needed, you can add steps to certify the deployment.
4. Divert Subset of traffic - This is an automation task to interact with the load-balancer to divert a subset of end user traffic to this just-deployed version. This task can use the CloudBees F5 plugin or can even point to an existing script or a custom automation.
5. Confirm if successful or not -  This can be a manual or automated task to confirm if the rollout to the subset of end users is successful.
6. Update the target env  -  This is a wrapup automated task to ensure that the $   property is set appropriately depending on the success or failure of the canary deployment.
7. Update the target env.

5Run the Pipeline

In a Canary deployment, before you run the pipeline, either the Production-A or the Production-B environment is serving all production traffic. Let’s assume that Production-B is serving the production traffic currently.

Before starting the deployment, ensure that the $  property on the project is set to value Production-A  .

When the pipeline starts:

1. The pipeline runs the Dev stage and continues to the Production stage.
2. Once the deployment reaches the Production stage, the application process task deploys to the Production-A environment based on the property value, which was set to Production-A at the start of the run.
3. Once the deployment task completes, the deployment is certified using a test automation tool or manual testing. This task (number 2 above) ensures that the new version is functionally verified to work in the Production-A environment.
4. Once the deployment is certified, a subset of traffic is automatically diverted to the Production-A environment as task 3 updates the load balancer configurations. The application is now in a canary state in which a fraction of users are tested on the newer version, whereas the larger portion still uses the safe current version.
5. Once sufficient time is allowed and testing is done, step 4 asks for user confirmation of success or failure of the new version.
6. If the new version in the Production-A environment is working satisfactorily, all traffic is diverted to it automatically. But if the user input in task 4 indicates failure, all traffic is routed back to the Production-B environment. (If you want to gradually move traffic to the newer version instead of moving the entire traffic at this time, just add additional tasks to the pipeline.)
7. The system automatically updates the $   property to Production-B if the rollout is successful, so that the next time, canary deployment begins on it. If the rollout failed as indicated by user input in task 4, the $   property is kept as Production-A.

 It's that simple!

---