Information Technology Reference
In-Depth Information
Broken Builds
Since you treat the database the same as the other source code, you
may experience broken builds because of a database error. Of course,
errors may occur in any part of your build: source code, deployment,
tests, inspections, as well as the database. When using CDBI, database
integration is just another part of the build, so the playing field is lev-
eled: Whatever breaks the build, the priority is to fix it. The payoff
comes after this; the fix is now integrated, and that particular issue is
prevented from recurring.
Break down barriers and make members of your database team a part
of the development team. You may already be doing this, but all too
often there is a “wall” between the DBA and the software developers.
As mentioned earlier, treat your database code and your other source
code in the same manner. The same goes for the people on your team.
This is probably the most controversial of the CDBI practices. We've
worked on teams that have used CDBI with the DBA on the develop-
ment team, and we've also seen the more traditional approach with the
DBA on another team, the database team. CDBI worked in both envi-
ronments, but it worked significantly better when the DBA was a part
of the team.
Some people ask, “If the DBA is no longer dropping and recreat-
ing tables, creating test environments, and granting access, then what
is she doing?” The simple answer is, “Now she can do her job!”—
spending more time on higher-level tasks such as improving database
performance, improving SQL performance, data normalization, and
other value-added improvements.
