Software Release Glossary
Most commonly used terms and acronyms by product managers, engineers and devops, regarding deployment strategies

Canary Deployment

What is a canary deployment?

Canary deployment (or canary release) is a deployment strategy that reduces the risk of releasing new software by allowing you to release the software gradually to a small subset of users. Thus, this technique allows you to test your features on a certain group of users before rolling out to the rest of your users.

The origin of the phrase comes from coal mining where the canary birds were used to detect carbon monoxide or other toxic gases. Canaries are more sensitive to these gases than humans so if a bird died then that was a sign for the miners to evacuate.

In the context of software development, it might not be this extreme but it does serve the purpose of alerting developers to any issues in production before it’s rolled out to everyone else causing damage to their business. 

How to run canary deployment?

You start by choosing this subset of users. The simple way is to choose a random sample. However, you can also choose to test on just your internal employees or if you want to get more sophisticated, you can choose your users based on criteria such as location or other demographics.

Therefore, you start testing on this subset of users then as you gain more confidence in your release, you widen your release and direct more users to it. You would do this by directing this group of users to a new software version while the rest of the users remain in the original version. 

For example, you can have 10% of users in the new version while the remaining 90% stay in the old version. If no errors are reported with the 10% then you can gradually roll it out to more users until you feel confident enough to release it to all users.

Sometimes developers might opt for blue-green deployment instead. This is where production is split into two similar environments, one active and the other idle. Any work done on the new version will be made in the active environment, such as in the green environment while the blue or idle environment remains as backup. The blue environment remains active while all changes are being made. Once the release is finished, all traffic would then be directed towards the green-the now active- environment. If anything goes wrong, you can switch back to the blue environment.

While a blue/green deployment extends to all users, canary deployments are usually more targeted towards a specific group of users.

More control and confidence 

The main advantage of canary deployment lies in the fact that you would be able to test your features on a pre-selected group of users with a safe rollback strategy should any issues arise during testing.

Therefore, you are reducing risk as you are not doing one big bang release to all your users so a canary release gives you a layer of protection and a way to safely roll back in case of bugs. The good news is that only a small percentage of your users will encounter that bug as opposed to 100%.

Canary release vs canary deployment

You might have come across both terms being used interchangeably. The difference is that during deployment, the code is pushed into production but is not yet visible to users. Meanwhile, during release users get access to the new features.

Flagship Sign Up

In fact, they both represent the same idea but it depends on what term each organization chooses to use. They essentially boil down to the same idea of releasing software with less risk.

Canary testing and feature flags

Canary deployment act at the level of full deployment and not individual features, as is the case with feature flags. Therefore, with canary releases you don’t have control over an individual feature.

Canary testing can be done using feature flags by turning on or off certain features for certain users. Used separately, both have their individual benefits but when used together you get fool-proof safe and quick deployments.

With feature flags, you can perform a canary test on each feature by selecting the group of users you want to test your feature on. This way, you can bypass multiple environments and test at the user rather than the server level.

Without feature flags, any issue that comes up with your canary release you have to rollback the entire deployment to fix the issue and then go through the deployment and release process all over again. However, with feature flags, you can simply turn off the buggy feature and go on with the release as planned without the need for redeployment.

Therefore, feature flags serve as a kill switch so if you run into an issue with your canary release, you can just deactivate the troublesome feature using feature flagging.

However, canary releases are not a good idea when you want to test out multiple features. In this scenario, it’s best to use feature flags to be able to understand where the issue is and with which feature exactly.

In conclusion

Canary deployment, much like the term they originate from, serve as a warning for developers. By releasing to a small subset of users, developers can rollback and go back to the original version while they fix any issues. With feature flags, this strategy becomes simpler but more powerful resulting in a superior product for your target customers.

Keep reading: Everything You Need to Know About Canary Deployments.

More terms from the glossary
Smoke Testing

Smoke testing is a rapid regression test of major functionality to detect early errors and indicate whether the product is ready for further testing.

Read description
Version Control

Version control, or source control, is the practice of managing and tracking changes to software code.

Read description
Software Development Life Cycle

Software development life cycle (SDLC) refers to the different stages that a software goes through from planning to completion.

Read description
Copy link