How To: Canary Deployments with ElectricFlow
Jul. 27, 2017 04:27 PM
The original post can be found here.
Aiming to make the most nail biting part of software releases – deployments – as boring, repeatable and push-button as possible, ElectricFlow 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 ElectricFlow. 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.
To read the full step-by-step process go here.