I know I can have two different strategies when I want to deploy in Openshift.

• Rolling strategy: Openshift waits for new pods to become ready before scaling down the production pods.

• Recreate strategy: Openshift will remove old instances and the will start new ones.Getting a 503 HTTP error in the meanthime. For db or when two or more instances can't coexist.

To chage the deployment configuration:

oc edit dc/mydeploy-conf -o json

"spec": {
    "strategy": {
       "type": "Recreate/Rolling"
     },

EDIT 1 -- Adding info from the project github suggested by Clayton https://github.com/openshift/origin/blob/master/examples/deployment/README.md

Not included strategies in Openshift v3 but can be done manually.

• Blue-Green Deployment

Blue-Green deployments involve running two versions of an application at the same time and moving production traffic from the old version to the new version (more about blue-green deployments). There are several ways to implement a blue-green deployment in OpenShift.

Create two copies of the example application

oc new-app openshift/deployment-example:v1 --name=bluegreen-example-old
oc new-app openshift/deployment-example:v2 --name=bluegreen-example-new

Create a route that points to the old service

oc expose svc/bluegreen-example-old --name=bluegreen-example

Edit the route and change the service to bluegreen-example-new

oc edit route/bluegreen-example

• A/B Deployment

A/B deployments generally imply running two (or more) versions of the application code or application configuration at the same time for testing or experimentation purposes.

The simplest form of an A/B deployment is to divide production traffic between two or more distinct shards -- a single group of instances with homogenous configuration and code.

More complicated A/B deployments may involve a specialized proxy or load balancer that assigns traffic to specific shards based on information about the user or application (all "test" users get sent to the B shard, but regular users get sent to the A shard). A/B deployments can be considered similar to A/B testing, although an A/B deployment implies multiple versions of code and configuration, where as A/B testing often uses one codebase with application specific checks.

Example: One service, multiple deployment configs

OpenShift, through labels and deployment configurations, can support multiple simultaneous shards being exposed through the same service. To the consuming user, the shards are invisible. An example of the simplest possible sharding is described below:

Create the first shard of the application based on the example deployment images

oc new-app openshift/deployment-example --name=ab-example-a --labels=ab-example=true SUBTITLE="shard A"

Edit the newly created shard to set a label ab-example=true that will be common to all shards:

oc edit dc/ab-example-a

In the editor, add the line ab-example: "true" underneath spec.selector and spec.template.metadata.labels alongside the existing deploymentconfig=ab-example-a label. Save and exit the editor.

Trigger a re-deployment of the first shard to pick up the new labels:

oc deploy ab-example-a --latest

Create a service that uses the common label:

oc expose dc/ab-example-a --name=ab-example --selector=ab-example=true

make the application available via a route

oc expose svc/ab-example

Create a second shard based on the same source image as the first shard but different tagged version, and set a unique value:

oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE="shard B" COLOR="red"

Edit the newly created shard to set a label ab-example=true that will be common to all shards:

oc edit dc/ab-example-b

In the editor, add the line ab-example: "true" underneath spec.selector and spec.template.metadata.labels alongside the existing deploymentconfig=ab-example-b label. Save and exit the editor.

Trigger a re-deployment of the second shard to pick up the new labels:

oc deploy ab-example-b --latest

At this point, both sets of pods are being served under the route. However, since both browsers (by leaving a connection open) and the router (by default through a cookie) will attempt to preserve your connection to a backend server, you may not see both shards being returned to you. To force your browser to one or the other shard, use the scale command:

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

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