- our team
- Our Clients
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.
- Every project is described by a makefile.
- Every project is an install profile.
- 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
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
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
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/libraries. All projects within these directories are defined in the
.makefile and put in place when running
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.