Wednesday, July 18, 2018
Little local Drupal build script
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 dont 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 its easy to remember their names. Usually its 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
Thats 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, its necessary if you dont 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
Its time to call the update:
$ drush updb -y
Now comes a little trick. In order to make sure that Features wont report a sick day you need to clear the cache first. And funny enough, you should call feature revert two times. Its not 100 safe still but usually it can revert everything after 2 calls. Its 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 its not only your grandma who knows the trick. Thats it basically. You add some candies if you want, such as opening a browser tab ready to rock:
$ open `drush --uri=URL uli`
Ive 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
