Deploying local to remote sites drush site aliases

Deploying local to remote sites drush site aliases by kiwipion

Introduction

In this tutorial we are going to deploy a copy of our current local site across to what we will term our staging server using the Drush function site aliases. For ease of use the staging server will be on the local machine as well, but you can use the same principal for propagating across to a remote server such as a shared host.

Prerequisites

For you to follow these instructions you will need the followng setup on your machine

• Local environment set up ie MAMP for mac
• Drush installed.

Preparation

Implement your own aliases.drushrc.php file. You can copy the example.aliases.drushrc.php from the examples directory to either your local drush root directory or into your drupal installation make sure you read the instructions at the top of this file to ensure that it gets picked up buy drush.

There are two very good articles that can be used as reference here http://emspace.com.au/article/drush-aliases-primer-live-dev-syncing & here http://drupal.org/node/670460

Go into your drush/examples folder and copy the examples.aliases.drushrc.php to a location of your preference, I'll be putting mine in the drupal installation directory and renaming it to mysite.aliases.drushrc.php.

For reference here are my aliases for @mysite.dev & @mysite.stage

$aliases['dev'] = array(     'uri' => 'myserver.myserver',     'root' => '/sites/mysite',     'path-aliases' => array(       '%drush' => '/Users/nigelhenshaw/dev/drush',       '%drush-script' => '/Users/nigelhenshaw/dev/drush/drush',       '%dump-dir' => '/sites/SQL/dumps/',       '%dump' => '/sites/SQL/sql-dev.sql',       '%files' => 'sites/drupalovereasy.com/files',      ),   );   $aliases['stage'] = array(     'uri' => 'myserver.stage',     'root' => '/sites/mysite.stage',     'path-aliases' => array(       '%drush' => '/Users/nigelhenshaw/dev/drush',       '%drush-script' => '/Users/nigelhenshaw/dev/drush/drush',       '%dump-dir' => '/sites/SQL/dumps/',       '%dump' => '/sites/SQL/sql-stage.sql',       '%files' => 'sites/drupalovereasy.com/files',      ),   );

Inform the drushrc.php file of the location of the aliases file in ['alias-path'] section.

Now check that drupal is scanning your alias file correctly and your configuration is correct by running

drush sa

You should be something like this, which will confirm that drush is scanning your alias file and the context of your alias is correct.

@self @mysite.dev @mysite default

The alias I definned is @mysite.dev

Let's see if we can backup the contents of the database by doing a drush dump, this will be the command that I will be running

drush @mysite.dev sql-dump > `drush dd @mysite.dev:%dump`

A copy of my database should now be downloaded at /sites/SQL/dumps/, which was specified in the the mysite.aliases.drushrc.php

Now I'm going to repeat the process and create alias settings for my staging server which I will call mysite.stage

Deploy

There are two steps required for migrating across to a new site location that has not yet been populated

1/ Rsync the code across

% drush rsync @mysite.dev @mysite.stage

2 / Configure the database and ensure that settings.php is aligned with it.

3/ Sql-sync the database across

% drush sql-sync @mysite.dev @mysite.stage 

Your staging site should now be up and running.

Synchronization

Once a remote site has been installed you will have to consider how you will maintain the site after ie how do you manage source code and database content. Normally source is pushed up to the remote server and database content is pulled down. An example demonstrating this would be upgrading a site where that database content has been pulled down to the staging server using drush sql-sync. The source code is then pushed up to the staging server from the local dev server using drush rsync, then staging server is tested and verified. Once passed the validation criterea the remote live site will then be put into maintenance mode with the latest copy of the database sync'd back down to the staging server. The validation testing would normally be re-run and then the source code would be merged up to the live server.

This is a very light-weight example which I'm using the demonstrate the direction of source code versus database data in relation to each other, which is different from what we did with the brand new setup of the staging server that had both the source code and database content pushed to the staging server.

Final Thoughts

In closing it will be interesting to see how drush rsync and sql-sync will develop in regards with the work happening in git and dog, I have seen discussions of installing git on the live server and merging the code up but I don't yet know if it is possible to install git on a shared host without the root access. And I do find the drush rsync & sql-sync fast and simple to use.

And my final word for the day "always make sure you backup the database before running the sql-sync command".