Roll back

Run a rollback

From the app's folder, on a machine with the project's key:

mybeast-deploy rollback --app shop --env production -- make rollback:production

With a rollback command saved in the app's settings, leave out everything after --: mybeast-deploy shows the command and asks first. The rollback is reported as Rollback #13, numbered with the app's deploys, with its log, who ran it and how it ended.

Deploys goes back nothing by itself: your script does the going back, as it always has. A rollback that succeeds becomes what is live in the environment; one that fails is told to the project's people, like a failed deploy.

Where it goes

Without --to, a rollback goes to the good deploy before what is live, the one a script's make rollback goes back to as a rule. When what is live is itself a rollback, it goes to the good deploy before the one that rollback went back to: a second rollback goes back one release further.

Your script still chooses. When its log names the release it went to, and the app's release line finds it, the rollback is recorded as going there. When Deploys has seen no good deploy before what is live, the page says the script chooses the release.

Go back to a release

--to RELEASE names where it goes. The command gets RELEASE=<release> in its environment, and the rollback is recorded as going to the good deploy of that release:

mybeast-deploy rollback --app shop --env production --to 20261026-101010-abc1234 -- make rollback

A Makefile reads it as any other variable:

rollback:
	./deploy/rollback.sh $(RELEASE)

A release is 1 to 64 letters, digits and . _ + -. The rollback card gives the --to line ready to copy when the deploy it goes back to has a release.

When the pages offer it

On an app's page, Live now says for each environment where a rollback would go, how long that was live, and gives the command to copy. The card Roll back production comes first, on the app's page and on the deploy's, when:

• the last deploy there failed or was lost, so what is live may be half of it, or
• in a production environment, an incident began within 6 hours of what is live going live, while it was live, as Incidents says.

It is not offered first after a rollback: going back from going back is no answer.

What is recorded

• Went back to: the deploy whose release it went to. Its commit is that deploy's, not the checkout's.
• Release: the one --to named, else the one its log names, else the release of the deploy it went back to.
• Nothing in Errors: going back is not a fix, so Errors' “it's fixed” notices wait for the next good deploy. See Name each release in Errors.