What things are important to consider when managing a site using Drush make?

1 Answer 1


"Make files", in the Drush and Drupal context, define a set of modules, themes and libraries that make up a site. While one could stick the entire sites/all/modules directory into git, the make file is a lot faster to handle, both for git and the developers. Below is a make file from an actual project of mine. I've cut out a lot as the whole file is hundreds of lines, but I've retained enough to show all of the functionality I've used.

api = 2

; Core
core = 7.x
projects[drupal][version] = 7.14

; Contrib modules
projects[date][version] = 2.0-alpha4
projects[email][version] = 1.0

; Media and file_entity go hand in hand - please make sure they work together.
projects[media][version] = 2.0-unstable5
projects[file_entity][version] = 2.0-unstable5

; Cron modules
projects[ultimate_cron][version] = 1.6
projects[background_process][version] = 1.12

; Performance modules
projects[expire][version] = 1.0-alpha2
projects[cache_actions][version] = 2.0-alpha3

; Unstable modules
projects[menu_node_views][type] = module
projects[menu_node_views][download][type] = git
projects[menu_node_views][download][url] = http://git.drupal.org/project/menu_node_views.git
projects[menu_node_views][download][revision] = f46dd41eb8c4e693a6642a6c461afa57d99a6f1b

projects[filefield_sources_plupload][type] = module
projects[filefield_sources_plupload][download][type] = git
projects[filefield_sources_plupload][download][url] = http://git.drupal.org/project/filefield_sources_plupload.git
projects[filefield_sources_plupload][download][revision] = da374770b80fcbc0dab17158d38c8436ef29caca

projects[menu_token][type] = module
projects[menu_token][download][type] = git
projects[menu_token][download][url] = http://git.drupal.org/project/menu_token.git
projects[menu_token][download][revision] = 8c18fbb

; Libraries
libraries[mediaelement][download][type] = "file"
libraries[mediaelement][download][url] = "https://github.com/johndyer/mediaelement/zipball/2.7.0"

; Patches

; #1491150: node_load in menu_node_menu_link_insert is not safe - http://drupal.org/node/1491150
projects[menu_node][patch][] = http://drupal.org/files/menu_node-node_load-in-menu_node_menu_link_insert-1491150-1.patch

; Fix rendering of relation endpoints
projects[relation][patch][] = http://drupal.org/files/relation_table_endpoints_break.patch
projects[relation][patch][] = http://drupal.org/files/relation_bundle_permissions.patch

libraries[jquery-json-min][download][type] = "file"
libraries[jquery-json-min][download][url] = "http://jquery-json.googlecode.com/files/jquery.json-2.3.min.js"
libraries[jquery-json-min][download][sha1] = "2a4615b93c65dd50f92117c570121035a0327fee"
libraries[jquery-json-min][destination] = "libraries/jquery-json"

The api line defines which Drush make API to use for the rest of the file. One important thing to notice about the file, is that all modules either have a specific version, or point to a specific git commmit. We never have -dev versions in our files. When we show up at a client meeting, or hand over the make file to the Jenkins server, there must never be any surprises. The exact version included in the file should be tested and expected to pass all types of tests. This is important to be able to delivery something of high quality.

In my company, the general agreement is that every team provides a shell-script called "build", in the root of the repository, which is responsible for setting up the site, so that automated tests can be run by the same cross-team CI setup.

Module updates can be done quickly directly on sites for testing, but officially by updating the make file, and rebuilding the site.

My team currently uses this set of build-scripts. I'm working towards moving much of the functionality into a drush extension that will heavily use provision though. A CLI version of Aegir if you will.

  • 1
    Genius. Thanks for taking the time to write this up it's very helpful
    – Clive
    Jun 7, 2012 at 10:59
  • Yes, I agree with Clive, upvoting as a very useful post. I'm interested in not having to repeatitively install the same set of modules and patches. @Letharion I would warmheartedly welcome if you could elaborate some day on how you proceed with that. Do you install it locally or to remote server? Jun 7, 2012 at 13:40
  • 1
    Playing around with drush make. I totally understand the reason for putting fixed version numbers in there. However, how do you update them? Is there a drush make equivalent for drush up? At some point, you need to update your versions to the newest version (especially security updates). Having to do that manually with dozens of modules seems rather tedious...
    – Berdir
    Jun 7, 2012 at 20:07
  • 1
    Moar questions: Do you have a .gitignore file or how do you avoid commiting "maked" files? If yes, how does that look? Tried to do something fancy with wildcard and ! but that doesn't work for directories.
    – Berdir
    Jun 7, 2012 at 20:36
  • 1
    I don't really agree. Lack of -dev is what ensures consistency, not the other way around. It's each developers responsibility to ensure the patch applies, which may mean referring to a git revision instead of a stable release, but never an unpredictable -dev that can change from on build to another.
    – Letharion
    Mar 7, 2013 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.