I manage a few Drupal sites, and have worked out two simple systems for making upgrades as painless as possible, one using diff and patch, the other using subversion. The two examples I'll use here don't really have customized code outside of .htaccess files and things in the sites/ folder, so these processes may require some tinkering if you've done core level customization. Hopefully these will be helpful to someone new to working with updating PHP applications, and if you're running any PHP applications you need to stay on top of security updates to protect your site and your user's information! Upgrading both of these sites today took me less than 10 minutes to do, but if you're attempting your first upgrade, you should understand what is going on and maybe even read through the whole Introduction to upgrading Drupal guide. I definitely leave out some of the recommended steps.
ckdake.com - no revision control
This site (ckdake.com) is just my personal things and could be restored from backup pretty easily without too much trouble, and I'm the main user so it's not a big deal if it's down for a few hours. Drupal 6.12 came out and here's what I did to upgrade:
cd /var/www/ckdake.com/ wget http://ftp.drupal.org/files/projects/drupal-6.12.tar.gz tar -zxf drupal-6.12.tar.gz diff -uF^f -r htdocs drupal-6.12 > upgrade.patch vim upgrade.patch patch -p0 --dry-run < upgrade.patch patch -p0 < upgrade.patch
And that's it! In vim, I removed patch entries that did things I didn't want (like overwriting custom things I have in my .htaccess file), and I also looked at the output of the dry run of patch to make sure it looked right. After doing those things I visited ckdake.com/update.php and walked through Drupal's update wizard (which didn't make any changes this go around). Perhaps I should have done a mysqldump to backup my database first, but I have nightly backups of the database and in several years of upgrading Drupal this way have never had a problem updating minor versions this way. There was no downtime for my site since this all worked right (as it usually does) but I've broken things before. And keep in mind, a 5.x to 6.x upgrade is not going to be this easy...
fastermustache.org - revision control
fastermustache.org is used by a lot more people and I try to avoid any downtime there, so this process is a bit more involved and lets me roll back changes a lot more easily. Here's the sequence for that:
cd /var/www/test.fastermustache.org/ mv htdocs drupal-6.12 wget http://ftp.drupal.org/files/projects/drupal-6.12.tar.gz tar -zxf drupal-6.12.tar.gz mv drupal-6.12 htdocs cd htdocs svn st
I now have a list of all changes for this release, and go through resolving things as needed. `svn st | grep "?"` gives me a list of files that need to be added, and I grep on other svn status codes to verify other changes. Once everything looks good, I update the live site:
svn commit -m "drupal-6.12 upgrade" cd /var/www/fastermustache.org/htdocs svn up
And then visit fastermustache.org/update.php to do any database changes required. This process also works for module updating:
cd /var/www/test.fastermustache.org/htdocs/sites/default/modules/ wget http://ftp.drupal.org/files/projects/date-6.x-2.2.tar.gz tar -zxf date-6.x-2.2.tar.gz rm date-6.x-2.2.tar.gz svn st # resolve all the issues as described above svn commit -m "date-6.x-2.2 upgrade" cd /var/www/fastermustache.org/htdocs/sites/default/modules/ svn up
And then one more visit to fastermustache.org/update.php and any needed database changes are made. Again, it would be a really good idea to do mysql database backups before running `svn up` on the live site, but I trust Drupal to treat me well for these sorts of updates. Perhaps once something breaks horribly, I'll post some steps on how to recover from problems.
I never thought I'd see this from this particular crowd of companies but here's the basic timeframe for those of you that don't follow this. For years, Microsoft has claimed that Open Source Software couldn't provide a workable business model. In August 2003, Novell (another large software company) began embracing Linux as a solution for it's customers. In November 2006, Novell entered into a patent agreement with Microsoft which led to people complaining that Novell had "sold out." Microsoft says that Linux infringes on their patents, Novell said that they didn't agree but still had a partnership with Microsoft working towards the same goals.
And the kicker: Microsoft responded with a press release saying that they and Novell were _Agreeing to Disagree_ on an issue that many see as the core component of the initial agreement! It'll be interesting to see how this pans out.