(that's well stripped down, but hopefully you get the idea). The basic outline of what I do is to:
lrwxrwxrwx drupal -> drupal-6.20 drwxr-xr-x drupal-6.20
- download the new version of Drupal
- backup all of our databases
- move the
sitesdirectory from the existing drupal-6.20 to the new version
- delete the symlink and repoint it at the new version
update.phpon each site in the new multisite
- clear caches
drush dl drupal-6.22 --drupal-project-rename=drupal-6.22
drupal-project-renameparameter is necessary because drush wants to rename the folder
drupalby default. So now our directory looks like this:
And of course, to be safe, we backup our databases. If you have a working drush setup, you can easily run the following:
lrwxrwxrwx drupal -> drupal-6.20 drwxr-xr-x drupal-6.20 drwxr-xr-x drupal-6.22
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
drush @sites sql-dump --root=/path/to/drupal --yes --result-file=/path/to/your/drush-dumps/@DATABASE_@DATE.sql
sitesdirectory to the new version, but we have to get the new, but empty sites directory out of the way.
And remove and repoint the symlink for drupal
rm -rf drupal-6.22/sites; mv drupal/sites drupal-6.22
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.
rm -f drupal; ln -s drupal-6.22 drupal
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
drush @sites updb --root=/path/to/drupal --yes drush @sites cc all --root=/path/to/drupal --yes
sitesfolder back into drupal-6.20, run
drush sql-cli < /path/to/that/dump/we/made.sqland 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 --yesMy 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.