anchor.diff:  ---
   
   This topic describes a workflow by which developers can push updates to their apps without incurring downtime. 
  -
  -Cloud foundry now supports native rolling, zero-downtime deployments for applications. The traditional cf push behavior is to upload your new code, stop the old version of the application, and start the new version of the application.
   
   ## <a id="prerequisites"></a>  Prerequisites
   
  
positive.code: 
  ## <a id="deploy"></a>  Deploy an App
  
  
  To deploy an app without incurring downtime, run the following command:
  
  ```
  cf v3-zdt-push APP-NAME
  
negative.code: 
  * Scaling up the original web process
  * Removing any deployment artifacts
  * Resetting the `current_droplet` on the app
  
  ### <a id="restart"></a> Restart an App
  
  ## <a id="how-it-works"></a> How it works
  
  The original `cf push` does the following:
  
  1. Uploads your new code.
  1. Stops the old version of the app.
  1. Starts the new version of the app.
  
  To understand how the `v3-zdt-push` command works, see the _Deployment Algorithm_ section below.
  
  ### <a id="deployment-algorithm"></a>  Deployment Algorithm
  
  `cf v3-zdt-push` does the following:
  
  1. Stages the app and create a droplet with the updated code for your app.
  1. Creates a new deployment web process for the app with the new droplet and any new configuration. This new process starts out with 1 instance and shares the route with the old process. If you run `cf app` on your app, you see a `web` process and a `web-deployment-DEPLOYMENT-UUID` process.
  1. The `cc_deployment_updater` BOSH job runs in the background, updating deployments as follows:
  	1. Add another instance of the new deployment web process and remove an instance from the old web process. This only happens if all instances of the new deployment web process are currently running.
  	1. Repeat the above step until the new deployment web process reaches the desired number of instances. 
  	1. Remove the old web process. The new deployment web process now fully replaces the old web process.
  	1. Update all non-web processes with a restart. 
  	1. Mark the deployment as `DEPLOYED`. 
  
  ### <a id="limitations"></a>  Limitations
  
  The following table describes the limitations to consider when using the experimental `v3-zdt-push` command. 
  
  <table>
  	<tr>
  		<th>Limitation</th>
  		<th>Description</th>
  	</tr>
  	<tr>
  		<td>Multiple app versions</td>
  		<td>During a deployment, Cloud Foundry serves both the old and new version of your app at the same route. This could lead to user issues if you push backwards-incompatible API changes.</td>
  	</tr>
  	<tr>
  		<td>Database migrations</td>
  		<td>Deployments do not handle database migrations. If you are migrating an app database and the old app is not compatible with the migration, you may still have downtime. 
  		</td>
  	</tr>
  	<tr>
  		<td>Non-web processes</td>
  		<td>Zero-downtime deployments are only for web processes. Non-web processes, such as worker processes, restart in bulk after the web processes have updated. 
  		</td>
  	</tr>
  	<tr>
  		<td>Quotas</td>
  		<td>A deployment creates an extra instance of your app. If there is not enough quota available, the deployment does not work. Administrators may need to increase quotas to account for zero-downtime deployments.</td>
  	</tr>
  	<tr>
  		<td>Simultaneous deployments</td>
  		<td>If you run <code>v3-zdt-push</code> for an app before your previous <code>v3-zdt-push</code> command for the same app has completed, your first push gets interrupted. Until the last deployment completes, there may be many versions of the app running at once. Eventually, the app runs the code from your most recent push.</td>
  	</tr>
  </table>