Drupal Geek: Using Drush to Pull Latest Production Website Back to a Development Environment

In this blog, I'll describe how to leverage drush, the DRUpal SHell, to pull a production system back to a development environment. Couple of assumptions here:

  1. Drush is installed and available from the command line. This is a topic for another blog but, in essence, you download the module from http://drupal.org/project/drush, expand the tarball and put it in your path.
  2. You are using SSH private/public keys to login to the production server. Once again, this is beyond the scope of this blog post but this is a good place to learn how to do it: http://remysharp.com/2007/01/22/ssh-without-a-password/
  3. Your development environment web server and database are already set up, meaning that the directory for the dev site already exists and the server points to it. Also, the database exists.

Step 1. Create a drush alias file.

Drush has the ability to use alias files to refer to specific drupal site installations. Instead of having to ssh to a server, change directory to the specific drupal sites directory and then run drush, I can just run something like "drush @mysite ..." and then the rest of the command. The drush alias file should be stored in your home directory's .drush folder. Here is what I would do on a new Mac machine:

If it doesn't already exist, create a .drush folder in your home directory

mkdir ~/.drush

Now, with your favorite text editor (I switch back and forth between using Coda and Textmate), create a new file. The file MUST end with "aliases.drushrc.php". You can choose to prefix it any way you like using ordinary file naming conventions. For example, let's do an alias file for the example.com website. I would likely name the file "example.aliases.drushrc.php" like so using Textmate:

mate ~/.drush/example.aliases.drushrc.php

or using vi:

vi ~/.drush/example.aliases.drushrc.php

Assuming your development environment is local, enter the following:

< ?php //note that the space before the question mark should be removed...couldn't post to blog without it :-(
$aliases['example-local'] = array(
  'uri' => 'default', // The Drupal multi-site folder under <drupalroot>/sites/
  'root' => '/Users/bjones/Sites/example/httpdocs', // This is your website root folder
);
$aliases['example-prod'] = array( 
  'uri' => 'default',
  'root' => '/var/www/example.com/httpdocs', //Path to website root on your production server
  'remote-host' => 'www.example.com', // url to your production web server accessible via ssh
  'remote-user' => 'bjones', // your username on that server. Remember that you should have ssh keys for logging in
  'path-aliases' => array(
      '%dump' => '/Users/bjones/.drush/example-dump.sql', //this keeps you from having to specify dump files
   ),

);
?>

The $aliases lines have arbitrary names that we're going to use now

Step 2. Pull the files

From the command line on your dev server, enter:

drush rsync @example-prod @example-local

Note that the first alias is the source site and the second one is the destination site. Drush will use the information in the example.aliases.drushrc.php file to know where to get the source files and where to put them on the destination site.

Your dev machine will ask you to confirm that you're going to destroy your local version of the directory and replace it with the production site. The very cool thing about this process is that drush (rsync really) will only pull what has changed on the production server to the development machine. One gotcha for this process can be if you don't have full write permissions on the development directory.

Note: drush rsync does not pull settings.php files. This is very cool in that your development environment can have different database login information than your production system and drush rsync will not overwrite the dev environment setup.

Step 3. Pull the database

Again from the command line on your dev server, enter:

drush sql-sync @example-prod @example-local

Again the system will let you know that armageddon is raining down on your poor development environment. This time, the developemnt database will be replaced with the production database. Assuming that's ok with you, confirm.

Conclusion

That's pretty much it. Once you setup your alias files for your different sites, you'll discover that pull prod back to dev to make a change is two command line entries: "drush rsync ..." and "drush sql-sync ..." It makes doing updates to a dev environment so much easier (and encourages you to NOT make changes directly to prod).

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
11 + 6 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.