Zero Downtime deployment for single and multiple revsions - microsoft/azure-container-apps GitHub Wiki

Q: How to use ACA native zero downtime deployment?

A: There is a property on the container app called latestRevisionName. The value in that property is the name of latest created revision. It was also the same revision referred to in the ingress section when you use latestRevision: true. e.g: the default

{
  "latestRevision": true,
  "weight": 100
}

latestRevisionName still is the latest created revision name. There will be a new property latestReadyRevisionName (once 2022-10-01 is available). latestRevision: true in traffic now refers to the latestReadyRevisionName instead of latestRevisionName (aka: latest created revision)

The latest created revision becomes the latest ready revision once it passes its probes at least once.

For example, if you have an app foo with a first revision being created on app creation foo--rev1:

  1. latestRevisionName == foo--rev1 and latestReadyRevisionName == foo--rev1 Since rev1 this is the first/only revision created.

  2. Create foo--rev2:
    latestRevisionName == foo--rev2, but latestReadyRevisionName == foo--rev1. While waiting for --rev2 to pass its probes.

  3. if:

    • rev2 never passes its probes, it never becomes latestReadyRevisionName and never gets traffic.
    • rev2 passes its probes 2 minutes later, it becomes latestReadyRevisionName 2 minutes later and traffic goes to it.

TL;DR:

When you assign traffic to latestRevision: true (which is the default of 100% to latestRevision: true), you're assigning traffic to the latest created revision that has passed its probes at least once. As opposed to just the latest created revision (as it used to be).

In bicep: latestRevisionName still has the same semantics it always had (i.e: the name of the latest created revision) with 2022-10-01, there will be the new latestReadyRevisionName. Depending on what you're doing in bicep, you can use either.