Information Technology Reference
In-Depth Information
Supporting Multiple Database Environments
The next logical step after creating a local database sandbox is
creating different database instances to support multiple database
environments. For example, you may need to create a database
that contains all of your migrated production data. Assuming there
are many records in this database, you probably don't want to
include it in your local development database. Usually, this will
only be the DML (data changes),
not
the DDL (create, alter, and
drop statements to the database). By automating your database
integration, you can modify build script parameters to include the
data to support these environments. This way, you can execute
one command to provide data for different database environ-
ments. The same goes for versions. You may want to test new
code against a prior version of the database. Use automated data-
base integration to provide this capability with a “push of the Inte-
grate button.”
copied down to her workstation along with the other source code
changes, and her next private build will incorporate the changes in her
local database instance.
The next section identifies the reasons and approach for using a
version control repository for database integration.
Database Assets
Sharing your database integration scripts is a best practice, plain and sim-
ple. All software assets need to be in a version control repository, and this
includes all database assets. Such assets might include the following:
• DDL to drop and create tables and views, including constraints
and triggers
• Stored procedures and functions
