Simplify your development workflow with Drush and scripts
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.
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
20cd ../../..
21# pwd
22
23# Check drupal status
24drush status
25
26# Disable these themes to make sure they are never enabled.
27drush --yes pm-disable seven
28drush --yes pm-disable bartik
29
30# Enable some modules that must be enabled.
31drush --yes pm-enable features
32drush --yes pm-enable strongarm
33
34# Enable project features.
35drush --yes pm-enable ok_base
36drush --yes pm-enable ok_event
37drush --yes pm-enable ok_i18n
38drush --yes pm-enable ok_menus
39drush --yes pm-enable ok_news
40drush --yes pm-enable ok_page
41drush --yes pm-enable ok_search
42drush --yes pm-enable ok_slideshow
43drush --yes pm-enable ok_sidebar
44drush --yes pm-enable ok_theme
45drush --yes pm-enable ok_user
46drush --yes pm-enable ok_wysiwyg
47
48# Enable project theme.
49drush --yes pm-enable ourprettytheme
50
51# Update
52drush --yes updb
53
54# Disable unused modules and features.
55drush --yes pm-disable features_override
56drush --yes pm-uninstall features_override
57
58# Remove an old content type and some fields.
59drush --yes php-eval "node_type_delete('page');"
60drush field-delete field_news_tags --bundle=news
61drush field-delete field_news_link --bundle=news
62
63# Index content for solr
64drush sapi-i ok_sitewide_index 10000 25
65drush sapi-s
66
67# Revert all features and clear cache.
68drush --yes features-revert-all
69drush cache-clear all
70
71# Display list of features to check status manually.
72drush 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
78if [ $( 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"
81elif [ -f /usr/local/bin/growlnotify ]; then
82 # Growl notification
83 growlnotify -n "undpaul Update Script" -m "$USER, the update script run is complete"
84elif [ $(command -v say) ]; then
85 # Vocal output for finished update.sh
86 say "$USER, the update script run is complete"
87fi
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:
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?
