Documentation

Appearance

How should I stage a RAUC rollout across production devices? ​

Do not use the whole fleet to discover whether a new image works in the field.

RAUC can protect an individual device from many classes of failed update. That does not make an unbounded fleet rollout safe.

RAUC protects the device. A rollout strategy protects the fleet.

A release can install correctly, boot correctly, and still contain an application defect that only appears with a particular hardware revision, peripheral, customer network, or real workload.

Start before the rollout button ​

Before targeting production, test the actual product image on representative hardware: bootloader, partition layout, persistent data mount, peripherals, and normal workload.

Pay particular attention to persistent data. A/B rollback restores the previous root filesystem, but persistent files or databases may have been changed by the newer release. A boot-safe rollback design does not automatically make application data backward-compatible.

For Dataplicity-managed RAUC, the Device Class must first satisfy the RAUC image OTA requirements, including physical failed-boot rollback validation for the exact board, bootloader, and image-layout revision you ship.

Use an explicit first cohort ​

The first production cohort should be small, deliberate, and identifiable.

Good canaries are devices where:

  • the hardware configuration is understood;
  • the workload is representative;
  • support can reach the customer if necessary;
  • failure will not create an unacceptable operational consequence.

Avoid using "whatever devices happen to be online" as the canary definition.

A typical release may look like:

text
lab hardware
    ↓
10 production canaries
    ↓
50-device cohort
    ↓
25% of eligible fleet
    ↓
remaining eligible fleet

The numbers are product-specific. The principle is that each expansion is a conscious decision.

Dataplicity image rollouts use device tags for cohort targeting, so hardware revision, site, region, customer type, or a dedicated canary tag can define the wave.

Advance on outcomes, not time alone ​

A wave should not advance just because a fixed number of hours has elapsed.

You need enough observed outcome data to make the next decision. At minimum distinguish:

  • targeted;
  • downloading / installing;
  • booted into the intended image;
  • awaiting validation;
  • succeeded / marked good;
  • rolled back;
  • failed before boot;
  • failed validation;
  • offline / outcome unknown.

For example:

text
100 targeted
58 succeeded
2 rolled back
0 other known failures
40 outcome unknown

That is not a 96.7% successful rollout. Forty percent of the population has not yet produced a known outcome.

The denominator is part of the result.

Define stop conditions before production ​

Decide what should pause the rollout before you need to make the decision under pressure.

Some conditions are deterministic enough to automate. Confirmed validation failures or RAUC rollback rates crossing a defined threshold are direct evidence that the rollout is not behaving as intended.

Dataplicity records those outcomes as durable rollout facts and can auto-pause on deterministic rollback / validation-failure thresholds. The pause reason is auditable and the system does not automatically resume the rollout.

Other signals require more interpretation. A new application failure, reboot-rate increase, or reliability Issue concentrated in the new release can strongly suggest a regression, but correlation should not casually be presented as proof of causation.

That is why deterministic RAUC outcome truth and broader Pulse / Reliability release-health evidence are kept separate.

Do not automatically resume ​

Automatic pause and automatic resume are not symmetrical.

Pausing limits potential damage. Automatically resuming because a metric later drops below a threshold can expand a release before anyone understands what happened.

Before continuing, the operator should be able to answer:

  • What failed?
  • Which devices were affected?
  • What was the denominator?
  • Is the problem concentrated in a hardware or customer cohort?
  • Is the failure understood well enough to expand the release?

Keep OS and application releases separate where useful ​

The operating-system image and the product application do not necessarily need the same release lifecycle.

Dataplicity keeps OS images and Containers / Class Software as separate version lines and pins. That lets an OEM run a conservative OS-image programme while shipping application changes at a different cadence.

A security-driven base-image release may warrant a different canary and soak policy from a weekly application release.

Do not collapse them into one version number simply because it looks simpler in a dashboard.

A rollout is complete when the state is understood ​

The release is not complete when the last command is sent.

It is operationally complete when the eligible fleet has converged to an understood state:

text
expected release
+
known successful validation
+
known exceptions
+
known offline population
+
no unexplained rollback concentration
+
acceptable post-release health

Some devices may remain offline for days. That is normal for many field fleets. They should remain pending or unknown, not silently improve the success percentage.

A green dashboard is not the success criterion. Success means knowing enough to decide whether the next device should receive the release.