How Canary Deployments Enable No-downtime Upgrades & Easy Rollbacks

In the early- to mid-twentieth century, miners brought canaries into coal mines with them to detect carbon monoxide and other toxic gases. Since they’re more sensitive than humans, canaries would show the first warning signs of those gases. If the canary became ill or died, miners knew they needed to evacuate immediately.

In software development, a canary deployment (also called a phased rollout) involves rolling out a new feature to a subset of users before implementing it widely. Much like the classic canary in a coal mine, this provides the opportunity to test a feature and determine if it’s harmful (or has any bugs) before exposing your larger user base.

What are the benefits of canary deployment?

When developing software, there are many different strategies for deploying new updates. The goal is to use a system that increases velocity, while reducing risk. With a canary deployment, you release a feature to a small percentage of users to see how they respond (like the canary). If that goes well, you can slowly release to more and more users, while monitoring outcomes and/or responses.

Canary deployments make it easier to ensure your features are viable before rolling out to your greater user base. You’re able to implement in a real-world environment but on a small scale. In the case of a feature that doesn’t work as expected or causes an overall negative impact, you can easily roll back the update, with most of your users none the wiser.

In other deployment scenarios, your users are at increased risk of exposure to bugs or malfunctioning features, which can damage your reputation and relationships. Those issues can cause wide scale problems — and business impacts.

When should developers use a canary deployment?

This can be used for any and all new feature roll-outs, but is especially impactful if you’re unsure how a new feature will perform or if your hardware can handle traffic/data/use. Unlike many other deployment strategies, a canary deployment makes it easy to continually monitor your feature’s roll-out, and roll back if anything is going awry.

We think of deployments in two fairly distinct categories. User facing deployments and back end/infrastructure deployments. The former are a great use case for feature flag driven canary deployments. The latter are more suited to ‘old style’ canary deployments

What other deployment strategies exist?

There are many other deployment strategies that exist. Typically, this is seen as an evolution. Basic or traditional deployment was the way of the world for a long time. More recently blue-green deployments have been the most popular option, while some teams are more towards continuous deployments with canary deployments. Advanced strategies can be more challenging, but make up for it by significantly reducing downtime and risk exposure.

These are the most common deployment strategies:

Basic Deployment

Basic deployment is the traditional way to roll out updates – you just release them widely. This is not a best practice today.

Pros:

• The most simple way to roll out an update

Cons:

• Downtime or “maintenance” periods necessary
• Can lead to extended downtime if there is a problem with the new version
• Not easy to rollback

Blue-Green Deployment

Sometimes you need to introduce or modify the infrastructure that your product runs on top of. Maybe you are introducing a caching tier with Redis, or upgrading your core database server. These infrastructure changes are challenging, and best managed at a much lower level within your platform stack than the application itself.

Providers often have ways of managing traffic like this at the network level. For example, in Google AppEngine, you can deploy a new version of your platform and then send e.g. 1% of your traffic to that new version. Similarly, AWS has a feature within their Application Load Balancer that lets you achieve the same thing.

In blue-green deployment scenarios, a second environment is set up to replicate the deployment environment. This environment will be checked to make sure that it is ready to receive traffic before being introduced into production.

Pros:

• Provides safe place to test new features
• Provides no downtime deployments

Cons:

• A second environment may not always identify all issues, and bugs can slip into production.

Feature Flag Deployment

Feature flags are a great way to deploy user-facing changes using canary deployments. There are a lot of benefits to using flags here:

• You don’t need to stand up a second set of infrastructure to manage your release
• You can easily manage your canary rollouts using your feature flagging platform like Flagsmith
• Integrations with analytics providers mean you can monitor the performance of the feature and immediately see how it affects user behavior
• Rolling the feature out to your entire population is a single button press
• You don’t have to clean up any unused infrastructure once the release has been fully rolled out

Are canary deployments right for you?

Today, your user experience is one of your key differentiators in the marketplace. Negative experiences — especially consistent ones — erode user trust and loyalty over time. Canary deployments are an effective strategy for reducing the risk of rolling out a feature that doesn’t work as expected.

Flagsmith lets you release features in confidence. You get to control who has access to what features. That makes roll-outs easy and roll-backs even easier. Try it for free today!