Canary release vs rolling deployment: Choosing a deployment strategy

October 7, 2023

Article by Michael Ferranti

Canary release

Canary release is a deployment strategy that gradually exposes a new software version to a small subset of users before rolling it out to the entire user base. This approach involves initially directing a small percentage of traffic (e.g., 5-10%) to the new version while maintaining the majority of users on the stable version. By monitoring the performance and user feedback from this “canary” group, teams can identify potential issues with minimal impact and either proceed with full deployment or roll back if problems arise.

The name “canary” comes from the historical practice of coal miners using canaries as early warning systems for toxic gases. Similarly, the small group of users serves as an early warning system for potential issues in the new software version. This strategy is particularly valuable for organizations that want to test in production with real user traffic while minimizing risk to the overall user experience.

Rolling deployment

Rolling deployment is a strategy where a new version of an application is gradually released across a fleet of servers or instances, replacing the previous version incrementally. Instead of updating all servers simultaneously, servers are taken out of the production pool one by one or in small batches, updated with the new version, verified, and then returned to the pool. This continues until all servers are running the new version.

This approach ensures continuous service availability by maintaining sufficient capacity throughout the deployment process. Rolling deployments reduce risk by allowing teams to halt the process if issues are detected after updating a subset of servers, limiting the impact to only those servers already updated. It’s commonly used in cloud environments and container orchestration platforms like Kubernetes, which can automate much of the rolling update process.

Comparison: Canary release vs. rolling deployment

Purpose

Canary Release: Tests new features with a subset of users to validate functionality and user acceptance.

Rolling Deployment: Gradually replaces server instances to minimize downtime and maintain service capacity.

Traffic management

Canary Release: Diverts a percentage of traffic to the new version while the majority continues using the stable version.

Rolling Deployment: All traffic to an updated server receives the new version as servers are incrementally updated.

Risk level

Canary Release: Lower risk as only a small percentage of users are exposed to potential issues.

Rolling Deployment: Moderate risk as servers are updated in batches, limiting but not eliminating potential widespread impact.

Rollback process

Canary Release: Quick rollback by redirecting all traffic back to the stable version.

Rolling Deployment: More complex rollback requiring reverting updated servers to the previous version.

Monitoring focus

Canary Release: Emphasizes user behavior metrics and error rates for the canary group versus the control group.

Rolling Deployment: Focuses on system health metrics and service availability during the transition period.

Deployment duration

Canary Release: Can be maintained for extended periods to gather sufficient data before full release.

Rolling Deployment: Typically aims to complete the full transition in a single, continuous operation.

Feature flags with canary releases

Feature flags complement canary releases by providing additional granularity and control over feature exposure. With canary releases, teams can use feature flags to target specific user segments for the canary group based on attributes like location, subscription tier, or usage patterns rather than just random traffic splitting. This targeted approach allows for more strategic testing with users who best represent the target audience for new features. Furthermore, feature flags enable quick toggling of problematic features without requiring a full deployment rollback, adding an extra safety layer to the canary approach.

During a canary deployment, feature flags can also help isolate which specific features might be causing issues. By using multiple feature flags within a single release, teams can independently evaluate different components and make data-driven decisions about which features to roll out widely and which need more refinement. This capability transforms canary releases from simple binary deployments to sophisticated, feature-by-feature progressive delivery platforms.

Feature flags with rolling deployments

In rolling deployments, feature flags provide an additional dimension of control beyond the infrastructure-focused approach of gradually updating servers. While rolling deployments ensure that new code is safely distributed across the infrastructure, feature flags determine whether that code is actually executed. This separation allows teams to complete a rolling deployment of dormant features across all servers, then later activate those features through feature flags without requiring another deployment cycle. This approach minimizes the number of deployments while maintaining fine-grained control over feature availability.

Feature flags also enhance rolling deployments by providing circuit-breaker functionality. If monitoring detects issues after a feature has been activated across all servers, teams can instantly disable the problematic feature via the feature flag rather than rolling back the entire deployment. This capability is particularly valuable in rolling deployments where reversing a partially completed deployment can be complex and time-consuming. By combining rolling deployments with feature flags, organizations achieve both infrastructure stability and feature agility.

Canary releases and rolling deployments are both strategies for deploying software updates with minimal risk and disruption. A canary release involves deploying a new version to a small subset of users or servers first—often just 5-10% of traffic—while maintaining the existing version for everyone else. This allows teams to test the new version in production with real users while limiting potential negative impacts. The primary advantage is the ability to quickly detect and contain issues before they affect the entire user base. However, canary releases require more complex infrastructure to manage traffic routing and monitoring, and may lead to inconsistent user experiences during the partial deployment phase.

Rolling deployments, on the other hand, gradually replace instances of the old version with the new version across the entire infrastructure in waves or batches. This approach provides a more consistent upgrade path with less infrastructure complexity compared to canary releases. Rolling deployments are ideal for services with horizontally scaled, stateless architectures and when you have high confidence in your testing processes. Choose canary releases when you need careful risk management for critical services or when dealing with unpredictable user reactions to changes, particularly for customer-facing applications. Opt for rolling deployments when your application is designed for horizontal scaling, when you have strong pre-production testing, or when simplicity in deployment architecture is preferred over the fine-grained control offered by canary releases.

Frequently asked questions

What is a canary release?

A canary release is a deployment strategy that gradually exposes a new software version to a small subset of users (typically 5-10% of traffic) before rolling it out to the entire user base. The name comes from the historical practice of coal miners using canaries as early warning systems for toxic gases. Similarly, this small group of users serves as an early warning system for potential issues in the new software version, allowing teams to identify problems with minimal impact and either proceed with full deployment or roll back if problems arise.

How does a canary release differ from a rolling deployment?

While both strategies minimize risk during software updates, they differ in several ways. Canary releases test new features with a subset of users to validate functionality and user acceptance, while rolling deployments gradually replace server instances to minimize downtime. Canary releases divert only a percentage of traffic to the new version, whereas rolling deployments update servers incrementally with all traffic to an updated server receiving the new version. Canary releases offer lower risk as only a small percentage of users experience potential issues, while rolling deployments have moderate risk as servers are updated in batches.

How do feature flags complement canary releases?

Feature flags provide additional granularity and control over feature exposure during canary releases. They allow teams to target specific user segments for the canary group based on attributes like location, subscription tier, or usage patterns rather than just random traffic splitting. Feature flags enable quick toggling of problematic features without requiring a full deployment rollback, adding an extra safety layer. They also help isolate which specific features might be causing issues, transforming canary releases from simple binary deployments to sophisticated, feature-by-feature progressive delivery platforms.

When should I choose a canary release over a rolling deployment?

Choose canary releases when you need careful risk management for critical services or when dealing with unpredictable user reactions to changes, particularly for customer-facing applications. Canary releases are ideal when you want to test in production with real user traffic while minimizing risk to the overall user experience. Rolling deployments are better suited when your application is designed for horizontal scaling, when you have strong pre-production testing, or when simplicity in deployment architecture is preferred over the fine-grained control offered by canary releases.

Share this article