How I update Drupal core

When new security releases come out for Drupal, updating is definitely something that you want to do sooner rather than later. My philosophy has generally been to update my local setup immediately, let all of our developers/users know that I am going to update the shared dev server within two days, then schedule a time to update production based on any issues we find with the dev server. Since we run most of our sites as a rather large multisite, it means updating everybody at once, but hey, that's what dev's for, right? Well, we'll leave that for another discussion. Since last night, Drupal 6.21 and Drupal 6.22 were released, I have updated a couple of machines and been asked to help with some more, so I thought it might be nice to have this written down somewhere. The general way I setup Drupal sites is to download Drupal into a version specific directory (eg., drupal-6.20 and drupal-6.22) and the point a generic symlink named "drupal" at the version I want to be current. Then I can set my apache conf (or cpanel or whatever) so that the websites are being driven out of the "drupal" folder. This allows the upgrade process to happen with some fairly straight forward rollback ability if things don't work. And we never have to start/stop apache or reconfigure the conf files. So my directory looks like: lrwxrwxrwx drupal -> drupal-6.20 drwxr-xr-x drupal-6.20 (that's well stripped down, but hopefully you get the idea). The basic outline of what I do is to:

1. download the new version of Drupal
2. backup all of our databases
3. move the sites directory from the existing drupal-6.20 to the new version
4. delete the symlink and repoint it at the new version
5. run update.php on each site in the new multisite
6. clear caches

The first thing I do is to download the new version next to the existing version, not overwriting: drush dl drupal-6.22 --drupal-project-rename=drupal-6.22 The drupal-project-rename parameter is necessary because drush wants to rename the folder drupal by default. So now our directory looks like this: lrwxrwxrwx drupal -> drupal-6.20 drwxr-xr-x drupal-6.20 drwxr-xr-x drupal-6.22 And of course, to be safe, we backup our databases. If you have a working drush setup, you can easily run the following: drush @sites sql-dump --root=/path/to/drupal --yes --result-file=/path/to/your/drush-dumps/@DATABASE_@DATE.sql If you have a good place to put sql dump files and know the full path to your Drupal root, drush will go through and dump each file. Next, we want to move the existing sites directory to the new version, but we have to get the new, but empty sites directory out of the way. rm -rf drupal-6.22/sites; mv drupal/sites drupal-6.22 And remove and repoint the symlink for drupal rm -f drupal; ln -s drupal-6.22 drupal As of this point, all of our sites are running on Drupal-6.22. However, if the new version has database changes (as 6.22 did) we need to run update.php on all of the sites. I also tend to clear cache here just because... Luckily, drush makes this easy as well. drush @sites updb --root=/path/to/drupal --yes drush @sites cc all --root=/path/to/drupal --yes If all goes well, we can do the same on dev and then on production. The key here is that if something does go wrong, you can basically reverse the process, put the sites folder back into drupal-6.20, run drush sql-cli /path/to/that/dump/we/made.sql and repoint the symlink back to the original folder. If you're extra careful, you might even throw in the whole process of turning the site offline, disabling all of your contrib modules, etc. but so far, *fingers crossed*, I haven't needed to do that for minor version upgrades. Or if I do, I find that out on my local machine before blowing up a production system. drush @sites vset site_offline 1 --yes; drush @sites vset site_offline_message "We're upgrading Drupal, be right back." But remember to turn them back on ;-) drush @sites vset site_offline 0 --yes My next approach will be integrating git into this whole process... git pull, git checkout 6.22, drush @sites updb... But not yet. Soon, but not yet.