Automating Drupal

deployment with
drush_make, installation
profiles and features
DrupalCamp Austin
Presented by: 2009
 Adrian Rollett & Adam Jensen
Central Web Support
University of North Texas
Twitter: @acrollet @jazzslider
Who are we, anyway?

• UNT Central Web Support office handles:

o Systems administration
o Web application development
o Hosting services
• UNT recently selected Drupal as the official
campus CMS
• Have rolled out ≈300 instances of our
custom Drupal distribution
What's in it for me?

Image by flickr user atlanticlost

Dynamic web apps without Drupal

• Functionality lives in code

• Content lives in the database
Dynamic web apps with Drupal

• Functionality lives mostly in code, but what

about…
o Content types?
o Views?
o Dependencies?
• How do you…
o Use version control?
o Package it up for redistribution?
o Deploy it elsewhere?
• One common solution: put database dumps
in version control!
Versioning database dumps is kind
of like making a photocopy of a
pig: messy, difficult and time-
consuming

Original photos by flickr users sugarmtnfarm and binglib

So what then?

• Functionality should still live in code if

possible, but why?
Less Clicking: make your changes
in code, not with a mouse

Image from warmouse.com
Easy automation of deployment

Original image by flickr user jasoneppink

Features

• The Features module (currently beta3) allows you to

export  sets of functionality (photo albums, blogs,
calendars, etc.) as "features"
• Features are modules, but at a higher level of
abstraction
• Key differences:
o Code is generated, (usually) not written by hand
o Collects functionality rather than creating it
o Easily enabled by lay people, and they don't have
to look at the core modules page to do it
What is a feature?

• Features bring
together all the
little pieces that
make up usable,
fully-configured
Drupal
functionality.

Image from XKCD: http://xkcd.com/659/

What are the pieces?

• Information about module dependencies

• Exported configurations for things like…
o content types,
o views,
o menu items, and
o pretty much anything else that…
 can be exported as code, and
 has a machine-readable name.
• Most importantly: features are modules,
so all these pieces are defined in code.
No database dumps to manage.
For example…
Making an event calendar the old
way
1. Download calendar, cck, date, and views;
enable several relevant modules from each
project.
2. Create an "Event" content type.
3. Assign a date field to the Event content type.
4. Clone the calendar view that comes with the
calendar module.
5. Modify the view such that it only shows Event
nodes, and places them on the calendar using
their date field.
6. Go back over the end result to make sure you
didn't miss a step. All told, ≈15 minutes. Not
too bad, but…
Making an event calendar with
features
1. Do all that other stuff
once.
2. Create a new feature,
making sure to
specify…
o The module
dependencies
o The content type to
export
o The view to export
• Initial setup, ≈20
minutes. But then…
Deploying a feature

• Once you've built your

feature, deploying to
another site is simple:
1. Install the feature
code as you would
any other module
2. Make sure that the
dependent modules
are there
3. Visit
admin/build/features
and enable it!
• Time spent: ≈5 minutes,
maybe less.
Some advantages

• As long as the module

dependencies are there,
you can now install this
same feature on any site in
virtually no time.
• Since everything is in code,
it's…
o versionable,
o packageable, and
o deployable.
• End users can turn it on and
off without worrying about
the nitty gritty configuration
details.
What it doesn't do

• Some common needs that

features can't handle yet
on its own:
o Exporting taxonomy
vocabularies.
 Exportables module
can help with this
o Exporting variables.
o Enabling blocks.
o Exporting nodes (not
really within scope).
o Probably more things.
How to deal with that

• Features are modules. If necessary, you

can add your own hook_enable() and
hook_disable() code to ensure that
everything is set up as it needs to be.
• Avoid changing any of the
module.features.*.inc files. These can be
overridden if you later re-export your
feature, so stick to editing the .module and
.info files.
Features servers

• Rather than uploading features modules to

drupal.org, you can set up your own server
using the feature server module
o http://
code.developmentseed.org/featureserver/da
• Decentralized approach to distribution
means you can have greater control over
the process
• See 
http://developmentseed.org/blog/2009/jun/24/d
drupal for more information
What's next?

• Features is great for discrete functionality,

but what if you could do the same thing for
your entire site?
Drush: a quick review

• Command-line interface for managing

Drupal
• Some helpful commands:
o drush dl {project}
o drush enable {module}
o drush disable {module}
o drush update {module}
o There's lots more; run drush by itself for a
list of available commands
What is drush_make?

From drupal.org/project/drush_make: 
  
• Provides the equivalent of a make script for
Drupal, using Drush.
From the readme file:

• Drush_make is an extension to drush that

can create a ready-to-use drupal site, pulling
sources from various locations. 
o It does this by parsing a flat text file
(similar to a drupal .info file) and
downloading the sources it describes. 
• In practical terms, this means that it is
possible to distribute a complicated Drupal
distribution (such as Development Seed's
Managing News) as a single text file. 
What can drush_make do?

• Download Drupal core, as well as contrib

modules from drupal.org.
• Fetch themes and installation profiles.
• Check code out from CVS, SVN, git and bzr
repositories.
• Download plain .tar.(gz) and .zip files
(particularly useful for libraries that can not
be distributed directly with drupal core or
modules).
• Fetch and apply patches.
What does a makefile look like?    

It can be as simple as this:

$ sudo cat distro.build
core = 6.x
projects[] =  drupal
projects[cws_d6][type] = "profile"
projects[cws_d6][download][type] = "svn"
projects[cws_d6][download][url] =
"file:///export/web/svn/drupal_install_profiles/trun
k/cws_d6"
projects[cws_d6][download][branch] = "trunk"
Here it is in action (truncated output):

$ drush make distro.build new

Project information for drupal retrieved.                     
drupal downloaded from                                           
http://ftp.drupal.org/files/projects/drupal-6.14.tar.gz.
cws_d6 downloaded from                                              
file:///export/web/svn/drupal_install_profiles/trunk/cws_d6.
Project information for admin_menu retrieved.                      
Project information for cck retrieved.                              
Project information for cws_event_calendar retrieved.               
adminrole downloaded
from http://ftp.drupal.org/files/projects/adminrole-6.x-1.1.tar.gz.
adminrole patched with adminrole_exceptions.patch.
cws_event_calendar downloaded from https://cws.unt.edu/
[...]/cws_event_calendar-6.x-1.0-beta4.tar.
northtexas downloaded from
file:///export/web/svn/cws/northtexas_theme.
tinymce downloaded from http://downloads.sourceforge.net/
[...]/tinymce_3_2_7.zip.
Wait a minute, how did
drush_make know to grab all those
other items?
If the installation
profile you specify
includes a make file,
drush_make will
automatically parse
it.

That's the beauty of

recursion!

Original photo by flickr user 

frangipani_photograph
What can't drush_make do?

• Configure the database settings and install

Drupal itself. (an installcore command has
been added to drush, but works only with
Drupal 7)
• Make changes to an existing Drupal
installation.
• Configure or enable modules, set variables,
etc.
• drush make coffee not implemented at
this time
Can't I do the same stuff with a
shell script?
• Yes, but there are several advantages:
o A drush_make make file is simply descriptive;
tell it what dependencies your site needs, and it
handles the process of retrieving them
o Make files are sharable, distributable, and
guaranteed to work on any system that runs
Drupal
o Make files also tend to be more succinct and
human-readable than shell scripts (no need to
know bash/python/ruby/etc.)
o It's a standard, public, open source tool instead
of a custom solution
Custom Drupal to Go: tying it all
together with installation profiles

Original photo by flickr user dsnet

If features provide all needed
functionality, what use are
installation profiles?

Original photos by flickr users albaum and texasrobo

Installation profiles are the glue
between drush_make and features

Installation
profiles
drush_make + features will give
you this out of the box:

FAIL
What you see after logging in to
an Open Atrium site for the first
time
Wait, aren't installation profiles
bad???
Installation profiles have had a bad rap
for some amount of time. Probably the
chief complaint is the following:

The main problem holding back the full potential of

installation profiles is the lack of a packaging tool for
contributed modules.

-- Greg Knaddison (greggles)

drush_make solves that problem!

Original image by flickr user dbgg1979

Other drawbacks of installation
profiles
• You must know PHP and the Drupal APIs
o If you're a developer, hopefully this
doesn't scare you!
o the installation_profile_api module helps
somewhat
• They can be somewhat finicky to build
• They can only be run at install time.
o anything you want to be able to enable
and disable should be contained in a
feature (or module update)
What are installation profiles good
for in the context of this
presentation?
• Enabling a custom theme
• Doing one-time setup tasks like
o enable modules and features
o download and install translations
o disable unnecessary default functionality
• Anything! *

* (perhaps not
anything)
Tips for building Installation
Profiles    
• Start with the default profile, and modify it
to your purposes
• The open atrium installation profile is a nice
example
• Always look for an install_profile_api helper
function first
• The name of your profile and the directory
it's in should be the same
• When debugging an install profile, you'll
want php debug output to be on
• Clear *all* caches at the end of your profile 
References

• http://drupal.org/project/features
o http://drupal.org/project/exportables
o http://code.developmentseed.org/featureserver/dash
o http://developmentseed.org/blog/2009/jun/24/distribu
• drush_make
o drush_make README
o blog post from mig5.net on drush_make and aegir
o proposed patch for generating makefiles
• Installation Profiles
o Damien McKenna's very helpful post on building insta
 
Questions?

 
Thank you!

                 Adam Jensen
                 @jazzslider

                 Adrian Rollett 
                 @acrollet

            UNT Central Web Support 

                            https://webadmin.unt.edu