in reply to
Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance
One thing I learned is to use chroots for test environments (This only applies for unix-like systems, I think). Ideally, you'll have a chroot for each version that you should care about (production, integration test, development test). Each chroot has a copy of the webserver *and* the database, and before an integration test, make a copy of the chroot so you can repeat the test. This is saving me a lot of time, as, to fix a bug in production, I can just spawn (creating a copy first) my production chroot (which is a clone of the real production) to find and fix the bug.
This is combined with having a Tag in the revision control system (in my case, CVS (Yes, I know many are switching from CVS to SVN, but I do like the file-oriented nature of CVS)) for every version you care about. In addition to what is said in the link the OP cites, I consider the HEAD as "sacrosant" also. Ideally, HEAD would not only "at least compile", HEAD *MUST BE RELEASEBLE AT ANY TIME*, to do that, every development is made on a branch tag and is only merged to HEAD when all tests passes.
Ah, the fact of having a tag for each version, makes it possible to take the production version to only fix the bug in question without "contaminating" it with the new features^Wbugs...