September 15, 2008

Bulk view

Drupal: Making our build system better

Hooray! We have running code, and we’re about to make another release after our code exits quality assurance. This means, of course, that we’ll need some way to differentiate the inevitable bugfixes that the next production release will require, and development of new features.

What’s the best way to do this? Making a release branch seems like a good idea. Here’s how I did it:

svn copy http://subversion.example.com/myproject/trunk http://subversion.example.com/myproject/branches/release-1 

Bugfixes for release-1 will be committed to the release-1 branch, while new development continues on trunk. Bugfixes will be periodically merged into trunk to make it easier to roll the next release, which will be the release-2 branch.

Next, I need to configure my local system so that it’s easy to switch back and forth. I could work with a single source tree for local.example.com, but that means switching back and forth. The best thing to do would be to have two separate source code directories: one for trunk, and one for production releases.

svn co http://subversion.example.com/myproject/branches/release-1 /var/www/example.com-prod

For each site, I’ll need

  • a source code directory
  • a database
  • entries in /etc/hosts
  • entries in my Apache configuration
  • a local site directory (ex: sites/dev.local.example.com) with settings.php
  • a QA site directory (ex: sites/dev.qa.example.com) with settings.php

I’ll also need to update my Makefile to make it easier to work. For example, the Makefile should connect me to the right database depending on which branch I’m on. How do I determine this? One way is to have an unversioned file that overrides some of the Makefile variables, and to include that file in my Makefile. I can do this by adding the following to my Makefile:

-include *.mk

and then creating a dev-local.mk file that changes the values of my variables.

I’ll need copies of the production database translated for the different domains, which means I need to update my deploy script and format it a little to make it easier to deal with all these options. Hmm…

This will be fun.

UPDATE: Fixed HTML tags. Thanks for pointing it out!

Drupal: Programmatically installing and enabling modules in the .install file

To make configuration management easier, we decided to make sure that all behavior-related changes are in the source code repository. So when I needed to add the reCAPTCHA module to the project, I needed to figure out how to programmatically install and enable the module with update code in another module’s .install file.

Here is some sample code to do so:

/**
 * Install and enable the captcha module.
 */
function yourmodule_update_1() {
  $ret = array();
  include_once('includes/install.inc');
  module_rebuild_cache();
  drupal_install_modules(array('recaptcha'));
  variable_set('recaptcha_public_key', 'PUBLIC KEY GOES HERE');
  variable_set('recaptcha_private_key', 'SECRET KEY GOES HERE');
  $ret[] = array(
    'success' => true,
    'query' => 'Installed recaptcha module and enabled it',
  );
  return $ret;
}