Information Technology Reference
In-Depth Information
separation between the database team and the development team—
each team is focused on their own responsibilities with little collabora-
tion between the two. How can the product be integrated if the teams
aren't integrated? In a scenario like this, the database administrator, for
instance, may not be committing most of the database scripts to the
version control repository. These types of risks can then arise.
• Fear of making changes or refactoring the database or source
code
• Difficulty in populating the database with different sets of test
data
• Difficulty in maintaining development and testing environments
(e.g., Development, Integration, QA, and Test)
This negatively affects development, because the database is not
keeping up with the development team or vice versa. The software and
database developers may all be running different versions of the data-
base. Project members are unable to go to a single source point (ver-
sion control repository) to get the latest database. The following dialog
illustrates this problem.
Lauren (Developer):
I'm having a lot of problems testing on
v1.2.1.b1 of the database using build 1345.
Pauline (Database Designer):
Oh no, with build 1345, you should use
v1.2.1.b
2
, but I also need to make a few changes to it first.
Lauren:
I just spent four hours for nothing.
Pa uline:
Well, you should have checked with me first.
Solution
This solution would necessitate fundamental change for some projects;
it outlines an approach where the database is not a separate entity from
development.
• Place all database artifacts in your
version control repository
.
This means everything you need to recreate the database schema
and data: database creation scripts, data manipulation scripts,
stored procedures, triggers, and any other database assets.
