Stumbled over another slide set on Twitter:
http://twitter.com/brianlmoon/statuses/17140624730

I found the first slide set particularly interesting, when in the second part it goes into suggesting to release new code without showing the new features to the general public to better control the impact. In that way its similar to the way several commenters suggested doing DB changes with full BC in one step and then flip the switch to actually use the changes later on. Helps manage the size of the potential issues you would be facing and if you need to do damage control you are not taking away features, you are just fixing existing features for the user.

Not so sure about the second slide set. Sure it makes to document deployments and the type of deployment (hotfix with DB change, scheduled update etc) and the end result (performance regression, lots of bugs etc) in order to learn from the past and improve processes. But it also seems quite a challenge to get there. I guess it requires full logging on the CLI interaction during deployments/maintenance in order to be useful.

Yet another link I was send via twitter:
http://www.thenetcircle.com/2010/07/03/new-possibilities-offered-by-smart-deployment-scripts/

This one suggests basically changing your doc root to point to the current application version. This way its possible to maintain FS caches for each application version (meaning you can also prime the caches more easily).

@Tyrael
Im my case normally it isn't a problem if nodes upgrade at different time. Hg push/pull commands are fast enough, but if I really want to ensure the atomisation of the change I always can stop the webserver in the nodes and start it again when the change is done (if I can assume it of course)