Automating Drupal

deployment with drush_make,

installation profiles and
features

Presented by:
Adrian Rollett & Adam Jensen
Central Web Support
University of North Texas
Twitter: @acrollet @jazzslider
Who are we, anyway?

UNT Central Web Support office handles:

Systems administration
Web application development
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…

Content types?
Views?
Dependencies?
How do you…
Use version control?
Package it up for redistribution?
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:
Code is generated, (usually) not written by hand
Collects functionality rather than creating it
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…
content types,
views,
menu items, and
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

Download calendar, cck, date, and views; enable several

relevant modules from each project.
Create an "Event" content type.
Assign a date field to the Event content type.
Clone the calendar view that comes with the calendar
module.
Modify the view such that it only shows Event nodes, and
places them on the calendar using their date field.
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

Do all that other stuff

once.
Create a new feature,
making sure to specify…
The module
dependencies
The content type to
export
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:
Install the feature code
as you would any other
module
Make sure that the
dependent modules are
there
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…
versionable,
packageable, and
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:
Exporting taxonomy
vocabularies.
Exportables
module can help
with this
Exporting variables.
Enabling blocks.
Exporting nodes (not
really within scope).
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
http://code.developmentseed.
org/featureserver/dashboard
Decentralized approach to distribution means you can have
greater control over the process
See http://developmentseed.
org/blog/2009/jun/24/distributed-feature-servers-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:
drush dl {project}
drush enable {module}
drush disable {module}
drush update {module}
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.
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/trunk/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:
A drush_make make file is simply descriptive; tell it
what dependencies your site needs, and it handles the
process of retrieving them
Make files are sharable, distributable, and guaranteed to
work on any system that runs Drupal
Make files also tend to be more succinct and human-
readable than shell scripts (no need to know
bash/python/ruby/etc.)
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

If you're a developer, hopefully this doesn't scare you!
the installation_profile_api module helps somewhat
They can be somewhat finicky to build
They can only be run at install time.
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
enable modules and features
download and install translations
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
http://drupal.org/project/exportables
http://code.developmentseed.
org/featureserver/dashboard
http://developmentseed.org/blog/2009/jun/24/distributed-
feature-servers-drupal
drush_make
drush_make README
blog post from mig5.net on drush_make and aegir
proposed patch for generating makefiles
Installation Profiles
Damien McKenna's very helpful post on building
installation profiles
Questions?
Thank you!

Adam Jensen
@jazzslider

Adrian Rollett
@acrollet

UNT Central Web Support

https://webadmin.unt.edu