Blue-green deployment is a technique that lowers the risk by running two identical production environments, effectively reducing downtime and routing incoming traffic to either one of the environments. 

Canary deployment​ uses a phased method. It is more risk-aware where it allows one to roll out the production code to a subset of users for initial testing. 

Blue-Green Deployment

A Blue-Green deployment method can be deployed without creating application downtime. This eliminates risks that could directly affect a business and a development team​.

At any time, only one environment is live, with the live environment serving all production traffic. For example, the Blue environment is live, and the Green environment is inoperative.

In a Blue-Green Deployment, a software or version is released on a duplicate version of the live environment. A new version of the software is prepared, deployed, and tested within the green environment. Once the software or version is successfully deployed and thoroughly tested, one can switch the router and all incoming traffic to the green environment instead of the older version, i.e., the Blue environment. Therefore the Green environment is now functional, and the Blue is idle. 

In the Blue/green release, you mirror two production environments ("blue" and "green") and push changes out to all the nodes of either Blue or green environment. After successfully pushing out changes, use networking to control which environment users are routed to via DNS.

Canary Deployment

Canary deployment is different from a Blue-Green deployment. A canary deployment method primarily focuses on testing the software or version on a subset of users before making it available for all users in a live/production deployment. This deployment method decreases the chance of application failure and increases the likelihood of catching any bugs before cany changes are released to production. 

Canary development pushes new code to a small group of unaware users to determine if any significant bugs or features are broken. The new code is phased to all users after the testing is complete. 

A canary deployment might sound like an ideal solution but have a lot of factors to consider. Testing in a canary model increases the cost of every testing subset, which adds complexity to systems. A live production environment presents the challenges of dealing with multiple software version issues. Every new version issue introduces new code, components, services, and risks. In the implementation of a canary deployment, it is essential to consider what level of refactoring of code does the newer version consist of or needs from the older version, does the more recent version of the software performs and scales better than the previous version, and are different edge cases taken care of for functional issues with the code to be released. 

A simple change to two lines of code does not accommodate for a canary deployment. For example, changing the background color of your application would not qualify, whereas integrating a new payment gateway will. Implementation of a canary deployment can be done in multiple ways: 

• A load balancer can be used to route traffic based on request headers in requests.

• The user base can be partitioned within the codebase itself.

A canary deployment provides control over the impact and minimizes the points of failure when a lousy bug is released.  Practical Example 

Set up Canary Deployments on Kubernetes: 

Step 1: Pull a docker image 

Step 2: Create a Kubernetes Deployment 

Step 3: Create a service for your Kubernetes deployment 

Step 4: Note/check the version of your deployment

Step 5: Create a Canary Deployment

Step 6: Run your Canary deployment 

Step 7: Monitor your Canary version 

In brief, the essence of blue-green is deploying at once, and the importance of canary deployment is deploying incrementally. Blue-green deployment is more suitable for situations where you have practices that allow you to be confident about your release. Still, if your testing infrastructure cannot complete testing, it is better to use canary deployment and partial release.