andycao (11/30/2012)
Seriously, if you architect things properly then DB changes can and should go out way ahead of the apps.
David Benoit (11/30/2012)
We deploy database changes separately from code changes and allow for a layer of abstraction. The benefits here are tremendous although there is a more complicated framework that has to be in place in order to support this. However, when you are able to make database changes, apply the data to those changes, all in preparation and before the application "knows" about it, can really be a huge savings on the day of an application release AND can allow for some pre-change testing to ensure that the application is going to perform as expected.
I agree with the above. If you are releasing on an agile schedule, you will almost always know about the database changes first, before the application code changes are complete. The design of the system and the release process should permit database changes to be released independently of the code changes. That way, database changes are already there when the application changes are released. This technique splits the testing of the two and can easily result in a reduction of implementation problems and issues.