drush

I was reminded recently about how a GitLab engineer managed to delete the prod database, and that got me thinking about one of my biggest (production) mistakes.

It's been at least 5 years since this happened so I think it's safe to tell the story of when I dropped a production database of one of my clients.

At the time I was working on a (pretty large) Drupal website for an international organization. The site consisted of an extensive content area and allowed users to make anonymous purchases through the website, which were sent to a CRM every night. It was hosted on the Acquia platform and used BLT to perform the day-to-day development operations on the site.

I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hook_update_N() hook. The hook_update_N() hook is just one of the options available in running updates as the update pipeline also includes hook_post_update_NAME(). The hook_deploy_NAME() hook, bundled with Drush 10, can also be used as an update hook in the same way.

Each of these update hooks has a number of different best practices when considering their use. All of these hooks are run once and once only and the key idea is that they take Drupal (or a module) from one version to another by adding database changes or configuration updates as the module gets updated.

For example, if you have a module that has a database table then it will be stored as schema information within your module. Once you release the module you must ensure that everyone who already has the module installed can still use it after the schema has changed. This means that as well as updating the schema information you also need to provide steps in the update hooks to update existing installs. Without this step the module would likely crash as it attempts to inject data into tables or fields that don't exist.

When copying a database from your production environment to your dev or local setup you should probably be sanitising it. This means to remove all user identifiable information from the database. You would assume that this means removing passwords and email addresses, but it also includes any fields you might have added to the user that might contain information. Things like name, address, company or even gender should all be sanitised.

Sanitisation is important from a data security point of view as you do not want any user data leaking out from your development (or testing) platforms. You want your users to have confidence in your abilities to protect their data and sanitisation allows you to keep their user data only on your production environment (and any production backups).

If you are using Drupal 9 and Drush then you can sanitise your data easily using the sql:sanitize command. This comes with Drush and should be available out of the box.

Drush sql-sync is a very easy way of grabbing a copy of a Drupal database from one site and installing it on another site. The normal application of this task is to copy the database from the production site to your local environment for facilitate local development. There are one or two steps to sort out before you can use the command

This post assumes you have Drush 8 installed on your machine as Drush 9 uses a different syntax for sotring Drush aliases. This also assumes that you have setup SSH key access to all servers you need to get access to.

Setting Up Aliases

The first thing you need to do is set up your Drush aliases, this allows you to connect to the remote Drupal instance from your local machine. Drush aliases are kept in your ~/.drush directory. To see what aliases you have on your system use the command.