Almost all (if not all - a sweeping statement I hesitate to make!) of our application code is coupled loosely enough to the DB to allow us to deploy database changes ahead of application changes. We insist that all stored procedure calls pass the parameters by name (i.e., EXEC storedProc @parameter1 = 'x', @parameter2 = 'y' rather than EXEC storedProc 'x','y'), so we can add parameters, with acceptable default values if necessary, without breaking the application code. Our application developers also write their code such that it works so long as the columns it expects are present in result sets and does not break if columns are returned in a different order or additional columns are included.

Since we database developers have to complete our work to a significant degree before the application developers can begin coding against it, the database changes are almost always ready for security review, testing, and deployment before the application code is finished. We usually push database changes through security review and QA and sometimes even deploy it to production before the corresponding application code. This keeps our security review and QA teams from being unduly burdened by big changes involving both database and application code. It also lets us find and fix any problems that show up in security review and testing while the application developers still have the hood up on their code to make any changes needed there more conveniently. Plus, we can deploy the database code to production at a time when we can roll back any changes if unexpected problems occur without necessitating a corresponding rollback of the application code.