Deployments view¶
Where rollouts live.
Listing¶
The Deployments page lists every deployment, newest first and filterable by state, showing the artifact build number, audience summary (named channels and groups, or every active device when neither axis is set), strategy, percentage, state and creation time.
The project page carries a summary card. Active and paused deployments always appear there, however much history sits above them, because a live rollout should never be below the fold.
A deployment is in one of five states: draft, active, paused,
completed or cancelled. See
Deployments for what each one means for the
devices checking in.
Detail page¶
The rollout cards refresh on their own, every few seconds, without a page reload. They are labeled Check-ins only. Each number counts devices that have checked in for this deployment. Expected rows in the Devices table are not included.
- Eligible: check-ins with the eligible flag set.
- Assigned: check-ins inside the cohort.
- In progress: assigned check-ins that have been offered and have not reached a terminal status.
- Confirmed: check-ins that confirmed the new build.
- Failed / RB: check-ins that failed or rolled back.
- Success rate: the percentage of terminal check-ins that confirmed. The card shows n/a when no check-in is terminal.
The progress bar counts the same check-ins. The funnel counts check-ins that reported each stage.
Controls¶
Which controls appear depends on the state. Everything else about a deployment is immutable: to change the audience or the artifact, create a new one.
| Control | Shown when | Effect |
|---|---|---|
| Start | draft |
Begins offering the build. |
| Resume | paused |
Same button, resumes offering. |
| Pause | active |
Stops offering immediately. |
| Complete | active or paused |
Retires the deployment as finished. |
| Cancel | anything not already completed or cancelled |
Retires it as abandoned. |
| Ramp | active or paused, canary only |
Raises the rollout percentage. |
Two things worth knowing:
- The dashboard shows the rollout control for canary deployments only.
An
immediatedeployment goes to its full audience when it starts, so there is nothing to ramp. The API is looser:{"action": "ramp"}raises the percentage on any deployment, whatever its strategy or state. - Ramping only goes up. A percentage below the current one is refused, in the dashboard and the API alike, so you cannot accidentally shrink a rollout that devices have already been offered. Pause instead.
- Cancel works at any percentage, including 100%, for as long as the deployment is live. It is the stop button for a bad build.
Devices table¶
The Devices table on the deployment page lists devices that have checked in for this deployment. On a draft or active deployment it also lists active devices that are in the audience, compatible with this build, and have no check-in yet.
Checked-in rows show the status the device reported. A matching device with no check-in shows Expected. Expected means the device is in the audience, compatible with this build, and has no check-in yet.
On a draft or active deployment whose rollout percentage is below 100%, the Devices card also says how that percentage limits the offer. At 0% it says no device is in the rollout, so a check-in does not offer this build. From 1% through 99% it says only part of these devices is in the rollout, and a check-in offers this build only while the deployment is active, and only to that part.
Checked-in rows are listed above expected rows. The status menu includes Expected on draft and active deployments. Search matches the device id. The table shows 25 devices per page.
From build on an Expected row is the device's current build when the list loads. An empty current build is shown as a dash. A checked-in row shows the previous build stored on its device state. An offer writes the device's current build when that field is empty. A status report writes it when that report creates the row. From is the device build recorded when this deployment offered the update. It does not change if the device reports a different build later. (none) means no build was recorded. A stored 0 also shows as (none).
Expected rows are read from the audience when the page loads. They are not saved as deployment device state. An empty audience includes every active device in the project, and the artifact has to be compatible with that device (framework, chip, board, hardware revision, partition profile, NVS schema, and security mode). Groups are a union, channels are a union, and the two axes intersect. Inactive devices are left out, as are devices outside the audience or incompatible with the artifact. Draft and active deployments both show this set. The list is read-only.
The Timeline button on a checked-in row opens that device's reported stages. The reported reason and timestamp stay on the row. Expected rows have no timeline.
On a draft or active deployment, with every status selected or with the Expected status selected, the list footer says how many rows are checked in and how many are expected. That line is shown even when the rows fit on one page. Search narrows both numbers to device ids that match. A check-in status filter leaves Expected rows out. Paused, completed, and cancelled deployments do too. When one of those lists spans more than one page, the footer counts the check-ins on it as a device total.