Little local Drupal build script

Sometimes I realize how small tools can be a huge help in the everyday operations. One of the most embarrassing fact about me that I like typing. I like typing queries and scripts and whatnot. But this tool I tell you tonight is a really helpful one.


So you have your Drupal development environment. What do you do when you start a new feature branch? Or test the current one? How about just starting something over? Or validating a deployment? These are exactly the use cases for a local re-deployment. I knew I do it a lot, but since I have the script I do it even more and it makes my deployment safer.

First I use Drush alieses immensely. If you don't know what is it - stop now and take a look at the link. Drush alias is a link to a remote environment which lets you to run your Drush commands locally on a remote site. I keep my site groups in separate files under ~/.drush so it's easy to remember their names. Usually it's the site name and inside the file the items are the stages, such as development, staging and production. It looks like:

$ drush @statdiary.staging dis views_ui

That's a crucial part of my productivity. The script is actually tiny. I keep these files in my project folder and add the ignore to my local home (dot)gitignore. I make a separate build script for each environment, such as build-from-dev.sh, build-from-staging.sh, etc. First things first we need to clear out the database:

$ drush sql-sync --sanitize --create-db -y @GROUP.SITE default

This will get the database from that environment and put it to my local database. --sanitize makes sure that user data will be sanitized. Better not to send your test emails to real humans. --create-db removes the tables from my local db, it's necessary if you don't want unexpected broken dependencies caused by disabled controllers or modules. -y is just approve the operation without us hitting it.

We then need a user account to login:

$ drush upwd admin --password=monkey

It's time to call the update:

$ drush updb -y

Now comes a little trick. In order to make sure that Features won't report a sick day you need to clear the cache first. And funny enough, you should call feature revert two times. It's not 100 safe still but usually it can revert everything after 2 calls. It's a strange effect when a feature is inconsistent and the state is toggling between feature revert and cache clear. That said, it looks like:


$ drush cc all
$ drush fra -y
$ drush cc all
$ drush fra -y
$ drush cc all

No it's not only your grandma who knows the trick. That's it basically. You add some candies if you want, such as opening a browser tab ready to rock:

$ open `drush --uri=URL uli`

I've tried to set it up in Jenkins but this way seems much quicker.

Let me know if you have other useful commands when pulling an environment to local.

---

Peter