A blue/green deployment is a deployment strategy in which you create two separate, but identical environments.
One environment (blue) is running the current application version and one environment (green) is running the new application version.
Once testing has been completed on the green environment, live application traffic is directed to the green environment and the blue environment is deprecated.
At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.
As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green.
Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.
This technique can eliminate downtime due to app deployment. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails.
Canary Deployment:
A canary deployment is a deployment strategy that releases an application or service incrementally to a subset of users.
The purpose of a canary deployment is to reduce the risk of deploying a new version that impacts the workload.
All infrastructure in a target environment is updated in small phases (e.g: 2%, 25%, 75%, 100%).
Canary deployment benefits include zero downtime, easy rollout and quick rollback — plus the added safety from the gradual rollout process.
Blue-green deploy Vs canary deployment:
If you have the resources for two complete application hosting environments, blue-green is good option.
If, however, you are limited in how many extra resources you can provision, or your application is modular and configuration-driven, you can use the canary deployment option instead.
