Build Kit Abridged or Every Site is a Drupal Distribution

Five years ago Dries blogged about distributions becoming an integral part of the Drupal ecosystem. He saw a future for Drupal that included tailored products for many different markets. Today there are a large number of distributions targeting many categories. In this post I'm going to discuss Build Kit and how it can be used as a platform for building and maintaining distributions and custom site builds.

Build Kit

The philosophy of Build Kit was introduced in the blog post by Development Seed, Features and Exportables on Drupal 7. As outlined in this blog post the components are:

  1. Every project is described by a makefile.
  2. Every project is an install profile.
  3. Build with exportable components and manage them with Features.

By describing the entire project in a .make file maintenance time is decreased. In one place it is possible to view all the modules, themes, and libraries of a project and any patches that are in use.

Build Kit 7.x-2.x can be installed using a single line from your shell. Be sure you have drush_make installed and run:

drush make --working-copy "" buildkit

This will create a patched version of Drupal 7 core and will download a small number of contrib modules necessary for building sites with exportables including features, context, and strongarm.

Drupal 7 core patches

Build Kit includes the make file distro.make to keep track of Drupal 7 core patches that are necessary for building with exportables. Some of the patches that were tracked when Development Seed blogged about the project have since been committed to core. Remaining patches are:

Both of these patches are being worked on for the 8.x branch of core and are tagged needs backport to D7.x. Build Kit includes working 7.x versions of the patches. Any help towards getting these two issues committed will be greatly appreciated by those building distributions.

Creating your own distribution or custom site build

At Affinity Bridge we build each of our new custom site builds as if it were a distribution. Follow the Extending Build Kit steps in Build Kit's README.txt to see how to extend Build Kit yourself. Also take a look at a very simple distribution to see how we structure our files in version control (note the inclusion of .gitignore and that help us when rebuilding the code base in place).

Adjusting to a new development methodology

When using a distro oriented approach for development there are a number of differences that may seem counter productive compared to the "old school" method:

  • sites/all/ directory remains empty. All contrib and custom modules, themes and libraries live in profiles/profilename/. Some of the paths that are important to ignore from version control are profiles/profilename/modules/contrib, profiles/profilename/themes/contrib and profiles/profilename/libraries. All projects within these directories are defined in the .make file and put in place when running drush_make.

  • Rebuilding takes a few minutes. This was the biggest adjustment to me. But after getting into the flow of using this approach it becomes easier to minimize rebuilds, only needing to do so when updating projects or introducing a new project.

  • Tracking much less in version control. At first it felt dangerous but soon we realized the extent of duplication happening. Why track all of Drupal core when you can track the line projects[drupal][version] = "7.7"?

Learn more at DrupalCon London

I'm organising a BoF presentation on Wednesday, August 24 at DrupalCon London, Understanding Build Kit and the Kit specifications. Along with Build Kit I'll also be discussing Kit which is a set of specifications for building interoperable Features modules and themes. Hope to see you there.


Thanks for sharing! Our

Thanks for sharing! Our DrupalCon presentation is definitely along the same lines.

Unfortunately we missed the BoF, but do you have any notes to share besides the PDF uploaded to the BoF page? Thanks!

I enjoyed your DrupalCon

I enjoyed your DrupalCon session. I was happy to see others promoting Build Kit and Kit. They seem to me like important projects that aren't getting enough love :)

I did post the link to my slides I used for my BoF but that's the only notes I have. It was a fairly brief overview of the slides and then some great discussion.

persisting content?

Hi Shawn,

Thanks again for the great presentation at PNWDS, and especially for taking the time to answer all my questions afterwards.

I've finally got a nice buildkit-based setup working, which I'm trying to apply to a project that I'm upgrading from D6 to D7.

What's tripping me up is the drush site-install myprofile step. What I want to do is drop in my D6 database, run updb, and then gradually turn on various modules in my install profile (rebuilding as I go).

Obviously I'm missing something. I shouldn't be using the site-install command at all, since it overwrite the db anyway. What do you do in your workflow to rebuild and maintain the db you had?

Or is that the point, you can't/don't want to? It's just the install profile you're building, so you don't care about content?

If that's the case, I've considered doing the 6 -> 7 upgrade using the migrate module for everything (like described here. But I would much rather benefit from all the upgrade paths provided by contrib modules like cck, etc..

Does this problem make sense? Any advice? Thanks!

The method I've outlined here

The method I've outlined here if for building a new site, not for applying to an existing site.

I don't know if it's possible to change a sites install profile. If it is I doubt it would be trivial.

You are correct that you should not use the drush site-install command on an existing site.

My workflow for rebuilding the codebase is to include a bash script in the profile that:

  • nukes the modules, themes, and libraries directories
  • runs drush make on the profile .make file
  • git checkout modules themes to pull out the custom modules and themes that are tracked in version control

Here is the script from my Simple profile.

Did I answer your questions? Let me know if you have any others.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options