anchor.diff:            "from": {
               "kind": "ImageStreamTag",
               "name": "origin-ruby-sample:latest"
  -          },
  -          "lastTriggeredImage": ""
  +          }
           }
         }
       ],
  -    "replicas": 1,
  -    "selector": {
  -      "name": "frontend"
  -    },
  +    "strategy": { <5>
  +      "type": "Rolling"
  +    }
  +  }
  +}
  +----
  +
  +<1> The replication controller template named `frontend` describes a simple Ruby application.
  +<2> There will be 5 replicas of `frontend` by default.
  +<3> A link:#config-change-trigger[configuration change trigger] causes a new deployment to be created any time the replication controller template changes.
  +<4> An link:#image-change-trigger[image change trigger] trigger causes a new deployment to be
  +created each time a new version of the `origin-ruby-sample:latest` image repository is available.
  +<5> The link:#rolling-strategy[rolling strategy] is the default and may be omitted.
  +====
  +
  +== Triggers
  +
  +A deployment configuration can contain triggers, which drive the creation of
  +new deployments in response to events, both inside and outside OpenShift.
  +
  +WARNING: If no triggers are defined on a deployment configuration, deployments
  +must be triggered manually with:
  +
  +----
  +$ oc deploy deploymentConfigName --latest
  +----
  +
  +=== Configuration Change Trigger [[config-change-trigger]]
  +
  +The ConfigChange trigger results in a new deployment whenever changes are
  +detected to the replication controller template of the deployment configuration.
  +
  +IMPORTANT: If a ConfigChange trigger is defined on a deployment configuration,
  +the first deployment will be automatically created soon after the deployment
  +configuration itself is created.
  +
  +The following is an example of a ConfigChange trigger:
  +
  +====
  +
  +[source,json]
  +----
  +"triggers": [
  +  {
  +    "type": "ConfigChange"
  +  }
  +]
  +----
  +====
  +
  +=== Image Change Trigger [[image-change-trigger]]
  +
  +The ImageChange trigger results in a new deployment whenever the value of an
  +image stream tag changes.
  +
  +The following is an example of an ImageChange trigger:
  +
  +====
  +
  +[source,json]
  +----
  +"triggers": [
  +  {
  +    "type": "ImageChange",
  +    "imageChangeParams": {
  +      "automatic": true, <1>
  +      "from": {
  +        "kind": "ImageStreamTag",
  +        "name": "origin-ruby-sample:latest"
  +      },
  +      "containerNames": [
  +        "helloworld"
  +      ]
  +    }
  +  }
  +]
  +----
  +<1> If the `*automatic*` option is set to `false`, the trigger is disabled.
  +====
  +
  +With the above example, when the `latest` tag value of the `origin-ruby-sample`
  +image stream changes and the new tag value differs from the current image
  +specified in the deployment configuration's `helloworld` container, a new
  +deployment is created using the new tag value for the `helloworld` container.
  +
  +== Strategies
  +
  +A deployment configuration declares a strategy which is responsible for
  +executing the deployment process. Each application has different requirements
  +for availability (and other considerations) during deployments. OpenShift
  +provides out-of-the-box strategies to support a variety of deployment
  +scenarios.
  +
  +The link:#rolling-strategy[rolling strategy] is the default strategy used if
  +no strategy is specified on a deployment configuration.
  +
  +=== Rolling Strategy [[rolling-strategy]]
  +
  +The Rolling strategy performs a rolling update and supports
  +link:#lifecycle-hooks[lifecycle hooks] for injecting code into the deployment
  +process.
  +
  +The following is an example of the Rolling strategy:
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Rolling",
  +  "rollingParams": {
  +    "timeoutSeconds": 120, <1>
  +    "pre": {}, <2>
  +    "post": {}
  +  }
  +}
  +----
  +
  +<1> How long to wait for a scaling event before giving up. Optional; the default is 120.
  +<2> `*pre*` and `*post*` are both link:#lifecycle-hooks[lifecycle hooks].
  +
  +The Rolling strategy will:
  +
  +. Execute any "pre" lifecycle hook.
  +. Scale up the new deployment by one.
  +. Scale down the old deployment by one.
  +. Repeat this scaling until the new deployment has reached the desired replica
  +count and the old deployment has been scaled to zero.
  +. Execute any "post" lifecycle hook.
  +
  +IMPORTANT: During scale up, if the replica count of the deployment is greater
  +than one, the  first replica of the deployment will be validated for readiness
  +before fully scaling up the deployment. If the validation of the first replica
  +fails, the deployment will be considered a failure.
  +
  +IMPORTANT: When executing the "post" lifecycle hook, all failures will be
  +ignored regardless of the failure policy specified on the hook.
  +
  +=== Recreate Strategy [[recreate-strategy]]
  +
  +The Recreate strategy has basic rollout behavior and supports
  +link:#lifecycle-hooks[lifecycle hooks] for injecting code into the deployment
  +process.
  +
  +The following is an example of the Recreate strategy:
  +
  +====
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Recreate",
  +  "recreateParams": { <1>
  +    "pre": {}, <2>
  +    "post": {}
  +  }
  +}
  +----
  +
  +<1> `*recreateParams*` are optional.
  +<2> `*pre*` and `*post*` are both link:#lifecycle-hooks[lifecycle hooks].
  +====
  +
  +The Recreate strategy will:
  +
  +. Execute any "pre" lifecycle hook.
  +. Scale down the previous deployment to zero.
  +. Scale up the new deployment.
  +. Execute any "post" lifecycle hook.
  +
  +IMPORTANT: During scale up, if the replica count of the deployment is greater
  +than one, the  first replica of the deployment will be validated for readiness
  +before fully scaling up the deployment. If the validation of the first replica
  +fails, the deployment will be considered a failure.
  +
  +IMPORTANT: When executing the "post" lifecycle hook, all failures will be
  +ignored regardless of the failure policy specified on the hook.
  +
  +=== Custom strategy [[custom-strategy]]
  +
  +The Custom strategy allows you to provide your own deployment behavior.
  +
  +The following is an example of the Custom strategy:
  +
  +====
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Custom",
  +  "customParams": {
  +    "image": "organization/strategy",
  +    "command": ["command", "arg1"],
  +    "environment": [
  +      {
  +        "name": "ENV_1",
  +        "value": "VALUE_1"
  +      }
  +    ]
  +  }
  +}
  +----
  +====
  +
  +In the above example, the *organization/strategy* Docker image provides the
  +deployment behavior. The optional `*command*` array overrides any `CMD`
  +directive specified in the image's *_Dockerfile_*. The optional environment
  +variables provided are added to the execution environment of the strategy
  +process.
  +
  +Additionally, OpenShift provides the following environment variables to the
  +strategy process:
  +
  +[cols="4,8",options="header"]
  +|===
  +|Environment Variable |Description
  +
  +.^|`*OPENSHIFT_DEPLOYMENT_NAME*`
  +|The name of the new deployment (a replication controller).
  +
  +.^|`*OPENSHIFT_DEPLOYMENT_NAMESPACE*`
  +|The namespace of the new deployment.
  +|===
  +
  +The replica count of the new deployment will initially be zero. The
  +responsibility of the strategy is to make the new deployment active using the
  +logic that best serves the needs of the user.
  +
  +== Lifecycle Hooks [[lifecycle-hooks]]
  +
  +The link:#recreate-strategy[Recreate] and link:#rolling-strategy[Rolling]
  +strategies support lifecycle hooks, which allow behavior to be injected into
  +the deployment process at predefined points within the strategy:
  +
  +The following is an example of a "pre" lifecycle hook:
  +
  +====
  +
  +[source,json]
  +----
  +"pre": {
  +  "failurePolicy": "Abort",
  +  "execNewPod": {} <1>
  +}
  +----
  +<1> `*execNewPod*` is link:#pod-based-lifecycle-hook[a pod-based lifecycle hook].
  +====
  +
  +Every hook has a `*failurePolicy*`, which defines the action the strategy should
  +take when a hook failure is encountered:
  +
  +[cols="2,8"]
  +|===
  +
  +.^|`*Abort*`
  +|The deployment should be considered a failure if the hook fails.
  +
  +.^|`*Retry*`
  +|The hook execution should be retried until it succeeds.
  +
  +.^|`*Ignore*`
  +|Any hook failure should be ignored and the deployment should proceeed.
  +|===
  +
  +WARNING: Some hook points for a strategy might support only a subset of
  +failure policy values. For example, the link:#recreate-strategy[Recreate] and
  +link:#rolling-strategy[Rolling] strategies do not currently support the
  +`*Abort*` policy for a "post" deployment lifecycle hook. Consult the
  +documentation for a given strategy for details on any restrictions regarding
  +lifecycle hooks.
  +
  +Hooks have a type-specific field that describes how to execute the hook.
  +Currently link:#pod-based-lifecycle-hook[pod-based hooks] are the only
  +supported hook type, specified by the `*execNewPod*` field.
  +
  +=== Pod-based Lifecycle Hook [[pod-based-lifecycle-hook]]
  +
  +Pod-based lifecycle hooks execute hook code in a new pod derived from the
  +template in a deployment configuration.
  +
  +The following simplified example deployment configuration uses the
  +link:#rolling-strategy[Rolling strategy]. Triggers and some other minor details
  +are omitted for brevity:
  +
  +====
  +
  +[source,json]
  +----
  +{
  +  "kind": "DeploymentConfig",
  +  "apiVersion": "v1",
  +  "metadata": {
  +    "name": "frontend"
  +  },
  +  "spec": {
       "template": {
         "metadata": {
           "labels": {
  
positive.code: toc::[]
  
  == Overview
  A deployment in OpenShift is an update to a single replication controller's pod
  template based on triggered events. The `*deployment*` subsystem provides:
  
  - A link:#defining-a-deploymentConfig[deploymentconfig] that drives automated deployments by the system.
  - link:#triggers[Triggers] which drive new deployments in response to events.
  - User-customizable link:#strategies[strategies] for deployment rollout behavior, which are responsible for making a deployment live in the cluster.
  - link:#rollbacks[Rollbacks] to a previous deployment.
  - Replication link:#scaling[scaling].
  - An audit history of deployed pod template configurations.
  
  The deployment configuration has a version parameter value that increases in increments of one each time a new deployment is created from that configuration. In addition, the cause of the last deployment is added to the configuration.
  
  == Defining a deploymentConfig
  
  A `*deploymentConfig*` describes a single link:templates.html[template] and a
  set of link:#triggers[triggers] for when a new deployment should be created.
  A deployment is simply a specially annotated `*replicationController*`.
  
  A `*deploymentConfig*` is a REST object, which can be used in a `POST` to the
  API server to create a new instance. The following configuration results in a
  new deployment every time a Docker image tag changes:
  
  ====
  
  
negative.code:         "containers": [
            {
              "name": "helloworld",
              "image": "openshift/origin-ruby-sample"
            }
          ]
        }
      }
      "replicas": 5,
      "selector": {
        "name": "frontend"
      },
      "strategy": {
        "type": "Rolling",
        "recreateParams": {
          "pre": {
            "failurePolicy": "Abort",
  