Merge pull request #215915 from anthonychu/patch-13

[Container Apps] Add zero downtime section to app lifecycle

Author: v-regandowner

articles/container-apps/application-lifecycle-management.md

@@ -5,7 +5,7 @@ services: container-apps
 author: craigshoemaker
 ms.service: container-apps
 ms.topic: conceptual
-ms.date: 11/02/2021
+ms.date: 10/25/2022
 ms.author: cshoe
 ms.custom: ignite-fall-2021, event-tier1-build-2022
 ---
@@ -16,7 +16,7 @@ The Azure Container Apps application lifecycle revolves around [revisions](revis
 
 When you deploy a container app, the first revision is automatically created. [More revisions are created](revisions.md) as [containers](containers.md) change, or any adjustments are made to the `template` section of the configuration.
 
-A container app flows through three phases: deployment, update, and deactivation.
+A container app flows through four phases: deployment, update, deactivation, and shutdown.
 
 ## Deployment
 
@@ -26,10 +26,19 @@ As a container app is deployed, the first revision is automatically created.
 
 ## Update
 
-As a container app is updated with a [revision scope-change](revisions.md#revision-scope-changes), a new revision is created. You can choose whether to [automatically deactivate old revisions, or allow them to remain available](revisions.md).
+As a container app is updated with a [revision scope-change](revisions.md#revision-scope-changes), a new revision is created. You can [choose](revisions.md#revision-modes) whether to automatically deactivate old revisions (single revision mode), or allow them to remain available (multiple revision mode).
 
 :::image type="content" source="media/application-lifecycle-management/azure-container-apps-lifecycle-update.png" alt-text="Azure Container Apps: Update phase":::
 
+### Zero downtime deployment
+
+In single revision mode, Container Apps automatically ensures your app does not experience downtime when creating new a revision. The existing active revision is not deactivated until the new revision is ready. If ingress is enabled, the existing revision will continue to receive 100% of the traffic until the new revision is ready.
+
+> [!NOTE]
+> A new revision is considered ready when one of its replicas starts and becomes ready. A replica is ready when all of its containers start and pass their [startup and readiness probes](./health-probes.md).
+
+In multiple revision mode, you control when revisions are activated or deactivated and which revisions receive ingress traffic. If a [traffic splitting rule](./revisions-manage.md#traffic-splitting) is configured with `latestRevision` set to `true`, traffic does not switch to the latest revision until it is ready.
+
 ## Deactivate
 
 Once a revision is no longer needed, you can deactivate a revision with the option to reactivate later. During deactivation, containers in the revision are [shut down](#shutdown).

articles/container-apps/health-probes.md

@@ -6,7 +6,7 @@ author: craigshoemaker
 ms.service: container-apps
 ms.custom: event-tier1-build-2022, ignite-2022
 ms.topic: conceptual
-ms.date: 03/30/2022
+ms.date: 10/28/2022
 ms.author: cshoe
 ---
 
@@ -158,7 +158,15 @@ The optional `failureThreshold` setting defines the number of attempts Container
 
 ## Default configuration
 
-Container Apps offers default probe settings if no probes are defined. If your app takes an extended amount of time to start, which is very common in Java, you often need to customize the probes so your container won't crash.
+If ingress is enabled, the following default probes are automatically added to the main app container if none is defined for each type.
+
+| Probe type | Default values |
+| -- | -- |
+| Startup | Protocol: TCP<br>Port: ingress target port<br>Timeout: 1 second<br>Period: 1 second<br>Initial delay: 1 second<br>Success threshold: 1<br>Failure threshold: `timeoutSeconds` |
+| Readiness | Protocol: TCP<br>Port: ingress target port<br>Timeout: 5 seconds<br>Period: 5 seconds<br>Initial delay: 3 seconds<br>Success threshold: 1<br>Failure threshold: `timeoutSeconds / 5` |
+| Liveness | Protocol: TCP<br>Port: ingress target port |
+
+If your app takes an extended amount of time to start, which is very common in Java, you often need to customize the probes so your container won't crash.
 
 The following example demonstrates how to configure the liveness and readiness probes in order to extend the startup times.
 

articles/container-apps/revisions-manage.md

@@ -297,6 +297,8 @@ az containerapp revision set-mode `
 
 Applied by assigning percentage values, you can decide how to balance traffic among different revisions. Traffic splitting rules are assigned by setting weights to different revisions.
 
+To create a traffic rule that always routes traffic to the latest revision, set its `latestRevision` property to `true` and don't set `revisionName`. 
+
 The following example shows how to split traffic between three revisions. 
 
 ```json

articles/container-apps/revisions.md

@@ -105,7 +105,7 @@ The revision mode controls whether only a single revision or multiple revisions
 
 ### Single revision mode
 
-By default, a container app is in *single revision mode*. In this mode, only one revision is active at a time. When a new revision is created, the latest revision replaces the active revision.
+By default, a container app is in *single revision mode*. In this mode, when a new revision is created, the latest revision replaces the active revision. For more information, see [Zero downtime deployment](./application-lifecycle-management.md#zero-downtime-deployment).
 
 ### Multiple revision mode