Resolution: Won't Do
Affects Version/s: None
Fix Version/s: None
Epic Name:Control commit during update
Market Goal:* Support mission-critical environments requiring more control of version consistency
Risk & mitigation:TBD
Epic Total Estimate:0
The update commit stage is the last one that happens as part of the update. If the update commit has conditions that fail then the client will attempt to roll back the update. So this is typically where you include state scripts that verify the device is healthy after the update (e.g. device UI is running, it can talk to the backend, etc.).
A use case for environments where the update process is more controlled is to ensure that all devices succeed the update, otherwise they all roll back. This way the software version running on all the devices is consistent (the same), which is important in environments where devices are communicating and they could have incompatible changes between versions (such as protocol changes).
User value (why)
- Guaranteed consistent version across the devices leads to lower risk of incompatibility issues causing downtime
- Required for compliance in certain industries, especially Transportation (Boats, Airlines, Trucks) where there are many devices in one site (e.g. Boat) that need to be consistent
- It is possible to enable waiting for commit in a deployment
- If waiting for commit is enabled, the devices do not commit the update automatically
- During the deployment it is possible to 1) commit or 2) abort the deployment for all included devices at any time
- If the user chooses to commit the deployment, all devices waiting for commit will commit it (i.e. make it permanent) and those not yet started will automatically commit it once they get to this stage
- If the user chooses to abort the deployment, all the devices roll back to the previously committed version (when they reach the Commit_Enter stage)
- This feature is only available in Enterprise plan (not Professional, Open Source/Starter)
Future notes (not in scope for this Epic, just for planning purposes)
- This is tied to Phased rollout in that if something fails within a phase you might want to roll back the entire phase, as well as abort the phased rollout (so it does not proceed to the next phase)
- Does this relate to client side API and supporting update acceptance in the device UI itself? In this use case, the user of the device has the option to accept the new version of the device, but if it is found to be buggy or hard to use after a few days, the user may choose to roll back the update altogether.