Build Kit Abridged

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 we're 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 "http://drupalcode.org/project/buildkit.git/blob_plain/refs/heads/7.x-2.x:/distro.make" 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:

• Make system directories configurable to allow tests in profiles/[name]/modules to be run A regression from Drupal 6 is that it's no longer possible to run tests of a contrib module if that module is located at profiles/profilename/modules/modulename.
• Use vocabulary machine name for permissions Taxonomy uses vocabulary ids in permissions which makes them not exportable. This patch uses machine names instead.

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 rebuild.sh 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 us. 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"?