anchor.diff:  [[rolling-strategy]]
   === Rolling Strategy
   
  -The rolling strategy performs a rolling update and supports
  -xref:lifecycle-hooks[lifecycle hooks] for injecting code into the deployment
  -process.
  -
  -The rolling deployment strategy waits for pods to pass their
  -xref:../dev_guide/application_health.adoc#dev-guide-application-health[readiness
  -check] before scaling down old components, and does not allow pods that do not
  -pass their readiness check within a configurable timeout.
  +A rolling deployment slowly replaces instances of the previous version of an
  +application with instances of the new version of the application. A rolling
  +deployment typically waits for new pods to become *ready* via a *readiness
  +check* before scaling down the old components. If a significant issue occurs,
  +the rolling deployment can be aborted.
  +
  +[[canary-deployments]]
  +=== Canary Deployments
  +
  +All rolling deployments in {product-title} are _canary_ deployments; a new
  +version (the canary) is tested  before all of the old instances are replaced. If
  +the readiness check never succeeds, the canary instance is removed and the
  +deployment configuration will be automatically rolled back. The readiness check
  +is part of the application code, and may be as sophisticated as necessary to
  +ensure the new instance is ready to be used. If you need to implement more
  +complex checks of the application (such as sending real user workloads to the
  +new instance), consider implementing a custom deployment or using a blue-green
  +deployment strategy.
  +
  +[[when-to-use-a-rolling-deployment]]
  +=== When to Use a Rolling Deployment
  +
  +* When you want to take no downtime during an application update.
  +* When your application supports having old code and new code running at the same time.
  +
  +A rolling deployment means you to have both old and new versions of your code
  +running at the same time. This typically requires that your application handle
  +xref:n1-compatibility[N-1 compatibility], that data stored by the new version
  +can be read and handled (or gracefully ignored) by the old version of the code.
  +This can take many forms -- data stored on disk, in a database, in a temporary
  +cache, or that is part of a user's browser session. While most web applications
  +can support rolling deployments, it is important to test and design your
  +application to handle it.
   
   The following is an example of the Rolling strategy:
   
  
positive.code: 
  == Overview
  
  {product-title} deployments provide fine-grained management over applications
  based on a user-defined template called a deployment configuration. The
  deployment system in response to a deployment configuration will create a
  replication controller to run an application. Replication controllers are
  created manually or in response to triggered events.
  
  [IMPORTANT]
  ====
  Users should never manipulate replication controllers owned by
  deployment configurations. The deployment system makes sure changes to
  deployment configurations are propagated appropriately to replication
  controllers.
  ====
  
  Features provided by the deployment system:
  
  - A xref:creating-a-deployment-configuration[deployment configuration], which is a template for running applications.
  - xref:triggers[Triggers] that drive automated deployments in response to events.
  - User-customizable xref:strategies[strategies] to transition from the previous version to the new version.
  - xref:rolling-back-a-deployment[Rollbacks] to a previous version either manually or automatically in case of deployment failure.
  - Manual replication xref:scaling[scaling] and autoscaling.
  
  The deployment configuration contains a version number that is incremented
  each time a new replication controller is created from that configuration.
  In addition, the cause of the last deployed replication controller is added
  to the deployment configuration.
  
  [[creating-a-deployment-configuration]]
  == Creating a Deployment Configuration
  
  A deployment configuration consists of the following key parts:
  
  - A pod template, which describes the application to be deployed.
  - The initial replica count for the replication controller.
  - A deployment xref:strategies[strategy], which will be used to deploy the application.
  - A set of xref:triggers[triggers], which cause replication controllers to be created automatically.
  - A set of xref:lifecycle-hooks[hooks] for executing custom behavior in different points during the lifecycle of a deployment.
  
  Deployment configurations are `*deploymentConfig*` {product-title} API resources
  which can be managed with the `oc` command like any other resource. The
  following is an example of a `*deploymentConfig*` resource:
  
  ====
  
  
negative.code: xref:../dev_guide/application_health.adoc#dev-guide-application-health[readiness
  checks] to determine if a new pod is ready for use. If a readiness check fails,
  the deployment configuration will retry to run the pod until it times out. The
  default timeout is `10m`, a value set in `TimeoutSeconds` in
  `dc.spec.strategy.*params`.
  
  The xref:rolling-strategy[Rolling strategy] is the default strategy used if
  no strategy is specified on a deployment configuration.
  