Improving Dev Cloud Drush Aliases to Improve Workflow
Yesterday I went over how to import an existing Drupal Git repository into Acquia Dev Cloud without losing its history, which was great for setting up our existing codebases, but I still ran into a bit of a problem I didn’t like with getting the existing Drupal databases imported into a remote Dev Cloud instance.
Acquia provides documentation on how to do the database import, but I much prefer to do a
drush sql-sync from my local machine, rather than have to copy my database dump into the import directory, ssh onto their server, run a Drush command to get the database connection information, and then finally execute a somewhat cryptic command to do the database import. There is a much easier way!
After logging in at network.acquia.com and selecting one of your “subscriptions,” under Dev Cloud, click Utilities and follow the instructions to get your Drush alias file to its new home in the ~/.drush directory. Now we need to do a little surgery.
First we need to add an entry for our local environment, since (of course) the one from Dev Cloud doesn’t come with one. This will entirely depend on your local setup, but here’s an example from mine:
// Site [site-name], environment local $aliases['[site-name].local'] = array( 'root' => '/Users/[user]/Sites/[site-name]/docroot', 'path-aliases' => array( '%dump-dir' => '/private/tmp', ), );
NOTE: Do be smart and replace
[user] with some appropriate values.
Now we need to add just a little bit of code to the end of each of the Dev Cloud environment entries, between the
'remote-user' line and the closing
'path-aliases' => array( '%dump-dir' => '/mnt/files/[site-name].dev/import', ),
Make sure that the environment in the code (dev, test, prod) matches the environment you’re adding it to. And rather than just plug in my formula, you probably want to double-check the value of the import directory with what you find on the Files and logs page, under Dev Cloud.
That’s it for the setup. Now we can have some fun (if you consider copying your Drupal database to a remote server with a single command fun). If you’ve done everything correctly, the following command should create a dump of your database, copy it to the Dev Cloud server import directory, and import it into the dev database. Magic!
drush sql-sync --no-cache @[site-name].local @[site-name].dev
drush rsync @[site-name].local:%files @[site-name].dev:%files
NOTE: You can really mess stuff up with these commands, if you don’t understand them, and you can mess them up just as fast even if you do understand them and you’re not careful. I speak from the voice of experience! You want to read the Drush documentation and double-check yourself whenever you execute a
drush sql-sync or
drush rsync command.
Well, that’s all, boys and girls. I’m sure I’ll come up with more insights and fixes for working with Dev Cloud, but this should suffice for now. And as I stated yesterday, I’m great with Acquia using this information to improve their documentation. Share the love/code/knowledge/whatever.