The A/B deployment approach shares a lot of similarities with the canary deployment approach, where a new version of the application is introduced into the production infrastructure and a certain number of incoming requests are redirected toward the canary version.

In the A/B deployments, the upgraded version of the application (version B) is introduced into the production infrastructure, and the load balancer is then configured to redirect a certain set of requests to the upgraded version based on some predefined criteria.

This kind of deployment approach is required when we are not sure how an upgraded version will affect a certain subset of users. For example, how will the users using a smartphone be affected by an upgraded version of the application?

If the functionality for the use cases seems to meet the expectations, version A is decommissioned and version B acts as a production version, handling all the incoming requests to the application.

The advantages of utilizing A/B deployments provide us with the following:

• Control over request distribution: With the A/B deployments in place, we are in control of how the requests are distributed across the different versions of the application that are deployed in production.
• The Ability to evaluate the functionality for a subset of users: In this approach, if there is some kind of doubt about how a particular update to the application will affect the subset of users meeting a certain criterion, we can specifically test the new version of the application with those users by introducing request redirection rules for the users inside the load balancer.