My (deprecated) answer to the Drupal Deployment question

Jacob Singh did a presentation at DrupalCon London about “How to have an open relationship … with software (and still make paper)”. I’m one of the people he interviewed for his presentation.

One of the questions he asked, was this one:

How do you use version control, spreadsheets, text files, napkins, etc to track your customizations to Drupal modules and core? Until the DOG project is done, what is the best worst practice here? On the Gardens team for instance, we used a PATCHES.txt file which listed the date, author, description and link for every patch to core or contrib. low tech, somewhat functional. How do you do this?

He liked my answer so much that he told me I should write a blog post about it — even if I’d just copy my answer verbatim. I’d been wanting to do that for years now. “Better late than never”, right? Although it’s actually too late now, because this system was actually designed to work when Drupal’s code still lived at http://cvs.drupal.org…

So, here is my (old) answer to the Drupal Deployment question. Copied verbatim, only formatting and links have been added.

My deprecated answer

I’m still on Drupal 5 and 6, but am very eager to start using dog. I actually waited some time to see it materialize, so that my first Drupal 7 project would actually be in VCS in The Right Way, but since dog still hasn’t progress enough to be usable, I’m gonna have to go with another approach.

I used my own custom system based on svn, that pulled in the original d.o code from CVS. Yes, that means CVS in svn. I hate tarballs. I had a script that did the initial set-up. Summary: svn in CVS, symlinks + svn:externals magic. Basically, you’d have a core directory” with all of Drupal core in there (checked out from CVS, checked in to svn). The sites and profiles directories are symlinks to respectively ../sites and ../profiles (meaning that these are at the same level as the core directory. This then allows me to use my own installation profile (which comes with all the common stuff).

• core is actually an svn:externals checkout of my own version of Drupal core (with the CDN module core patch for D5/D6, that added D7’s hook_file_url_alter()).
• profiles is actually another svn:externals checkout, this time of my own install profile
• sites contained the custom code

This allowed for maximum code reuse.

Unfortunately, with the switch from CVS to git, all of this is now broken. Yay.

Patches were applied to my own Drupal core, or my own installation profile when it made sense to apply them to all my Drupal sites. The patch file then lived in a patches directory, with the filenames following a scheme (as described somewhere by webchick, IIRC) that includes the node ID and follow-up ID of where the patch was originally posted on d.o, allowing it to be looked up later, to see if it’s already been committed.

You can actually check out this code at svn://wimleers.com/drupalbase¹. And for ease of glancing, I’ve included the script to do the initial repository set-up. It includes a better description and something that roughly equates to an ASCII-art visualization of the directory tree.

This is also why I wrote the syncvsvn script back in 2008. Yes, this system is so old, but I never got around to do that All-Encompassing Awesome Write-Up. I’m still struggling to write (well, publish) anything at all if it’s not near perfection.

My current answer

I don’t have a full answer yet. I’d love to use dog, but that’s just not ready yet.

The only usable “system” that exists today², is Drush make.

I’m currently using drush’s drush rsync and drush sql-sync commands with great success. While it doesn’t offer the same granularity — I’ve lost the ability to diff between different versions — it’s still awesome. I’m able to easily get a clone of the site up and running on my local machine and to sync changes. Although you have to be very careful when doing so, it’s now at least easily possible.