Rolling Back Updates

A deployment's release history is immutable, so you cannot delete or remove an update once it has been released. However, if you release an update that is broken or contains unintended features, it is easy to roll it back using the rollback command:

revopush rollback <appName> <deploymentName>
revopush rollback MyApp-iOS Production

This has the effect of creating a new release for the deployment that includes the exact same code and metadata as the version prior to the latest one. For example, imagine that you released the following updates to your app:

Release	Description	Mandatory
v1	Initial release!	Yes
v2	Added new feature	No
v3	Bug fixes	Yes

If you ran the rollback command on that deployment, a new release (v4) would be created that included the contents of the v2 release.

Release	Description	Mandatory
v1	Initial release!	Yes
v2	Added new feature	No
v3	Bug fixes	Yes
v4 (Rollback from v3 to v2)	Added new feature	No

End-users that had already acquired v3 would now be "moved back" to v2 when the app performs an update check. Additionally, any users that were still running v2, and therefore, had never acquired v3, wouldn't receive an update since they are already running the latest release (this is why our update check uses the package hash in addition to the release label).

If you would like to rollback a deployment to a release other than the previous (e.g. v3 -> v2), you can specify the optional --targetRelease parameter:

revopush rollback MyApp-iOS Production --targetRelease v34

NOTE: The release produced by a rollback will be annotated in the output of the deployment history command to help identify them more easily.