2. Create a route that points to the old service: 

$ oc new-app openshift/deployment-example:v2 --name=example-green 

$ oc expose svc/example-blue --name=bluegreen-example 

3. Browse to the application at example-blue.<project>.<router_domain>  to verify you see the v1  image. 

4. Edit the route and change the service name to example-green : 

$ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}' 

5. To verify that the route has changed, refresh the browser until you see the v2  image. 

## 3.4.5. A/B deployments 

The A/B deployment strategy lets you try a new version of the application in a limited way in the production environment. You can specify that the production version gets most of the user requests while a limited fraction of requests go to the new version. 

Because you control the portion of requests to each version, as testing progresses you can increase the fraction of requests to the new version and ultimately stop using the previous version. As you adjust the request load on each version, the number of pods in each service might have to be scaled as well to provide the expected performance. 

In addition to upgrading software, you can use this feature to experiment with versions of the user interface. Since some users get the old version and some the new, you can evaluate the user’s reaction to the different versions to inform design decisions. 

For this to be effective, both the old and new versions must be similar enough that both can run at the same time. This is common with bug fix releases and when new features do not interfere with the old. The versions require N-1 compatibility to properly work together. 

OpenShift Container Platform supports N-1 compatibility through the web console as well as the CLI. 

## 3.4.5.1. Load balancing for A/B testing 

The user sets up a route with multiple services. Each service handles a version of the application. 

Each service is assigned a weight  and the portion of requests to each service is the service_weight divided by the sum_of_weights . The weight  for each service is distributed to the service’s endpoints so that the sum of the endpoint weights  is the service weight . 

The route can have up to four services. The weight  for the service can be between 0  and 256 . When the weight  is 0 , the service does not participate in load-balancing but continues to serve existing persistent connections. When the service weight  is not 0 , each endpoint has a minimum weight  of 1 . Because of this, a service with a lot of endpoints can end up with higher weight  than intended. In this case, reduce the number of pods to get the expected load balance . 

## Procedure 

To set up the A/B environment: 

