Ted Bowman's picture

Drush is a great tool that every Drupal developer should learn. It will save you tons of time with everything from downloading and enabling modules, to exporting and reverting Features. Another advantage of Drush is that it allows you to group together commands in simple shell scripts. One of the most common tasks that can be encapsulated in a shell script is synchronizing the current state between to versions of your site. This is commonly done to bring live content from your production site into your development or local site. In this example I will be building a shell script that runs on Mac OS X but it should work on Linux and with small changes probably Windows too.

To take advantage of the Drush commands to synchronize sites you will need to set up Drush aliases for your sites. If you don't know what Drush aliases are you can read about them here. The Drush aliases example file is also a good resource. For our example we are going to use site aliases, @mysite-live, the live version of our site, and @mysite-dev, the development version of our site. Once you have the Drush site aliases setup the first command that we will need is sql-sync. As you might expect this command syncs the databases between two Drupal sites. In our case we would invoke the command this way:

drush sql-sync @mysite-live @mysite-dev

It's that simple. Now your development database will be an exact copy of your live database. It is important to note here that the second site alias is our target site. This is important because you don't want to send your development database to your live site! Luckily Drush asks for conformation before it runs sql-sync so we are prompted to make sure we put the aliases in the right order.

There maybe some problems though with having your development database be the exact same as your live database. You may want certain modules to be configured differently in development than in your live site. Luckily most module configuration settings are stored in Drupal variables and Drush can read and set these variables. Often the file system configuration for your Drupal site will be different on your development and local site than in your live site. In this case you want to make sure that your development settings aren't overwritten by your live settings. This can be done easily by saving the values before you synch the database and then restoring them afterwards.

# Save file system settings
private_path=$(drush @mysite-dev vget --format=string file_private_path)
public_path=$(drush @mysite-dev vget --format=string file_public_path)
temp_path=$(drush @mysite-dev vget --format=string file_temporary_path)
# Synch Database
drush sql-sync @mysite-live @mysite-dev
# Restore File system settings
drush @mysite-dev vset file_private_path $private_path
drush @mysite-dev vset file_public_path $public_path
drush @mysite-dev vset file_temporary_path $temp_path 

You also might have modules that you don't want enabled in development and others you only want enabled in development. To solve this problem you can enable and disable modules in your script. In this example lets enable the MailLog and Devel modules. After that lets set the variables related to the MailLog module so that emails are not sent from the site but displayed on the screen. This will ensure that no emails are sent to real email addresses of the users of the site.

drush @mysite-dev en maillog -y
drush @mysite-dev en devel -y
drush @mysite-dev vset --format=integer maillog_send 0
drush @mysite-dev vset --format=integer maillog_devel 1
drush @mysite-dev vset --format=integer maillog_log 1

Since you will be replacing your development database completely there is a chance that you may wipe out some work you have been doing. Any configuration such as Views, Panels, or Rules that you have not exported out of your development site will be wiped out when you synch with the live database.  Of course you know this and won't synch the database until you have all that taken care of, right? Just to be on the safe side it is a good idea to back up your database before you do the sync.  If you are using the Backup and Migrate module you can just put this line at the top of your script.

drush @mysite-dev bb

Now that your development database has been backed up, if you had forgotten that you didn't export a particularly complicated View in development you can restore the database to export this View.

Ok, that takes care of syncing your database and updating modules and configuration.  In certain cases you may also want to sync your files directory. If your site contains tons of uploaded file attachments you may want skip this step. Syncing the files directory though is very simple via Drush using the rsync command.

drush rsync @mysite-live:%files/ @mysite-dev:%files

This requires you have your files directory defined in your site aliases. As a variation on this you could also only sync certain sub directories of your files directory.

One last thing I like to do in my script is to clear all my caches in my development site.

drush @mysite-dev cc all

Thats it, you're down. You can download the script file to try it out. Of course you may want to add some other Drush commands that you need for your particular workflow but this should get you started.


Hi Ted,

You might be interested in my Drush command, Drush Rebuild (http://drupal.org/project/rebuild). With Drush Rebuild you can write a config file in YAML format and have Drush run the setup tasks you describe in this post for you. This makes it easy to share with colleagues working on a site with you. Plus you don't have to be paranoid about running `sql-sync` in the right direction :-)


Ted Bowman's picture

Kosta, yes this looks like a great project. I will have to check it out. Just a note the docs for the project still say the settings are via ini. I guess you have changed this to YAML , now.

I am also interested in your Drush Code Deploy sandbox project.  Is this project ready to use?  It seems like these 2 projects together could very useful to set up a reliable Dev - Test - Live site setup.

Hi Ted,

Yes the docs are out of date. If you have any troubles working with it, please post in the issue queue for the project. I have a task there to update the docs...

Drush Code Deploy is not quite ready. There are some tricky issues around Git / SSH / authentication that I could not solve easily and haven't had time to go back to.


I ted, is there a way someone could setup Drush on window 7

Ted Bowman's picture

There are some links here: https://www.drupal.org/node/594744 though I haven't tried them. The other options would be to use Acquia DevDesktop. I think it would install it's own version of Drush. If you were going to use Windows my recommendation would be to use Vagrant to run your server virtually as Linux.

Other Services

Drupal Consulting

Need help with project Planning?

Are you lost trying to select modules to implement your sites functionality?

Looking to simplify your Drupal development and solve problems faster?

Are you having trouble with modules such as Views or Panels?

Six Mile Tech’s Drupal consulting provides you or your company with an experienced Drupal expert.  You will be able to eliminate hours or days of wasted time looking for a way to solve your problem in Drupal. We can get you past your current dead ends in Drupal and we can teach you to solve your problems in Drupal the right way.

Contact Us to today to Learn More

Project Mentoring

Our mentoring service provides you with guidance through all of the phases of your Drupal project from planning to deployment.  We can help make sure that you are making your Drupal website the right way from the start.  With our guidance you will avoid common costly mistakes and start making more for your time.

Contact Us to today to Learn More


Training Newsletter

Sign up for our Training Newsletter to hear about in person and online trainings as well as to receive exclusive discount codes.

Online Trainings

Six Mile Tech offers online trainings via Skype, Google Hangout, or a screen sharing technology of your choice. These trainings can be used for generalized Drupal trainings or to tackle a specific problem for a site you are working on.