Using drupal and SVN for module updates - best practice ?

by John McGeechan

Synopsis


 One way to release module updates using drupal and subversion


Overview

I have been using drupal with subversion for a while now and have found this to be a pretty good and thorough means of releasing module updates from a development to a production environment. The following approach assumes that your drupal core and modules are all held in subversion in a checked out branch on your document root....

Part one

The following are all done on your test site...
  • backup test database
  • let's assume you are updating module 'foobar', move the whole foobar folder to a safe location outside of your drupal module folder eg move it from ~/sites/all/modules/contrib (or wherever you have it installed) and move it to say /tmp/foobar
  • download latest compatible version of the module for your installation (drush is a very useful tool for doing this)
  • unzip download into ~/sites/all/modules/contrib (or wherever)
  • run drupal update.php, select update for the foobar module (if there are any)
  • clear cache
  • test, test and test again
  • Assuming that the testing is successful and you are happy with the latest version of the module, here are the steps I use for releasing into production...

Part two


Still in test...
  • move ~/sites/all/modules/contrib/foobar to a safe location eg /tmp2/foobar
  • move the original module back ie from /tmp/foobar to ~/sites/all/modules/contrib
  • ​restore your backup, you are now at the point you were at before you upgraded the module
  • tag your current branch with something like PRE_FOOBAR_1.2_UPGRADE
  • do an svn delete of  ~/sites/all/modules/contrib/foobar and commit the change remembering to add a useful message "removing old foobar module"
  • copy new version from /tmp2/foobar to ~/sites/all/modules/contrib
  • run drupal update.php, select update for the foobar module (if there are any)
  • clear cache
  • check again as belt and braces if you wish
  • assuming testing is ok do an svn add of ~/sites/all/modules/contrib/foobar and commit the change remembering to add a useful message "adding new version of foobar module"

In production
  • go to your production site, take site offline and backup your database
  • logon to server and do an svn update to get the new version of module
  • run update.php on drupal
  • clear cache
  • test and test again
  • if all is good bring site back online
  • if for whatever reason the upgrade didn't work (unlikely), you have a very quick and easy back out, restore your database, go to server and update the  source tree to the PRE_FOOBAR_1.2_UPGRADE, the site is now as it was before you did the upgrade. Bring the site back on-line and try to work out what went wrong

Explanation

  • Firstly the above is a very cautious approach. That's because I am very cautious. From years of developing I have generally come to the conclusion that anything that can go wrong, usually does. As most developers tend to swash their buckle much more than me I can imagine the approach would seem pedestrian to many, I have no truck with this
  • Second thing to say is that that set up works well for me in that I tend to have trunk checked out in both my development and production environments, code changes only ever happen in dev and are only ever committed in dev after thorough testing, production only every has svn updates. Multiple developers using their own developer branches can still of course use this logic, they simply would have to merge their branch into trunk at some point
  • You can of course not bother with moving the original module out of the source tree and instead simply unzip the latest version over the top, the reason I don't is because there is a small chance - however small - that a file left behind by an old version scuppers in some way the later version and yes I have heard of this happening. Also, I refer you to my first point about caution and my predilection for it
  • This approach can also be used on a major or minor upgrade of core, but in that instance, I would in dev (of course after backing up the DB) make a completely new branch in subversion eg DRUPAL-6.XX based on the current trunk, then I would switch to that. I would then delete all the core files and unzip the latest version in their place, then run an update.php, test and test again. If it works, in production you would back up DB switch branch, run update.
  • Of course you may currently be using github rather than downloading and unzipping, that works too of course

Post new comment

By submitting this form, you accept the Mollom privacy policy.