Skip to main content

OTA - Deploying an Update to Production

OTA Release Rollout Process Recommendations

Memfault recommends setting up an OTA release process/checklist before deploying OTA. This will help ensure that OTA releases are deployed in a consistent and auditable manner, and provide a ready to go sequence in case a rollback is required.

An example OTA release process is as follows (only for illustrative purposes, a release checklist will be highly dependent on the specific device and use case):

Completed TimestampStepNotes
Day 1

Prepare release artifacts

Ideally generated by CI, and tagged in version control
Day 1Create an OTA Release in Memfault
Day 1Upload release artifacts to Memfault
Day 1

Select a set of devices for a canary OTA release Cohort

A small (5-10 devices) Cohort in a controlled setting, eg in a test lab

Day 1

Deploy the canary OTA release Cohort

Day 1Verify the canary OTA release Cohort is working as expected

Review Device Coverage and Device Vitals on Release Health, then investigate individual devices on Target Devices.

Day 1

Deploy the OTA release to the remaining devices, staged rollout at 5%

Day 1Verify the OTA release is working as expected

Compare Device Vitals before and after the update and investigate devices that are not on the target version.

skipped

If the OTA release is not working as expected, abort its activation

Use Activation by Cohort → Abort. If necessary, trigger rollback logic on the already updated devices.

Day 3

If the OTA release is working as expected, continue to rollout to 25% after 2 days

Day 5After 2 days, rollout to 50%
Day 7After 2 days, rollout to 100%
Day 9If everything is running smoothly, OTA deployment is complete

Monitoring Each Rollout Stage

Before increasing a staged rollout, open the Release in Memfault and review:

  • Release Health for adoption and Device Vital regressions.
  • Target Devices for devices that have or have not reported the target Software Version.

See Release Details for more information.