Just posted for my own reference - here's my workflow for updating a D6 (probably also D7) website using drush. Comprehensive information about all drush commands can be found on the http://drush.ws/ website. If you're not yet drinking the drush kool-aid, you need to—if you use a Linux server, of course.
- Visit admin/reports/updates page on your site, read through any relevant release notes for required updates (to check if there are special requirements for said update).
$ drush @site pm-updatecode <module1_shortname> <module2_shortname>(add all modules to be updated)
$ drush @site updatedb(updates the site database - update.php)
$ drush @site cc all(clears all caches on the site)
The reason I do this manually, instead of running something like
pm-updatecode is that I like the granularity and security of doing all the updates discretely—especially when I'm updating a larger site, where I like to know exactly what's happening when I update.
For Drupal core updates, at least in D6, I always copy the files in by hand (even though drush can handle this), because I just don't trust Drush with that operation—especially if I have other files included in my root directory for other purposes. (Plus, using git, this is a breeze. When I used SVN or CVS, it was a major pain, due to all the 'CVS' or '.svn' directories that had to be maintained).
After finishing the drush process, I do a
$ git add .,
$ git add -u, then
$ git commit -am "Updated <modulename1>, <modulename2>, etc." (after testing the site thoroughly, of course). Then I push the changes to production, do an
updatedb on that server, and breathe a sigh of relief when everything's working perfectly.
Anyone have a better idea for leveraging drush for updates? One thing I wish I could do is maintain patches when doing drush updates on a module, instead of having to re-download and apply the patch.