Friday, June 16, 2006

Want to see VS2005 strangeness?

Ran into this one with one last week...

Explaining 'The Binding Handle Is Invalid'

I especially appreciate (and chuckle over) his apology.

Thursday, June 01, 2006

Agile Database Deployment

A common problem in enterprise software development is how to manage database structure changes. In some environments this problem is solved by introducing a bottleneck commonly known as a DBA. The DBA is responsible for all changes to the structure of the database. DBAs are busy people and will often place low priority on a task to make minor yet important changes to a database. In order to stay Agile it is advisable to steer clear from the centralization of responsibility for database changes.

Another common solution is to permit all developers to make changes to a central development database. Changes can be introduced as developers see fit, however, they must be scheduled and will likely break the software until the associated code changes are committed. Again, not a very Agile solution as dependencies between

A more Agile way to manage database changes is for each developer to maintain their own copy of the database. This allows changes to be made without the risk of interrupting the work of other developers. The problem with this approach is that database structure changes need to be propagated to the other developers. One solution is to dump the database structure to an sql script after database changes are made and checking that file into your source control repository. When a developer wants to rebuild their database to get new changes they just have to execute this script. I typically include a database structure dump task in my NAnt script to occur after (and if) all my tests have passed.

There are problems with using a monolithic create script. For example conflicts are ugly to resolve and object drops can cause major headaches. The evolution of a monolithic script is to generate a separate script for each object and keep them in a file structure mimicing the logical orginazation of your database. For example we have the following structure checked into Subversion:

sql/tables/Project.sql
sql/tables/Customer.sql
sql/storedprocedures/InsertProject.sql
sql/storedprocedures/UpdateProject.sql
sql/storedprocedures/GetCustomer.sql

Now drops are evident because a file will be missing and conflicts are easy to manage because they are confined to a single small file. It also becomes apparent after a source update that there are changes to the database and what those changes may be.

Of course tools exist to assist with database structure synchronization but the solution above has been quite successful in my development environments to date. If you require something more robust then DBGhost may be a good place to start.

 
s