Rollouts & rolling back
Control which devices get a patch, and pull it back if something goes wrong. Everything here works from the CLI and from the console.
Staged rollouts
Publish a patch to a share of devices:
$ overpush patch android --rollout-percent 10
$ overpush patch ios --rollout-percent 10
Which devices are in the rollout stays the same over time, so:
- A device that got the patch at 10% keeps it at 50%.
- Raising the percentage only adds devices. No device that already has the patch loses it.
Changing the percentage
$ overpush patches rollout 4 --percent 50 $ overpush patches rollout 4 --percent 100
Devices see the new percentage the next time they check for a patch, which is at launch. In the console, open the release, then ⋮ → Change rollout on the active patch.
Setting the percentage back to 0 stops new devices from getting the patch, but devices that already have it keep it. To remove it from devices, revoke it.
Revoking a patch
Revoking is the kill switch. It tells every device to stop using the patch:
$ overpush patches revoke 4 --reason "checkout total wrong"
On their next launch, devices see that the patch is revoked, delete it, and run the release's original code.
In the console: open the release, then ⋮ → Roll back on the patch. The reason you give shows in the patch list and the activity log.
- No signing key needed. Anyone on the team with the developer role or higher can stop a patch, from the console or any computer that's logged in.
- Not instant. A device finds out when the app next starts. An app that's already running with the patch keeps running it until it's fully closed.
- Only the live patch. You can revoke the patch devices are currently being served.
Rolling forward
Rolled a patch back by mistake, or fixed what was wrong on the server side? In the console, turn on Show rolled back, then ⋮ → Roll forward on the patch. Devices take it again on their next launch.
Only the newest patch of a release can be rolled forward. If a newer patch exists, devices already get that one.
Going back to an earlier patch
If patch 4 is bad but patch 3 was fine, serve patch 3's code again:
$ overpush patches rollback --to 3
This publishes patch 3's code under a new, higher patch number, so devices that already have patch 4 also move off it. That's how patch numbers can keep going up even when the code goes back.
Which should I use?
| Situation | Use |
|---|---|
| Want to see how a patch behaves first | --rollout-percent 5, then patches rollout |
| Patch is bad, the release's own code is fine | patches revoke |
| Patch is bad, the previous patch was fine | patches rollback --to N |
| Patch crashes on startup | Nothing. Devices roll back by themselves. Then revoke it so no other devices try it. |