From 0a8d9f1258197cca50ee02819ea94ce129bfb2b3 Mon Sep 17 00:00:00 2001 From: Seth Boyles Date: Fri, 10 Jan 2025 15:51:39 -0800 Subject: [PATCH] Combine Rolling and Canary Deployments docs --- deploy-apps/canary-deploy.html.md.erb | 397 ------------------------- deploy-apps/rolling-deploy.html.md.erb | 290 +++++++++++------- 2 files changed, 188 insertions(+), 499 deletions(-) delete mode 100644 deploy-apps/canary-deploy.html.md.erb diff --git a/deploy-apps/canary-deploy.html.md.erb b/deploy-apps/canary-deploy.html.md.erb deleted file mode 100644 index 211c211b..00000000 --- a/deploy-apps/canary-deploy.html.md.erb +++ /dev/null @@ -1,397 +0,0 @@ ---- -title: Configuring canary app deployments -owner: CAPI ---- - -You can use Cloud Foundry Command Line Interface (cf CLI) commands -or the Cloud Foundry API (CAPI) to push your apps to <%= vars.app_runtime_first %> using a canary deployment. - -For information about the traditional method for addressing app downtime while pushing app updates, -see [Using blue-green deployment to reduce downtime and risk](./blue-green.html). - -For more information about CAPI, see the -[Cloud Foundry API (CAPI) documentation](https://v3-apidocs.cloudfoundry.org/). - -Canary deployments will allow users to deploy a single instance of a new version of an application and check if it is running as expected, -before continuing the rolling deployment of the rest of the instances. If the new version of the application is not running as expected, the canary deployment can be cancelled. - -The expected workflow for this feature is: -1. Deploy a single canary instance with the changed code -1. Manually verify that canary instance with new code runs as expected -1. Continue the rolling deployment for the remaining instances. - - -## Prerequisites - -The procedures in this topic require one of the following: - -* **cf CLI v8.8.0 or later** - -* **CAPI V3.173.0 or later:** If you use CAPI V3, you must install the cf CLI version 8+. - - -## Commands - -This section describes the commands for working with canary app deployments. - -### Deploy an app - -To deploy a canary version of an app: - -

-Caution -Review the limitations of this feature before running the command. For more information, see -Limitations.

- -* **For CF CLI v8:** - ``` - cf push APP-NAME --strategy canary --max-in-flight MAX_IN_FLIGHT - ``` - Where `APP-NAME` is the name that you want to give your app. - Where `MAX_IN_FLIGHT` applies **after** the single canary instance is successful and specifies the maximum number of new instances to start simultaneous until the deployment is complete. Optional and defaults to 1. - -

- Note - cf CLI will exit when the canary instance is healthy. - It also includes a --no-wait flag on push for users who don't want to wait - for the operation to complete. -

- - To cancel, see [Cancel a canary deployment](#cancel). - -* **For CAPI V3:** - 1. Log in to the cf CLI. - - ``` - cf login - ``` - 2. Create an empty app by running the following `curl` command with `POST /v3/apps`. Record the - app GUID from the output. - - ``` - cf curl /v3/apps \ - -X POST \ - -H "Content-type: application/json" \ - -d '{ - "name": "APP-NAME", - "relationships": { - "space": { - "data": { - "guid": "SPACE-GUID" - } - } - } - }' - ``` - - Where: - - 3. Create a package with the following `curl` command with `POST /v3/packages`. Record the package - GUID from the output. - - ``` - cf curl /v3/packages \ - -X POST \ - -H "Content-type: application/json" \ - -d '{ - "type": "bits", - "relationships": { - "app": { - "data": { - "guid": "APP-GUID" - } - } - } - }' - ``` - Where `APP-GUID` is the app GUID that you recorded in an earlier step. This app GUID is a - unique identifier for your app. - 4. Upload the package bits by running the following `curl` command with - `POST /v3/packages/PACKAGE-GUID/upload`. - - ``` - cf curl /v3/packages/PACKAGE-GUID/upload \ - -X POST \ - -F bits=@"PACKAGED-APP" \ - ``` - - Where: - - 5. Create the build by running the following `curl` command with `POST /v3/builds`. Record the - droplet GUID from the output. - - ``` - cf curl /v3/builds \ - -X POST \ - -H "Content-type: application/json" \ - -d '{ - "package": { - "guid": PACKAGE-GUID" - } - }' - ``` - Where `PACKAGE-GUID` is the package GUID that you recorded in an earlier step. - 6. Deploy your app by running the following `curl` command with `POST /v3/deployments`. To verify - the status of the deployment or take action on the deployment, record the deployment GUID from the - output. - - ``` - cf curl /v3/deployments \ - -X POST \ - -H "Content-type: application/json" \ - -d '{ - "droplet": { - "guid": "DROPLET-GUID" - }, - "options": { - "max_in_flight": MAX_IN_FLIGHT - }, - "strategy": "canary", - "relationships": { - "app": { - "data": { - "guid": "APP-GUID" - } - } - } - }' - ``` - Where `DROPLET-GUID` and `APP-GUID` are the GUIDs that you recorded in earlier steps. - Where `MAX_IN_FLIGHT` is an integer that applies **after** the single canary instance is successful and specifies the maximum number of new instances to start simultaneous until the deployment is complete. Optional and defaults to 1. - -For more information about this command, see [How it works](#how-it-works). - -### Continue the canary deployment - -To finish the deployment after validating the canary: - -* **For cf CLI v8+, run:** - - ``` - cf continue-deployment APP-NAME - ``` - Where `APP-NAME` is the name of the app. - -* **For CAPI V3, run:** - - ``` - cf curl /v3/deployments/DEPLOYMENT-GUID/actions/continue" -X POST - ``` - Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the - CAPI procedure in [Deploy an app](#deploy). - -This continues the rolling deployment of the app. - -## Cancel a canary deployment - -To stop the deployment of an app that you pushed: - -* **For cf CLI v8+, run:** - - ``` - cf cancel-deployment APP-NAME - ``` - Where `APP-NAME` is the name of the app. - -* **For CAPI V3, run:** - - ``` - cf curl /v3/deployments/DEPLOYMENT-GUID/actions/cancel" -X POST - ``` - Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the - CAPI procedure in [Deploy an app](#deploy). - -This reverts the app to its state from before the deployment started by: -* Removing any deployment artifacts -* Resetting the `current_droplet` on the app - -

-Note -The cancel command is designed to remove the canary instance of the app.

-If this command is used after continue-deployment it will behave like a cancelation of a rolling deployment. - -## How it works - -This section describes the canary deployments and their limitations. - -### Canary deployment - -This section describes pushing an app with a canary deployment strategy. - -1. The `cf push APP-NAME --strategy canary` command: - 1. Stages the updated app package. - 2. Creates a droplet with the updated app package. - 3. Creates a deployment with the new droplet and any new configuration. -
- For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation. - -2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the -background, updating deployments as follows: - 1. Adds one instance of the new web process (the 'canary' instance). - * This process shares routes with the old process. - * Now, if you run `cf app` on your app, you see multiple `web` processes. - 1. Sets the deployment to `PAUSED`. - -3. After validating that the canary instance is running as expected execute the command `cf continue-deployment APP-NAME`: - 1. Changes the deployment reason to `DEPLOYING` and starts doing a rolling deployment - -4. After the command changes the status of the deployment, the `cc_deployment_updater` BOSH job runs in the -background, updating deployments as follows: - 1. Adds MaxInFlight number of instances (**by default it is 1**) of the new web process and removes MaxInFlight number of instance from the old web process. This step repeats until the new web process reaches the required number of instances. -

- Important - This happens only if all instances of the new web process are running.

- 2. Removes the old web process. The new web process now fully replaces the old web process. - 3. Restarts all non-web processes of the app. - 4. Sets the deployment to `DEPLOYED`. - -### Limitations - -The following table describes the limitations of when using canary deployments. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LimitationDescription
Multiple app versionsDuring a deployment, <%= vars.app_runtime_abbr %> serves both the old and new version of your app at the - same route. This can lead to user issues if you push backwards-incompatible API changes.
Database migrationsDeployments do not handle database migrations. Migrating an app database when the existing - app is not compatible with the migration can result in downtime.
Non-web processesCanary deployment will only create an instance of the web process.
QuotasPushing updates to your app using a deployment strategy creates up to `max_in_flight` new instances (defaults to 1) . If you lack sufficient quota, the deployment fails. Administrators might need to increase - quotas to accommodate deployments.
Simultaneous apps when interrupting a pushIf you push app before your previous push command for the same app has completed, your - first push gets interrupted. Until the last deployment completes, there might be many versions - of the app running at the same time. Eventually, the app runs the code from your most recent - push.
V3 APIsDuring a canary deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message - like Cannot scale this process while a deployment is in flight.. For more information, see Scale a process - or Update a process in the CAPI V3 documentation.
Evaluating the Canary Instance - Because the current processes share the same route, the best way to validate that traffic is reaching the canary instance by looking at the logs. - If app revision logging is enabled, the logs for all instances will be tagged with `process_id` and `revision_version` values. e.g. `APP/REV/4/PROC/WEB/1` - - Retrieve the logs by running the cf CLI command `cf logs APP_NAME`. -
New or stopped applications - When pushing an application for the first time, or if the app is stopped, no deployment strategy is used and all application instances are started immediately. -
- - -## View the status of canary deployments - -You can use CAPI to view the status of canary deployment. - -To view the status of a canary deployment: - -1. Log in to the cf CLI: - - ``` - cf login - ``` - -1. Find the GUID of your app by running: - - ``` - cf app APP-NAME --guid - ``` - Where `APP-NAME` is the name of the app. - -1. Find the deployment for that app by running: - - ``` - cf curl GET /v3/deployments?app_guids=APP-GUID&status_values=ACTIVE - ``` - Where `APP-GUID` is the GUID of the app. Deployments are listed in chronological order, with - the latest deployment displayed as the last in a list. - -1. Run: - - ``` - cf curl GET /v3/deployments/DEPLOYMENT-GUID - ``` - Where `DEPLOYMENT-GUID` is the GUID of the canary deployment. - -`cf curl GET /v3/deployments/DEPLOYMENT-GUID` returns these status properties for canary deployments: - -* `status.value`: Indicates if the deployment is `ACTIVE` or `FINALIZED`. - -* `status.reason`: Provides detail about the deployment status. - -* `status.details`: Provides the timestamp for the most recent successful health check. - The value of the `status.details` property can be `nil` with no successful health check - for the deployment. For example, there might be no successful health check if the deployment was - cancelled. - -The following table describes the possible values for the `status.value` and `status.reason` -properties: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
status.valuestatus.reasonDescription
ACTIVEDEPLOYINGThe deployment is deploying.
ACTIVEPAUSEDThe deployment is paused waiting for the user to continue with the deployment.
ACTIVECANCELLINGThe deployment is cancelling.
FINALIZEDDEPLOYEDThe deployment was deployed.
FINALIZEDCANCELLEDThe deployment was cancelled.
FINALIZEDSUPERSEDEDThe deployment was stopped and did not finish deploying because there was another - deployment created for the app. -
diff --git a/deploy-apps/rolling-deploy.html.md.erb b/deploy-apps/rolling-deploy.html.md.erb index 78b19c88..daae8b78 100644 --- a/deploy-apps/rolling-deploy.html.md.erb +++ b/deploy-apps/rolling-deploy.html.md.erb @@ -1,10 +1,10 @@ --- -title: Configuring rolling app deployments +title: Configuring app deployments owner: CAPI --- You can use Cloud Foundry Command Line Interface (cf CLI) commands -or the Cloud Foundry API (CAPI) to push your apps to <%= vars.app_runtime_first %> using a rolling deployment. +or the Cloud Foundry API (CAPI) to push your apps to <%= vars.app_runtime_first %> using a deployment. For information about the traditional method for addressing app downtime while pushing app updates, see [Using blue-green deployment to reduce downtime and risk](./blue-green.html). @@ -19,7 +19,143 @@ The procedures in this topic require one of the following: * **cf CLI v7 or later** -* **CAPI V3:** If you use CAPI V3, you must install the cf CLI. +* **CAPI V3:** If you use CAPI V3 API, you must install the cf CLI. + +For Canary Deployments: + +* **cf CLI v8.8.0 or later** + +* **CAPI V3.173.0 or later:** + +## How Deployment Strategies Work + +Cloud Foundry provides two different strategies for deployments: + +1. `rolling` - Rolling Deployments bring up one or more web processes (as defined by `max-in-flight`) at a time. Once those instances report healthy and routable, the deployment brings down an equivalent number instances of the old revision. The deployment repeats this process until all instances have been replaced, and finally replaces all old non-web processes with new processes before completing. +2. `canary` - Canary Deployments bring up a single web process of the new revision, then pause indefinitely. This gives the chance for app operators or developers to evaluate the health of a new revision. Once evaluated, app operators can choose to either `cancel` or `continue` the deployment. Once continued, the Canary Deployment proceeds similarly to a Rolling Deployment. + +This section describes the different deployment strategies and their limitations in detail. + +### Rolling Deployments + +This section describes pushing an app with a rolling deployment strategy. + +1. The `cf push APP-NAME --strategy rolling` command: + 1. Stages the updated app package. + 2. Creates a droplet with the updated app package. + 3. Creates a deployment with the new droplet and any new configuration. + * This starts up to `max_in_flight` processes that shares the route with the old process. + * Now, if you run `cf app` on your app, you see multiple `web` processes. +
+ For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation. + +2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the +background, updating deployments as follows: + 1. Adds up to `max_in_flight` instances of the new web process and removes instances from the old web process. This step repeats until the new web process reaches the required number of instances. +

+ This happens only if all instances of the new web process are running.

+ 2. Removes the old web process. The new web process now fully replaces the old web process. + 3. Restarts all non-web processes of the app. + 4. Sets the deployment to `DEPLOYED`. + +### Canary Deployments + +This section describes pushing an app with a canary deployment strategy. + +1. The `cf push APP-NAME --strategy canary` command: + 1. Stages the updated app package. + 2. Creates a droplet with the updated app package. + 3. Creates a deployment with the new droplet and any new configuration. +
+ For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation. + +2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the +background, updating deployments as follows: + 1. Adds one instance of the new web process (the 'canary' instance). + * This process shares routes with the old process. + * Now, if you run `cf app` on your app, you see multiple `web` processes. + 1. Sets the deployment to `PAUSED`. + +3. After validating that the canary instance is running as expected execute the command `cf continue-deployment APP-NAME`: + 1. Changes the deployment reason to `DEPLOYING` and resumes similarly to a rolling deployment + +4. After the command changes the status of the deployment, the `cc_deployment_updater` BOSH job runs in the +background, updating deployments as follows: + 1. Adds MaxInFlight number of instances (**by default it is 1**) of the new web process and removes MaxInFlight number of instance from the old web process. This step repeats until the new web process reaches the required number of instances. +

+ Important + This happens only if all instances of the new web process are running.

+ 2. Removes the old web process. The new web process now fully replaces the old web process. + 3. Restarts all non-web processes of the app. + 4. Sets the deployment to `DEPLOYED`. + +### Limitations + +The following table describes the limitations when using deployments. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LimitationDescription
Multiple app versionsDuring a deployment, <%= vars.app_runtime_abbr %> serves both the old and new version of your app at the + same route. This can lead to user issues if you push backwards-incompatible API changes.
Database migrationsDeployments do not handle database migrations. Migrating an app database when the existing + app is not compatible with the migration can result in downtime.
Non-web processesDeployments only run web processes through the update sequence described + earlier. The commands restart worker and other non-web processes in bulk after updating all web + processes.

+ The CAPI V3 API introduces the concept of processes as runnable units of an app. Each app has a + web process by default. You can specify additional processes with a Procfile, and in some cases + buildpacks create additional processes. For more information about processes, see + Processes in the CAPI V3 + documentation.
QuotasPushing updates to your app using a deployment strategy creates up to `max_in_flight` new instances (defaults to 1). + Additionally, Canary Deployments use an extra instance when pausing with the Canary Instance deployed. + If you lack sufficient quota, the deployment fails. Administrators might need to increase quotas to accommodate deployments. +
Simultaneous apps when interrupting a pushIf you push app before your previous push command for the same app has completed, your + first push gets interrupted. Until the last deployment completes, there might be many versions + of the app running at the same time. Eventually, the app runs the code from your most recent + push.
V3 APIsDuring a rolling deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message + like Cannot scale this process while a deployment is in flight.. For more information, see Scale a process + or Update a process in the CAPI V3 documentation.
New or stopped applications + When pushing an application for the first time, or if the app is stopped, no deployment strategy is used and all application instances are started immediately. +
Evaluating the Canary Instance + Because the current processes share the same route, the best way to validate that traffic is reaching the canary instance by looking at the logs. + If app revision logging is enabled, the logs for all instances will be tagged with `process_id` and `revision_version` values. e.g. `APP/REV/4/PROC/WEB/1` +
+
+ Retrieve the logs by running the cf CLI command `cf logs APP_NAME`. +
## Commands @@ -55,10 +191,11 @@ Review the limitations of this feature before running the command. For more info * **For cf CLI v8.8.0+ and CAPI V3.173.0 or later** Allows you to additionally specify the `--max-in-flight` property, run: ``` - cf push APP-NAME --strategy rolling --max-in-flight MAX_IN_FLIGHT + cf push APP-NAME --strategy STRATEGY --max-in-flight MAX_IN_FLIGHT ``` Where `APP-NAME` is the name that you want to give your app. - Where `MAX_IN_FLIGHT` specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `MAX_IN_FLIGHT` specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `STRATEGY` is the strategy you would like to use for the deployment. Valid strategies are `rolling` and `canary`. * **For CAPI V3:** 1. Log in to the cf CLI. @@ -141,7 +278,7 @@ Review the limitations of this feature before running the command. For more info 6. Deploy your app by running the following `curl` command with `POST /v3/deployments`. To verify the status of the deployment or take action on the deployment, record the deployment GUID from the output. - + ``` cf curl /v3/deployments \ -X POST \ @@ -150,7 +287,7 @@ Review the limitations of this feature before running the command. For more info "droplet": { "guid": "DROPLET-GUID" }, - "strategy": "rolling", + "strategy": STRATEGY, "options": { "max_in_flight": MAX_IN_FLIGHT }, @@ -164,11 +301,12 @@ Review the limitations of this feature before running the command. For more info }' ``` Where `DROPLET-GUID` and `APP-GUID` are the GUIDs that you recorded in earlier steps. - Where `MAX_IN_FLIGHT` is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `MAX_IN_FLIGHT` is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `STRATEGY` is the strategy you would like to use for the deployment. Valid strategies are `rolling` and `canary`. -For more information about this command, see [How it works](#how-it-works). +For more information about this command, see [How Deployment Strategies Work](#how-deployment-strategies-work). -### Cancel a deployment +### Cancel a Deployment To stop the deployment of an app that you pushed: @@ -198,6 +336,28 @@ The cancel command is designed to revert the app to its original state as quickly as possible and does not guarantee zero downtime. Additionally, changes to environment variables and service bindings will not be reverted.

+ +### Continue a Canary Deployment + +To finish a Canary Deployment after the deployment has paused and the Canary instance has been validated: + +* **For cf CLI v8+, run:** + + ``` + cf continue-deployment APP-NAME + ``` + Where `APP-NAME` is the name of the app. + +* **For CAPI V3, run:** + + ``` + cf curl /v3/deployments/DEPLOYMENT-GUID/actions/continue" -X POST + ``` + Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the + CAPI procedure in [Deploy an app](#deploy). + +This continues the rolling deployment of the app. + ### Restart an app To restart your app without downtime, run the appropriate command. Restart an app to apply @@ -206,17 +366,19 @@ configuration updates that require a restart, such as environment variables or s * **For cf CLI v7+, run:** ``` - cf restart APP-NAME --strategy rolling + cf restart APP-NAME --strategy STRATEGY ``` Where `APP-NAME` is the name of the app. + `STRATEGY` is the strategy you would like to use for the deployment. Valid strategies are `rolling` and `canary`. * **For cf CLI v8.8.0+ and CAPI V3.173.0 or later** Allows you to additionally specify the `--max-in-flight` property, run: ``` - cf restart APP-NAME --strategy rolling --max-in-flight MAX_IN_FLIGHT + cf restart APP-NAME --strategy STRATEGY --max-in-flight MAX_IN_FLIGHT ``` Where `APP-NAME` is the name of the app. - Where `MAX_IN_FLIGHT` specifies the maximum number of new instances to restart simultaneous until the deployment is complete. Optional and defaults to 1. + `MAX_IN_FLIGHT` specifies the maximum number of new instances to restart simultaneous until the deployment is complete. Optional and defaults to 1. + `STRATEGY` is the strategy you would like to use for the deployment. Valid strategies are `rolling` and `canary`. * **For CAPI V3, run:** @@ -226,112 +388,31 @@ configuration updates that require a restart, such as environment variables or s -H "Content-type: application/json" \ -d '{ "droplet": { - "guid": "DROPLET-GUID" + "guid": DROPLET-GUID }, - "strategy": "rolling", + "strategy": STRATEGY, "options": { "max_in_flight": MAX_IN_FLIGHT }, "relationships": { "app": { "data": { - "guid": "APP-GUID" + "guid": APP-GUID } } } }' ``` Where `DROPLET-GUID` and `APP-GUID` are the GUIDs that you recorded in earlier steps. - Where `MAX_IN_FLIGHT` is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `MAX_IN_FLIGHT` is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1. + `STRATEGY` is the strategy you would like to use for the deployment. Valid strategies are `rolling` and `canary`. -## How it works -This section describes the rolling deployments and their limitations. +## View the status of deployments -### Rolling deployment +You can use CAPI to view the status of deployments. -This section describes pushing an app with a rolling deployment strategy. - -1. The `cf push APP-NAME --strategy rolling` command: - 1. Stages the updated app package. - 2. Creates a droplet with the updated app package. - 3. Creates a deployment with the new droplet and any new configuration. - * This starts up to `max_in_flight` processes that shares the route with the old process. - * Now, if you run `cf app` on your app, you see multiple `web` processes. -
- For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation. - -2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the -background, updating deployments as follows: - 1. Adds up to `max_in_flight` instances of the new web process and removes instances from the old web process. This step repeats until the new web process reaches the required number of instances. -

- This happens only if all instances of the new web process are running.

- 2. Removes the old web process. The new web process now fully replaces the old web process. - 3. Restarts all non-web processes of the app. - 4. Sets the deployment to `DEPLOYED`. - -### Limitations - -The following table describes the limitations of when using rolling deployments. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LimitationDescription
Multiple app versionsDuring a deployment, <%= vars.app_runtime_abbr %> serves both the old and new version of your app at the - same route. This can lead to user issues if you push backwards-incompatible API changes.
Database migrationsDeployments do not handle database migrations. Migrating an app database when the existing - app is not compatible with the migration can result in downtime.
Non-web processesRolling deployments only run web processes through the rolling update sequence described - earlier. The commands restart worker and other non-web processes in bulk after updating all web - processes.

- The CAPI V3 API introduces the concept of processes as runnable units of an app. Each app has a - web process by default. You can specify additional processes with a Procfile, and in some cases - buildpacks create additional processes. For more information about processes, see - Processes in the CAPI V3 - documentation.
QuotasPushing updates to your app using a deployment strategy creates up to `max_in_flight` new instances (defaults to 1). - If you lack sufficient quota, the deployment fails. Administrators might need to increase quotas to accommodate deployments.
Simultaneous apps when interrupting a pushIf you push app before your previous push command for the same app has completed, your - first push gets interrupted. Until the last deployment completes, there might be many versions - of the app running at the same time. Eventually, the app runs the code from your most recent - push.
V3 APIsDuring a rolling deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message - like Cannot scale this process while a deployment is in flight.. For more information, see Scale a process - or Update a process in the CAPI V3 documentation.
New or stopped applications - When pushing an application for the first time, or if the app is stopped, no deployment strategy is used and all application instances are started immediately. -
- - -## View the status of rolling deployments - -You can use CAPI to view the status of rolling deployments. - -To view the status of a rolling deployment: +To view the status of a deployment: 1. Log in to the cf CLI: @@ -384,6 +465,11 @@ properties: DEPLOYING The deployment is deploying. + + ACTIVE + PAUSED + The deployment is paused waiting for the user to continue with the deployment. Only used for Canary Deployments. + ACTIVE CANCELLING