In this approach of deployment, we follow the same strategy as in the blue/green deployments but with a minor change. Inside the blue/green deployments, the testing was carried out internally, and once the new version of the application was marked stable, all of the requests were used to switch to the new version in one go.

Inside the canary deployment approach, the testing happens based on the actual user requests. The Load Balancer is configured to redirect a certain percentage of the requests to the canary version that has been deployed in the infrastructure to see how the new version performs in the presence of the actual requests. 

The following diagram shows a representation of the Canary deployments strategy:

This kind of deployment approach is usually used for microservices-based applications when the internal testing of the application is deemed not to be enough, and there is a doubt about the stability of the infrastructure on which the application is running.

This testing approach provides the advantage of testing the application in the production use case, while allowing for easy rollback in case the application does not meet the expected results.

The drawback to using this kind of approach for deployment is the added complexity inside the infrastructure, which now needs to be intelligent to route a part of the incoming requests to the canary versions of the applications.