Rollback

Overview

Deployments come in two modes, Standard deploy and Custom deploy, and each has its own rollback behaviour.

Standard deploy

Whether a rollback is possible depends on the Versions setting of the deploy configuration; versions beyond that limit cannot be rolled back to. A rollback works as follows:

1. Click Rollback on a deploy request, choose the version to roll back to (the choice is limited by the versions kept) and the target hosts. Spug creates a new request whose title contains Rollback.
2. Open that request; approve it first if review is enabled, otherwise click deploy directly.
3. The rollback skips the checkout hooks and runs only the before / after deploy hooks on the hosts, using the version stored on the hosts.

Use the built-in variable SPUG_DEPLOY_TYPE in Before deploy on host and After deploy on host to behave differently during a rollback.

Custom deploy

Custom deploys are fully under your control, so Spug cannot restrict or interfere with rollbacks. The flow is:

1. As with standard deploys, click Rollback and choose the version; Spug creates a new request with Rollback in the title based on that version.
2. Open that request; approve it first if review is enabled, otherwise click deploy directly.
3. The rollback behaves exactly like a deploy and runs all actions in order; SPUG_RELEASE and the other variables come from the request you roll back to.

Use the built-in variable SPUG_DEPLOY_TYPE in your actions to behave differently during a rollback.

Controlling behaviour

SPUG_DEPLOY_TYPE distinguishes normal deploys from rollbacks: 1 is a normal deploy, 2 a rollback and 3 a webhook-triggered deploy. For example:

if [ "$SPUG_DEPLOY_TYPE" = "1" ]; then
    echo "normal deploy steps..."
elif [ "$SPUG_DEPLOY_TYPE" = "2" ]; then
    echo "only runs during a rollback"
fi