 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 you are at.
Each database has the same
set of test user ids and passwords. Developers and database connections can use the same user ids on any of the
databases.
Each development pair will
release newly developed code into the source code safe, promote their bronze database to silver, and add a migration
script to a list. How you manage the list of migrations will depend on your data base software and how you access
it. This list of scripts can then be executed in sequence to migrate the production database when the new |
version is released to production. Independence from the application code is important since it can change causing
the migration script fail. Use an integration station to control the sequence
of changes.
At any moment in time the
new silver database and the currently released code version 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 data base migration
scripts and the most current development release match up ready to be released.
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
a script to create a new gold database with a predefined set of test data. Some data will be created by tests,
but providing an example in the database helps developers create reliable migration scripts. We found it useful
to create a new gold and migrate it to silver once a week to avoid the inevitable data corruption and to assure
ourselves that our migration scripts were 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. 
  |
