When an application is initially being developed life is relatively simple for the developer. There is an application and there is a database. You can tear down the database and rebuild it with impunity.
Once it has been deployed life gets a little more complex. Databases require upgrade scripts. You need to know which version of an app is on each users machine.
Life gets a little more complex once you have multiple deployment stages. The simplest is the QA/Test database and the Production Database. In almost all cases you want to script changes to the test database and only run the finished scripts against the production server (having backed it up first). Personally I find it far easier to control a database if every seperate item is scripted in a one feature two script file basis: Create Constraint/Drop Constraint, Create Table/ Drop Table. This works great for databases that you control directly. This becomes hard when you don’t have control.
Recently I have been working on a workflow application (Team Track). It is relativley painless to make chnages in the test environment. The problem comes when you want to deploy those changes to production. The migration tools do not migrate all of the options – the poor developer has to recreate everything by hand. Server tools should be fully scriptable. Developers need to think of how to partition their applications to cope with more complex production deployment stages.
MS Analysis Server 2000 also suffers this problem – you need to manually copy the changes from one server to another. What were the developers doing when they left out scripting?
What I described is the simple case. Oftern there are more stages (QA, UAT, Staging, Pre-Live, Live).
Developer Rants 