Rolling back production deploys

If a production deploy of a security update goes wrong, it may be necessary to consider rolling back your production code and database(s) to quickly get your production site back up and running.  

If a member of the support team is actively assisting you with the failed deploy, we can advise on whether or not a rollback is advisable. Ultimately the decision to roll back is the decision of you or your team and Acquia takes no responsibility for data loss as a result of a production roll back. 

When to roll back

Before rolling back your site you should exhaust all other troubleshooting options to get your site back up. Have you:  

• Checked for any outstanding database updates? 
• Ran a registry rebuild (Drupal 7) or a Drush cache rebuild (Drupal 8 or higher)?
• Cleared all caches?

If you have exhausted all the options and any further troubleshooting steps, it may be time to consider rolling back to get the site back up. There are a number of steps for rolling back your production environment: 

• Rolling back code

• Rolling back the database

• Reverting the code merge into master

Rolling back code

If no database updates were required when deploying your code to production, you can simply roll back the code that was deployed to the previous tag. In the case of Remote Administration updates, any database updates are communicated in our initial ticket notification. 

1. Determine the previously deployed tag on production. (This is noted in the RA ticket) 
2. Deploy this tag via the Acquia Cloud UI. 
3. Clear caches on production and ensure that the site is loading correctly again. 

This option does not present any risk to your database, however it is always best practice to have a fresh database backup available when making changes to production. Remote Administration always generates an on demand backup before deploying code to production.

Rolling back the database

If database updates were required as part of the deployment process, the rollback process will also require you to revert the database to the previous backup. Failing to do so will mean that your code and database will diverge, which may cause errors on your site.

Rolling back the database will result in the loss of any data created after the database backup. This includes any newly created content, user created content, user accounts and user activity on the site. When considering a database rollback, it is important to consider your own acceptable level of data loss. For sites with high volumes of user activity and user generated content, we recommend you implement a content freeze or put the site in maintenance mode prior to deploying changes to production to minimize this risk. 

To revert your site to a previous backup: 

1. In the databases tab of your production environment, determine the backup you are reverting to. 
2. Deploy the selected backup to your production environment. 
3. Ensure that you have rolled back the previous code. 
4. Clear caches and ensure the site is loading correctly. 

Reverting the code merge into master

If Remote Administration preferences are set to merge the updates into your master branch, an additional step is required to revert this branch. Failure to do so means that any new tags or branches created from master will contain the problematic updates. 

To revert the merge: 

1. Checkout your master branch in your local dev environment. 
2. Git pull to ensure that it is up to date with your origin repository. 
3. Use git log to show the most recent commits. Copy the first 6 digits of the commit hash for the merge commit.
4. Use git revert [commit hash] to revert the commit. Push this change up to your origin master branch.