The “Take Release Automation to the Next Level” series gives you insights into the benefits and challenges surrounding DevOps deployment patterns. In this series, we’ll look at how different patterns work, the advantages and disadvantages of each one, considerations for implementing them, and best practices when applying them.
In Episode 3, we looked at rolling updates, which is a deployment strategy that helps teams achieve zero downtime while updating an application. A canary release is a similar strategy that allows you to roll out new features to—and collect feedback from—a targeted group of users.
In a canary release, you upgrade an application on a subset of the infrastructure and allow a limited set of users to access the new version. This approach allows you to test the new software under a Production-like load, evaluate how well it meets users’ needs, and assess whether new features are profitable.
A canary release is similar to a rolling update because it involves releasing a new feature in a staged manner. However, when you perform a rolling update, you only verify that the application is technically stable and functional before moving on to the next stage of the rollout. With a canary release, you evaluate users’ reaction to a new feature or functionality before deciding whether to release it more widely.
Advantages of Canary Releases
Canary releases are a good way to release experimental or beta features to users and gather their feedback. For example, you can use a canary release to roll out a new feature to users in a specific geographic region. If those users like the feature, you can deploy a canary to another region and test the user response there; or, you could choose to upgrade all remaining nodes in the environment, possibly by applying another release pattern to minimize application downtime.
Disadvantages of Canary Releases
Canary releases pose similar risks to rolling updates because multiple versions of the same application run in the environment while the canary release is deployed. For that reason, the environment will be somewhat unpredictable during the canary timeframe, and the application architecture must support running in cluster mode so that multiple instances can access the database.
Rolling Back a Canary Release
Rolling back a canary release is relatively easy because you only need to roll back the application version on servers where the new application version is deployed. User traffic can be redirected to nodes running the older version of the application, so users will not experience application downtime.
Implement Canary Releases with the XebiaLabs DevOps Platform
Canary releases pose similar risks to rolling updates, so successfully adopting canary releases requires similar control over the end-to-end deployment process. It’s important to automate control of the load balancer both when deploying a new application version and when rolling back. The XebiaLabs DevOps Platform makes it easy to implement canary releases consistently across different teams and applications. XebiaLabs also makes it easy to combine the canary release pattern with other advanced deployment patterns, so you have maximum flexibility while staying in control of your software delivery pipelines.
This white paper gives you insights into the DevOps best practice of advanced deployment patterns. It describes how each pattern works, the advantages and disadvantages of each one, considerations for implementing them, and best practices when applying them. Read more.
- Take Release Automation to the Next Level, Episode 3: Rock Your Pipeline with Rolling Updates
- Take Release Automation to the Next Level, Episode 2: Blaze a Trail with Blue/Green Deployments
- Take Release Automation to the Next Level, Episode 1: Speed Up Delivery with Advanced Deployment Patterns
- Best Practices for DevOps: Advanced Deployment Patterns
- How to perform a canary release with XebiaLabs
- Ullink Doubles Deployments and Achieves Zero Production Failures with XebiaLabs