Canary Deployment
Jump to navigation
Jump to search
A Canary Deployment is a software system deployment that deploys an updated software system into a small portion of a system cluster.
- …
- Counter-Example(s):
- a deployment of a system with a Feature Toggle.
- See: Continuous Delivery.
References
2020
- https://www.split.io/blog/canary-release-feature-flags/
- QUOTE: ... By monitoring the logs and performance of the canary machines compared to others, we get early feedback about whether the release is ready for primetime. If all goes well with the canaries, we continue the deployment of new code to additional machines until we’ve got it running on all of them. Here is the canary release in a picture, adapted from a blog post by Itay Shakuri:
- QUOTE: ... By monitoring the logs and performance of the canary machines compared to others, we get early feedback about whether the release is ready for primetime. If all goes well with the canaries, we continue the deployment of new code to additional machines until we’ve got it running on all of them. Here is the canary release in a picture, adapted from a blog post by Itay Shakuri:
2020
- https://octopus.com/docs/deployment-patterns/canary-deployments
- QUOTE: ... Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted. ... As an example, imagine an environment that has four web servers. Rather than simply deploying to all deployment targets in the environment, a canary deployment would look like this:
- The basic steps of a canary deployment are:
- Deploy to one or more canary servers.
- Test, or wait until satisfied.
- Deploy to the remaining servers.
- The test phase of the canary deployment can work in many ways. You could run some automated tests, perform manual testing yourself, or even leave the server live and wait to see if problems are encountered by end users. In fact, all three of these approaches might be used. Depending on how you plan to test, you might decide to remove the canary server from the production load balancer and return it only when rolling out the change to the rest of the servers.
- QUOTE: ... Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted. ... As an example, imagine an environment that has four web servers. Rather than simply deploying to all deployment targets in the environment, a canary deployment would look like this:
…
2019
- https://docs.gitlab.com/ee/user/project/canary_deployments.html
- QUOTE: ... When embracing Continuous Delivery, a company needs to decide what type of deployment strategy to use. One of the most popular strategies is canary deployments, where a small portion of the fleet is updated to the new version first. This subset, the canaries, then serve as the proverbial canary in the coal mine. If there is a problem with the new version of the application, only a small percentage of users are affected and the change can either be fixed or quickly reverted. Leveraging Kubernetes’ Canary deployments, visualize your canary deployments right inside the Deploy Board, without the need to leave GitLab.
Use cases: Canary deployments can be used when you want to ship features to only a portion of your pods fleet and watch their behavior as a percentage of your user base visits the temporarily deployed feature. If all works well, you can deploy the feature to production knowing that it won’t cause any problems. …
- QUOTE: ... When embracing Continuous Delivery, a company needs to decide what type of deployment strategy to use. One of the most popular strategies is canary deployments, where a small portion of the fleet is updated to the new version first. This subset, the canaries, then serve as the proverbial canary in the coal mine. If there is a problem with the new version of the application, only a small percentage of users are affected and the change can either be fixed or quickly reverted. Leveraging Kubernetes’ Canary deployments, visualize your canary deployments right inside the Deploy Board, without the need to leave GitLab.