Simplify your development workflow with Drush and scripts

Anja Schirwinski
Anja Schirwinski

We would like to share a tool with you that has helped speed up our development process as a team.

If you work on Drupal sites with a team of other developers you will know the problem: You pulled code and all of a sudden you get strange errors. Eventually you find out you need to run update.php or revert a certain Feature or clear the cache. Maybe you even got into the habit of just doing all of that after each pull and it takes up some valuable time that you need elsewhere. To avoid these problems we introduced shell scripts a while ago. Within just a few months they have evolved into a multi-file system with subscripts, but I want to share them in their simplest form.

Here's a few examples of what you can do in a script, combined with the powers of Drush:

  • Enable and disable modules or themes
  • Revert your Features
  • Clear your caches
  • Run database updates
  • Delete content types and fields
  • Index content for solr
  • Whatever else Drush can do
  • Output some audio when the script is finished!

Our scripts live in sites/all/scripts. Drupal by default disallows access to .sh files so there's nothing we need to do there to keep our files private.

update.sh Raw
  1. ################################################################################
  2. # Shell and drush commands to update the given installation
  3. #
  4. # Go to sites/all/scripts (e.g. cd sites/all/scripts) and type "sh update.sh"
  5. # in your console/shell/Terminal.
  6. #
  7. # The commands have to be functional for any case after the initial installation
  8. # installation. So on any set up after calling that script, the configuration
  9. # must be the same.
  10. #
  11. # For example:
  12. # ------------
  13. # When the script enabled a module in an earlier revision and that module shall
  14. # not be enabled in the current revision, we have to add a "drush dis" and a
  15. # "drush pm-uninstall" command for that module to this script.
  16. #
  17. ################################################################################
  18.  
  19. # Change directory to drupal root
  20. cd ../../..
  21. # pwd
  22.  
  23. # Check drupal status
  24. drush status
  25.  
  26. # Disable these themes to make sure they are never enabled.
  27. drush --yes pm-disable seven
  28. drush --yes pm-disable bartik
  29.  
  30. # Enable some modules that must be enabled.
  31. drush --yes pm-enable features
  32. drush --yes pm-enable strongarm
  33.  
  34. # Enable project features.
  35. drush --yes pm-enable ok_base
  36. drush --yes pm-enable ok_event
  37. drush --yes pm-enable ok_i18n
  38. drush --yes pm-enable ok_menus
  39. drush --yes pm-enable ok_news
  40. drush --yes pm-enable ok_page
  41. drush --yes pm-enable ok_search
  42. drush --yes pm-enable ok_slideshow
  43. drush --yes pm-enable ok_sidebar
  44. drush --yes pm-enable ok_theme
  45. drush --yes pm-enable ok_user
  46. drush --yes pm-enable ok_wysiwyg
  47.  
  48. # Enable project theme.
  49. drush --yes pm-enable ourprettytheme
  50.  
  51. # Update
  52. drush --yes updb
  53.  
  54. # Disable unused modules and features.
  55. drush --yes pm-disable features_override
  56. drush --yes pm-uninstall features_override
  57.  
  58. # Remove an old content type and some fields.
  59. drush --yes php-eval "node_type_delete('page');"
  60. drush field-delete field_news_tags --bundle=news
  61. drush field-delete field_news_link --bundle=news
  62.  
  63. # Index content for solr
  64. drush sapi-i ok_sitewide_index 10000 25
  65. drush sapi-s
  66.  
  67. # Revert all features and clear cache.
  68. drush --yes features-revert-all
  69. drush cache-clear all
  70.  
  71. # Display list of features to check status manually.
  72. drush features
  73.  
  74. # Check for available notification system
  75. # Checks in preferred order and only uses one: Notification Center, Growl, Audio
  76. # For OS X 10.8 use terminal notifier "sudo gem install terminal-notifier" http://rubygems.org/gems/terminal-notifier
  77. # For Growl, download and install growlnotifier http://growl.info/downloads#generaldownloads
  78. if [ $( find /Library/Ruby/Gems/ -name 'terminal-notifier*' -type d | wc -l) -ge 1 ]; then
  79.     # Notification center output for finished update.sh
  80.     terminal-notifier -message "$USER, the update script run is complete" -title "undpaul Update Script"
  81. elif [ -f /usr/local/bin/growlnotify ]; then
  82.     # Growl notification
  83.     growlnotify -n "undpaul Update Script" -m "$USER, the update script run is complete"
  84. elif [ $(command -v say) ]; then
  85.     # Vocal output for finished update.sh
  86.     say "$USER, the update script run is complete"
  87. fi
  88.  

Because the script tells us when it's finished, we can just go do something else while it runs.

We also use an installation script so everyone on the team can get started quickly. Basically, we expect to be able to set up the project from scratch at any time by just running install.sh and update.sh:

[gist:5848790]

This is really helpful if anyone wants to test their development with a fresh database, but using the current code base. It helps avoid problems that occur if someone forgot to export some setting in a Feature.

What do you think about our scripts? Does your team use something like this during development?

Anja Schirwinski
Acquia Certified Developer Badge
Anja Schirwinski
  • CEO

Co-founder and CEO of undpaul. Project manager, account manager, front end developer, certified Acquia developer and author of Drupal 8 Configuration Management (Packt Publishing).