Continuous Database Integration - Continuous Integration - page 128

Julie (DBA): Do you guys need any help?
Scott: Yeah, we are having a performance problem on one of the que-
ries. Do you have time to look at it? Also, I think we need to denormal-
ize the PRODUCT table. Can you model the table changes, prototype
the DDL changes, and set up a code branch so Nona can modify her
code for your changes? When you two are satisfied with the changes,
merge the branch and commit it to Subversion so that they run as part
of the integration build. Thanks, Julie.
Nona: . . . Sure, Scott. Should we use the test database rather than the
development database?
Scott: Yeah, just run ant -Denvironment=test db:refresh .
The developers and DBAs, who often perform roles that seem oppos-
ing or distant, are now continually working toward the same goal, and
both are accomplishing more of their tasks that require analysis or
design.
Questions
These questions can help you determine your level of automation and
continuous database integration.
■ Are you capable of recreating your database from your automated
build process? Can you rebuild your database at the “push of a
button?”
■ Are the scripts (build and SQL) to your database integration auto-
mation committed to your version control repository?
■ Is everyone on your project capable of recreating the database
using the automated build process?
■ During development, are you able to go back to prior versions of
the database using your version control repository?
■ Is your database integration process continuous? Are your software
code changes integrated and tested with the latest database when-
ever you apply those changes to the version control repository?
■ Are you running tests to verify the behavior of your database stored
procedures and triggers?
■ Is your automated database integration process configurable? Are
you able to modify the userid, password, unique database identifier,
tablespace size, and so on using a single configuration file?