If I've just sent you a link to this page, it's because I realized I didn't explain how I usually do Drupal updates. Apologies for that and hopefully all of this is old hat to you. For anyone else who's stumbled across this page, here's a relatively high level overview on how to safely update your Drupal site within a major release (e.g. 6.18 to 6.19).

Step 01: Make a Backup of Production

Everything you ever do with a Drupal site should start here.

I prefer tarballs and mysqldump's, other methods include any sort of version control systems (SVN, Git, Mercurial) and replication, binlogs, or even plain old file copy for the database(s).

The method isn't that important, but you must have a restorable point to roll everything back to in case of failure.

Step 02: Create a Development Site for the Update

The production site backup is used to build a development site. This development site is only to be used for the QA to verify if the standard Drupal updates can be used in production.

Step 03: Create a Module Update Plan

If the site is reasonable simple a full update of everything is attempted, if not a combinations of different updates are applied until a sequence of update steps are found that do not cause errors.

In particular nasty cases, to reduce the scope of effects to custom modules, I'll only apply security updates first and then do incremental update / QA steps to compartmentalize error probability.

I do standard, rudimentary QA (e.g. front page loads, login works) before turning it over to the client for more comprehensive QA.

Step 04: Client QA

After the update plan is built, then the client does a QA of the development site and identifies any site errors or loss of functionality.

Okay, you as a client will hate this part. Sorry, very little I can do about that. You'll need to go through every function and process on your site and verify it works. On a small site, you'll probably end up loading every page your site has. On a large site you'll need to load a representative sample of each content type and load every specialty page type you have.

The client will need to create a QA plan, and checklist, during this step.

If you find problems, that did not already exist on your site, you will need to note:

URL:
User ID:
Click Path:
Problem:

and send that to me.

Step 05: Problem Resolution (bug swatting)

These issues are then resolved and the specific steps to correct them are recorded.

After all steps are identified to update the site to an acceptable functional state, I combine all the different recorded steps into a single plan. I wipe the development site, re-build it from a new copy of production, and I apply the full update plan.

The client then does another QA to verify the full plan works correctly. If not, then the plan is updated and the development site is re-built again until the recorded update steps do work correctly.

Step 06: Update Production

After an update plan is client accepted (yeah!), then a window is scheduled to update production. When this widow is, is at the client's discretion.

During the update window content updates are halted, the site is copied to a new area, the update plan is implemented to the new area, the new area is client QA'ed, then the server's domain pointer is switched to the new area, and content updates are re-opened. (Other methods are available, but this is the one I generally use.)

The window for no content updates will be variable.

Step 07: Aw Crap!

And hopefully we never reach Step 07, because something bad has happened.

If the QA fails in Step 06, the domain pointer is not switched, and content updates are immediately re-opened. And we go back to Step 04 in our brand new, sparkly clean, development area.

# # #

Clear as mud? It's really not as bad as it sounds, and once you've run through the process a few times, you'll feel you can do it in your sleep.

And that completes a relatively high level overview on how to safely update your Drupal site within a major release.

Best Regards,
Michael

Basic QA Plan / Checklist

These bullet items are extremely brief, with the understanding that QA will entail performing, and verifying they work correctly, all actions related to each item.

• Create a user
• Use the contact form and all other forms
• Create a piece of content for each content type
• Load and use any specialty views
• Create and process an order