Single-tenant release tracking

Fleet Release Parity

Every production deployment Azure DevOps recorded in the last 120 days, for the applications that ship one image to more than one customer environment.

Applications
23
In the release cycle
63
Up to date
3
Behind general
24
On their own build
6
In soak now
9
Ready to promote
11

Read from Azure DevOps release records on 27 October 2026 at 11:08. 289 deployments. 2 releases rolled back, 83 replaced before finishing soak. Nothing here is read from a cluster.

How to read this

In soak

In general now, and has not yet been there two full days. It cannot go to a customer until it has. Weekends count.

Ready to promote

It completed its two days in general, and it is the newest release that did. This is the one that goes out at the next opportunity.

Promoted

At least one customer is running it.

Superseded

It completed its soak, but a newer release did too, so it will never be sent. Only the newest qualified release goes out - sending an older one would be shipping code we already know is behind.

Replaced too soon

It was replaced in general before finishing two days, so it never qualified and never will. This is the soak doing its job: a release that lasted hours was probably replaced for a reason.

Rolled back

General moved from it to an older version. Whatever we rolled back from is disqualified permanently and can never be promoted.

Up to date

Running the same version as its general environment.

Behind

General has moved on. The number is how many distinct versions general has released since the one this environment is on.

Own build

Running a version general never released - usually a fix applied straight to that customer. Automatic promotion must skip these rather than overwrite someone's fix, so they are flagged and left alone.

Can't compare

The version here is older than the earliest general release on record, so there is no way to tell whether general once released it or whether it was built for this customer. Reported as unknown rather than guessed at. More history fixes it.

A blank grey square

The application does not deploy to that customer at all - there is no stage for it. The column is only there because other applications do deploy to that customer. Nothing to act on.

Never deployed to

Shown hatched. The stage exists in the release pipeline but has never once been deployed to. Not drift - either the customer is served another way, or the stage is left over and unused. Worth tidying, but nothing is behind.

No recent deployment

It has been deployed to before, but nothing has landed inside the window shown.

An attempt did not land

Marked with ! on the grid. A release was tried and did not take effect - stopped before deploying, or refused by the target. Either way the environment kept running what it had, so this is a note about the pipeline rather than the environment's state.

No general stage

This application deploys only to named customers and has no shared general environment. There is nothing to soak a release against, so it cannot be promoted automatically as things stand.

Source: the Azure DevOps release API, read only. An environment is called "behind" by counting the distinct versions general has run since the one it is on, within the 120-day window above - a longer window can only reveal more history, never less.