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 Timestamp | Step | Notes |
|---|---|---|
| Day 1 | Prepare release artifacts | Ideally generated by CI, and tagged in version control |
| Day 1 | Create OTA Release in Memfault | |
| Day 1 | Upload release artifacts to Memfault | |
| Day 1 | Select a set of devices for a | A small (5-10 devices) cohort in a controlled setting, eg in a test lab |
| Day 1 | Deploy the | |
| Day 1 | Verify the canary OTA release cohort is working as expected | |
| Day 1 | Deploy the OTA release to the remaining devices, staged rollout at 5% | |
| Day 1 | Verify the OTA release is working as expected | |
skipped | If the OTA release is not working as expected, abort the release | 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 5 | After 2 days, rollout to 50% | |
| Day 7 | After 2 days, rollout to 100% | |
| Day 9 | If everything is running smoothly, OTA deployment is complete |