I upgraded a Drupal installation for a test project last week, just a point upgrade. In the interests of my own memory, here’s the timeline, copied from a bunch of post-its on my desk. Times noted are when I started doing each task.
9:06 mysql backup
9:14 file backup
9:16 set offline mode
9:18 switch to standard theme
9:19 disable extra modules
9:23 local new files (I have no f’ing idea what that means: moved the new version into the regular local folder?)
9:25 delete files on server and upload new version
9:31 try to run update.php
9:33 realize that I accidentally deleted/forgot to re-upload settings.php, modules & themes
9:40 run update.php
9:41 upload new versions of webform & nodequeue
9:43 re-enable modules
9:47 run update.php again (for the upgraded modules)
9:48 switch theme
9:49 switch to online mode
So: 43 minutes altogether, 33 minutes with the site offline, 9 minutes of THAT being the result of user error. (I suppose one should always allow time for user error.) Not bad.
Oh, and I’m going to the Drupal MiniCamp next weekend. 🙂
Hm. I’ve run faster upgrades, recently, by maintaining separate directories with each Drupal version. I copy the custom files (sites directories, sundry images and config files) into the new version, then switch a symlink from the old version to the new and run update.php. Generally that makes for a pretty quick transition. I’d be faster if I maintained an out-of-path copy of all the custom files.
And it would be even quicker if Drupal offered update by Subversion the way WordPress does. (I can think of a few other hosted apps I wish did that.)
That’s a darn good idea…this particular install is a “secret” project in a subdirectory of an existing site, but maybe when I go live I’ll set up something like that.
Also, the internet connection at work is often dreadfully slow.