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

Easy automation of deployment

Original image by flickr user jasoneppink

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, fullyconfigured Drupal functionality.

Image from XKCD:

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, 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 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-touse 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 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 new Project information for drupal retrieved. drupal downloaded from 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 adminrole patched with adminrole_exceptions.patch. cws_event_calendar downloaded from[...]/cws_event_calendar-6.x-1.0-beta4.tar. northtexas downloaded from file:///export/web/svn/cws/northtexas_theme. tinymce downloaded from[...]/

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 humanreadable 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:


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://code.developmentseed. org/featureserver/dashboard drush_make drush_make README blog post from on drush_make and aegir proposed patch for generating makefiles Installation Profiles Damien McKenna's very helpful post on building installation profiles


Thank you!
Adam Jensen

Adrian Rollett

UNT Central Web Support

Sign up to vote on this title
UsefulNot useful