Why the blog?

To record development problems and hopefully subsequent solutions when working on an ongoing Java project.

When I started on this project, it was already 5 years old. I thought it would be useful see how introducing some XP techniques might help reduce some unwanted artifacts

A test-driven re-write would be my preference, but as is so typical, this has been ruled out as too much work.

So, hopefully continuous gradual change in the right direction will help.

Thursday, June 26, 2008

Database migration (current production to next release)
Current process
The system has a new release every 3 months. Days before testing cycle, DBA must edit and clean up all database scripts created by developers over the previous 2 months.
DBA stays up late several nights in a row, continually getting a dump of production, restoring to dev database, editing scripts, running them against database and then re-editing until a smooth migration script is created that runs right through, with all missing FKs, and indexes added.
Problems with this
  • DBA has no control over database changes because all the code has been written against it already, its too late to change the way its been coded.
  • Developers make bad database design decisions
  • DBA might make changes to the scripts that break the Java code
  • It takes up all the DBAś time for a couple of weeks and stops whole project as it is a bottleneck.
  • Developerś changes may not be compatible with each other.
Proposed Solution
Database Continuous integration - e.g. DBDeploy
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)