Rollback

Rollback reverts all changes made by a deployed release, restoring entities to their state before the deployment. Whether something went wrong or a promotion has ended, rollback gives you a clean way to undo a release.

How rollback works

When a release is deployed, MageDrop captures a rollback snapshot — the current value of every field that's about to be changed. This snapshot is taken at deploy time, not when the change was originally staged.

When you trigger a rollback, MageDrop:

1. Reads the rollback snapshot for every entity in the release.
2. Sends PUT requests to the Magento REST API, restoring each field to its snapshot value.
3. Updates the release status to Rolled Back.

Why deploy-time, not staging-time?

Consider this scenario:

1. You stage a CMS page title change from "Welcome" to "Summer Sale" on Monday.
2. On Wednesday, someone manually updates the title to "Spring Collection" via Magento admin.
3. On Friday, you deploy the release. At deploy time, MageDrop captures "Spring Collection" as the current value.
4. If you roll back, the title is restored to "Spring Collection" (the deploy-time value), not "Welcome" (the staging-time value).

This approach ensures that rollback restores the actual state of the store as it was immediately before the release went live, accounting for any interim changes.

Manual rollback

To manually roll back a live release:

1. In the MageDrop dashboard, navigate to the release.
2. The release must be in Live or Failed status.
3. Click the Rollback button.
4. A confirmation dialog will appear — confirm to proceed.
5. MageDrop restores all entities to their pre-deploy values.
6. The release status changes to Rolled Back.

Automatic rollback (end date)

If you set a Scheduled End date on a release, the rollback happens automatically:

• The MageDrop cron checks every minute for live releases whose end date has passed.
• When the end date is reached, the rollback process runs automatically.
• The release status changes to Rolled Back.
• No manual intervention is needed.

See Scheduling Releases for more on setting up auto-rollback with end dates.

What gets rolled back

Rollback restores every field that was changed by the release. If a release changed the title and content of a CMS page, both fields are restored. Fields that weren't part of the release are untouched.

Handling interim changes

A common concern: what if someone edits an entity after the release was deployed, and then you roll back?

Rollback will overwrite those interim changes for the affected fields. For example:

1. Release deploys, changing a CMS page's title from "Spring Collection" to "Summer Sale".
2. After deployment, someone manually changes the page's meta description in Magento admin.
3. You roll back the release.
4. The title is restored to "Spring Collection" (the release changed this field).
5. The meta description is not affected (the release didn't change this field — the manual edit is preserved).

Rollback only touches fields that were part of the release. However, if someone manually changed the same field that the release modified, that manual change will be overwritten by the rollback snapshot value.

What happens if rollback fails

If the rollback encounters an error (e.g. network issue, API authentication failure, invalid data):

• The release status changes to Failed.
• The activity log shows which entity's rollback failed and the error details.
• Entities that were successfully rolled back remain rolled back.
• You can fix the underlying issue and click Retry Rollback.
• If the issue can't be resolved automatically, you may need to manually restore the affected entities in Magento admin using the snapshot values shown in the release's activity log.

Rollback is one-way

Once rolled back, a release cannot be re-deployed. If you need to re-apply the same changes, create a new release and stage the changes again. This prevents accidental double-deployments and keeps the release history clean.

Best practices

• Use end dates for promotions. If you know when a promotion should end, set the end date when scheduling. This eliminates the risk of forgetting to roll back.
• Review before rolling back. Check the release's staged changes in the dashboard to understand what will be reverted.
• Check the activity log. After a rollback, verify in the activity log that all entities were successfully restored.
• Don't rely on rollback as an undo. Rollback restores deploy-time values. If significant time has passed and many manual changes have been made, review the current state before rolling back.