How to effectively manage a site with Drush make?

Question

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

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
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.