I haven't done a routine deployment in the middle of the night for years. Here's a post (of mine) that's a little longer on details. http://blog.ministryofcodi

I haven't done a routine deployment in the middle of the night for years. Here's a post (of mine) that's a little longer on details. http://blog.ministryofcoding.com/2011/06/29/always-be-shipping-real-world-continuous-deployment/ http://blog.ministryofcoding.com/2011/06/29/always-be-shippi... I boil it down to this: The safest change to deploy to a stable system is the smallest change possible. Most of my changes don't require schema changes at all. The application itself, on startup, verifies that the database has the tables/columns it needs in order to work. If it doesn't, it will CREATE TABLE or ALTER TABLE appropriately. I try to avoid backwards-incompatible schema changes whenever possible, so I can rollback. It's always safer and easier to add a new table or column than to delete/rename an existing one. Something wrong with the code? Rolling back won't send you back to an incompatible state. I use an ORM instead of stored procedures, because I find them a lot more friendly with this general process, you don't have procs that expect a particular parameter signature. You may need to decouple your db-changes deployments from your non-db-changes deployments. Doing that can at least make the non-db-changes deployments a lot less painful.