content_image/857229.jpg
1. Create the two applications and give them different names. Each creates a DeploymentConfig object. The applications are versions of the same program; one is usually the current production version and the other the proposed new version. 

a. Create the first application. The following example creates an application called ab- example-a : 

b. Create the second application: 

Both applications are deployed and services are created. 

$ oc new-app openshift/deployment-example --name=ab-example-a 

$ oc new-app openshift/deployment-example --name=ab-example-b 

2. Make the application available externally via a route. At this point, you can expose either. It can be convenient to expose the current production version first and later modify the route to add the new version. 

$ oc expose svc/ab-example-a 

Browse to the application at ab-example-a.<project>.<router_domain>  to verify that you see the expected version. 

3. When you deploy the route, the router balances the traffic according to the weights  specified for the services. At this point, there is a single service with default weight=1  so all requests go to it. Adding the other service as an alternateBackends  and adjusting the weights  brings the A/B setup to life. This can be done by the oc set route-backends  command or by editing the route. Setting the oc set route-backend  to 0  means the service does not participate in load- balancing, but continues to serve existing persistent connections. 

<img src='content_image/857229.jpg'>

To edit the route, run: 

$ oc edit route <route_name> 

## Example output 

... metadata: name: route-alternate-service annotations: haproxy.router.openshift.io/balance: roundrobin spec: host: ab-example.my-project.my-domain to: kind: Service name: ab-example-a weight: 10 

## NOTE 

Changes to the route just change the portion of traffic to the various services. You might have to scale the deployment to adjust the number of pods to handle the anticipated loads. 

