About Canary Deployments
This topic explains the concept of canary deployments and goes into detail about when to use them.
Scenario
A new version of your Application is ready for release. You want to send it out for production, but before running a full deployment you would like to have an idea of how will it perform by testing it in actual usage in a subset of your infrastructure. To achieve this, you can execute a canary release.
In a canary release, the new version of an Application is first deployed into some mine galleries (clients/servers) where canaries (users) go down to work. Canaries will alert miners (developers) if dangerous gases (memory, CPU, integration problems) become present. If the air is clean, you keep on pushing the changes to other galleries until the whole mine gets updated.
Changes are first rolled out to some servers of the production Environment without routed users. After testing the performance and if you are satisfied with the outcome, you can start routing some users to the new infrastructure with a traffic control mechanism, for example, some company employees, who are unaware they are being used as functional testers. If this group of users give the deployment the thumbs up (or if no problems arise), you can route some more users or roll out the changes to more servers. If, on the contrary, something goes wrong (some bugs are found), users can be re-routed to the old infrastructure, because both versions run in parallel. The canary release is fully complete when the last user is routed to the new infrastructure.
Testing of the new infrastructure can be performed manually or by using a test suite. Furthermore, users' feedback may prove helpful to fix possible bugs.
See also: