How do I rollback a deployment?

Rolling back your deployment

There can be situations where you need to revert your remote server to a previous state/commit. If you use DeployBot's deployment tools this is really simple. One way is to use Rollback to button near on your successful deployments:

If you want to rollback to some other commit, you can use a second option. In the Deployments section, click Deployment button. From there, select a previous commit from the dropdown, and deploy. DeployBot will bring the files on your remote server to the state of that commit. Files will be added, edited and deleted as needed to get everything to this previous revision. We will automatically detect that it was a rollback and display it as such in the app.

How will rollback work?

You might be wondering (and you should) about how a rollback will work. For a deployment that uploads the files, rollback will revert the changes literally – if a file was added before, it will be removed, if a change was made, it will be unmade, if a file was deleted it will be added back.

Things are trickier for deployments that just execute code on your server. In that case, your script will have to react on the rollback on its own – we will provide updated %COMMIT% and %ROLLBACK?% variables, but you have to make sure your script takes them into account. If you are not sure how a rollback will work in your case, please don't hesitate to ask questions in support, we will be glad to investigate with you and clarify.

Rolling back in version control

It's important to note that rolling back the deployment will not revert the files in your repository. The next time you deploy, all the changes that you rolled back will be again uploaded to your remote server. So it is important that you revert or fix the offending changes in your repository as well.

Here's an example:

• You commit revision 10 and deploy it to the server.
• You commit revision 11, deploy it to the server and it breaks your site.
• You rollback the deployment to revision 10.
• You commit revision 12 that fixes the bug that broke the site, or you revert to revision 10 in version control.
• You deploy the most recent revision 12 to the server.

In this example all file changes between the revision 10 and 12 will be updated to revision 12 on the server, overwriting any broken code that revision 11 introduced. This will bring your repository and your server to the same state.