Continuous Database Integration - Continuous Integration - page 123

included in the integration build that occurred at 10:30 AM . The inte-
gration build machine uses a single source point, provided by the ver-
sion control repository, to synchronize and test changes as a part of the
integration build.
Once you have automated your database integration and incorpo-
rated it into your build scripts, making it run continuously is simple.
Your database integration tasks, along with the rest of your build,
should be executed using one command (such as an Ant/NAnt target ).
To run your database integration tasks continuously, you only need to
make sure these database integration build task commands are exe-
cuted as a part of the automated build.
Give Developers the Capability to Modify the
Database
Each developer should have the capability to modify any of the data-
base scripts. This doesn't mean that every developer will modify these
database scripts, because not every developer will have the necessary
database expertise. Because each developer will have his own database
sandbox, each can modify the local database and then commit the
changes to the version control repository. This will reduce the DBA
bottleneck and empower developers to make necessary changes. The
DBA can evaluate the new changes to the repository by reviewing the
integration builds or working with the developers if the build breaks.
As the adage goes, with this additional authority comes additional
responsibility. Changes to the underlying database structure can have
far-reaching impacts on the system. The developer who makes changes
to the database structure must assume the responsibility for thorough
testing before committing these changes. We feel it is far more likely
in today's industry for a developer to have a knowledge of databases
and database scripting—and the DBA is still there to “oversee” what
changes, if any, move into the system.