You need to know which revisions of your project are undeployed, and which of those are deployable, so you know what you need to rollout.
This app helps you do that.
For each tracked project the undeployed revisions will be listed. For each you can say whether the revision is deployable or not. The app then tells you which set of revisions you can deploy.
Once you've done a deploy you can update the deployed revision, and the list will adjust to show you only the undeployed revisions.
When a revision is in the trunk of your branch you want to roll it out as quickly as possible, because it is holding up deployment of any subsequent revisions.
If you rollback a revision because it doesn't do what it is supposed to, then you hold up all the subsequent revisions until your fix lands, and is deemed deployable.
If instead you only rollback revisions when they will break production you can deploy more frequently. Yes, you will sometimes be deploying bug fixes that don't fix the bug in question, but there's no real harm in that.
Breaking production means something like corrupting data, or causing a degraded experience for users. If the only effect of a mistake in the revision is that the same bug that existed before will continue to exist then you haven't made things worse.
Therefore, when you are checking the deployability of a revision, ask yourself not "Does this do what was intended?", but rather "Will this break production?". If the answer to the latter is "no" then you should deploy it, and work on another revision to do what was intended. The fact that the bug isn't fixed should be tracked in the bug tracker rather than here.
A corollary to this is that you should design revisions such that if they don't work as intended they won't break production. This may involve things like hiding changes behind a feature flag so that enabling them is distinct from deploying them.
When a revision is undeployable it needs to be fixed in some way. We don't want to remove the revision from history, as that causes a problem for distributed version control. Instead we want to add another revision that corrects the problem.
That revision can either undo the changes made by the first, or it could correct the problem. You generally want to pick whichever will be faster to land.
Once the new revision has landed and is displayed on the list of undeployed revisions you can amend the broken revision to indicate that the new one is a rollback for it. The system will then only suggest that both are deployed together, and only once the rollback revision is deemed deployable.
If you need to you can chain rollbacks.
Of course! If you select a revision you can use the following shortcuts: