 At the VCAPS project we
found ourselves faced with the problem of XP and a large database. Our database was Object Oriented, but a relational
database could be handled the same way. Remember that if you implement user stories customer value first your database
tables and normalization will become stable faster.
The key point is taking
the advice of Kent Beck, act as if the database is easy to change. Relational databases were created to be flexible,
so flex them. Kent also advises that when something is very difficult try doing it more often not less. That way
you get good at doing it and it won't be hard any longer. Get into the habit of migrating your database often,
you will make less mistakes not more.
The VCAPS solution was to
have a gold, a silver, and many bronze database versions. The gold is the one that resembles the production database.
The silver is a migrated gold database. Each developer has a bronze database migrated from the silver.
A bronze database becomes
silver when the developer's code is released. A silver database becomes gold when the production database is migrated.
It is important that everyone
can easily get a copy of the gold or silver data base to use as a bronze quickly and that we keep track of migration
paths. Setting up scripts to copy databases as files is very useful. You need one to make a copy of a bronze database
promoting it to silver, and one to restore the current silver to the local host, which ever computer that might
be.
Each database has the same
user ids and passwords. Developers and database connections can use the same user id on any of the databases.
Each development pair releases
newly developed code into the source code safe and promotes their bronze database to silver at the |
same time. (After the unit tests run at 100% of course!) At this point the new silver database and the currently
released code versions are exactly in sync. This is important and requires discipline to maintain.
At any moment in time the
gold database and the production release match up for production support. At any moment it time the silver data
base and the most current development release match up ready to run the unit tests at 100%.
Developers can integrate
often because it is easy to copy the silver database and check out the current released code at the same time.
The unit tests will run at 100%. Developers then add their own changes, perform any database migration, and integrate
until the unit tests are running at 100% again. This method is very fast and only takes a couple minutes.
To support testing we had
code to create a gold database with a predefined set of test data. Some data will be created by tests, but providing
a example in the database helps. We found it useful to create a new gold and migrate it to silver once a week to
avoid inevitable data corruption and to assure ourselves that our migration path was correct.
We did have an occasional
problem with migration. We didn't do as good a job of keeping track of changes as we should have. What we ended
up doing near the end was to formulate our migrations as executable methods on a DB maintenance object. This makes
the production migration more reliable and a non-event. 
eXPerience Software
  |
