Information Technology Reference
In-Depth Information
Are You on Autopilot?
As you are automating your database integration, a few things
may trip you up. It's easy for manual activities to unintentionally
accumulate in your database integration process. Try to resist this.
As Andrew Hunt and David Thomas mention in
The Pragmatic
Programmer
: Don't Repeat Yourself (or DRY, for short), keep your
build scripts “DRY.” An easy form of “duplication” to miss is when
we get acclimated to clicking through the database vendor's GUI
application wizard rather than interfacing through the command
line where it can run scripted. Another potential problem is the ten-
dency to wait until there are many DDL/DML changes before com-
mitting back to the version control repository. Database changes
can be pervasive, so try to make and check in small, incremental
changes to your database; this will make it easier to test and
debug.
A significant challenge on many software development projects is
making changes to the database structure. Many projects I've observed
typically use one shared database, so when developers make changes
to this shared development database they can adversely affect others
on the team—causing each developer's private build to break (if their
tests are part of the build). If developers have their own local code
“sandbox” to isolate their coding changes from other developers,
wouldn't it be great if they had a “database sandbox” too?
Multiple Database Instances
You may not have the resources to get a database for each
developer. In this situation, you could assign each developer a
separate schema on a central database server or use one of the
freely available, lightweight, open source equivalent databases.
Furthermore, many of the more widely used RDBMSs provide
free developer versions.
