$ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment- config=true --labels=ab-example=true --env=SUBTITLE\=shardA $ oc delete svc/ab-example-a 

The application is deployed and a service is created. This is the first shard. 

2. Make the application available via a route, or use the service IP directly: 

$ oc expose deploymentconfig ab-example-a --name=ab-example --selector=ab- example\=true $ oc expose service ab-example 

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

4. Create a second shard based on the same source image and label as the first shard, but with a different tagged version and unique environment variables: 

$ oc new-app openshift/deployment-example:v2 \ --name=ab-example-b --labels=ab-example=true \ SUBTITLE="shard B" COLOR="red" --as-deployment-config=true $ oc delete svc/ab-example-b 

5. At this point, both sets of pods are being served under the route. However, because both browsers (by leaving a connection open) and the router (by default, through a cookie) attempt to preserve your connection to a back-end server, you might not see both shards being returned to you. 

To force your browser to one or the other shard: 

a. Use the oc scale  command to reduce replicas of ab-example-a  to 0 . 

Refresh your browser to show v2  and shard B  (in red). 

b. Scale ab-example-a  to 1  replica and ab-example-b  to 0 : 

$ oc scale dc/ab-example-a --replicas=0 

$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0 

Refresh your browser to show v1  and shard A  (in blue). 

6. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the SUBTITLE  environment variable in either DeploymentConfig  object: 

$ oc edit dc/ab-example-a 

or 

$ oc edit dc/ab-example-b 

