Drush Make Files for Production Drupal sites

Deployment with a safety net

We now write Drush Make files for even our smallest one-off builds. This discipline saves us time and makes us more efficient as a team by knowing what code actually powers a site. It also helps us transition projects to our partners or to the shops that will be supporting the sites we build, helping us more quickly cut the long tail of a build. To give a sense of just how much this can help internal processes, I’ll explain how I was robbed of three days this week by jumping onto a project we worked on before we formalized using Drush Make in our build process.

This week we started sprinting on a custom Open Atrium build for Teachers Without Borders, an organization with a somewhat obvious multinational reach that wanted us to extend Open Atrium in a few interesting ways. They needed Open Atrium to be an identity hub, be localized into multiple languages, and have more social features like following. We’d already done some work for Teachers Without Borders deploying a set of Managing News sites, including one localized into Chinese, and an Open Atrium hub site with the OpenId Simple Sign On stack.

When we originally deployed these sites, we didn’t have a good way of tracking what had been added or changed from the standard Open Atrium and Managing News platforms. Each of these platforms had a number of extra modules deployed, mostly to power the authentication infrastructure, and a patch or two to some modules. As someone who didn’t work at all on either of those projects, it made getting into these two sites, as well as fixing bugs on them, a very confusing experience.

After an initial look at the code base, I decided that the best way to capture what was there and prevent others from suffering from the same confusion was to create make files for both projects. This meant examining each production platform and trying to distill what versions were running with what patches. Luckily Will, who had worked on this Open Atrium deployment, was able to help with the Open Atrium customization reconstruction. For Managing News I was a bit more on my own, though Alex was able to help me with some questions. Still, the process of reconstructing a customized platform that you didn’t work on is error prone. If it can be avoided, it should be.

The process I adopted for both of these sites was to fork the install profile into a new repository and start making changes. An “include” directive was recently added to Drush Make that allows you to include the contents of a remote make file in one that you’re creating. Using this I was able to delete nearly the entire contents of managingnews.make and replace it with an ‘include’ directive that pulled in the entire stable Managing News make file:

Once I’d done this I could add details to the make file about what was custom for this site. For example, I could add modules not normally a part of Managing News to the project, or I could add patches to modules defined in the stable make file. I could also switch the version of a module I wanted to use, such as switching from the public release of the mn_core module to a checkout from github.

Using a make file to track the customizations in a project leaves a record of which version of Open Atrium or Managing News you started from and exactly what is different. When a new developer comes onto the project, there is a definitive list of where the customizations start and how many exist. New developers don’t need to play a game of guess and check, instead they have a definitive record to look at. In these situations, the make file is your safety net.