From notes in {T109512#1611078}

Rollback

A rollback is an automatically detected failure, any failure that requires some human interaction would require a deploy to a specific revision. This is due to the ambiguity of expected behaviors in a rollback scenario.

The capistrano method for rollbacks and deploys seems sane and would make a rollback almost instantaneous, that is, having the actual deployed code be a symlink to a directory containing the currently deployed checkout, and simply creating a new directory and swapping symlinks as part of the deploy procedure. This allows a rollback (or a deploy) to happen as quickly as a symlink swap.

Rollback Steps:

1. Use git rev-parse to determine the SHA1 of a revision inside of main.py's Deploy class—make targets ignorant of tags, HEADs, refs, etc
2. Passing the SHA1 off to the targets which use git new-workdir to create a new working copy of the repo from a cache directory
3. The new working copy is created in a directory named after the SHA1
4. At the start of deploy-local on a given target, create a file called .in-progress at the same level as the cache directory containing the SHA1 to be deployed
5. At the end of Deploy loop through all targets again to mv .in-progress .done
6. If a failure is detected during a deploy, a rollback to the revision specified in .done (i.e., verifying the current symlink points to a directory named after the SHA1 inside .done) should represent the state the target repository was in pre-deploy