During the integration cycle, all teams work on the connections (integration points) between their code, the environments are prepared, and the integrated modules of the application are tested. Every integration failure is a candidate for blame-storming to determine which team was responsible for integration problems.
Existing SCM solutions make the integration of changes to native code (C#, C++, Java, etc...) much easier and more manageable. One can review each team’s changes and decide how to merge them. One can determine whether there is a conflict and decide whether a change should be implemented or postponed or discarded.
Database code is an integral part of the application and changes to the database objects are part of the version changes. However, the task of code merging is not as easy when dealing with database code as it is when dealing with native code. One cannot simply copy-and-paste code changes to database objects. Databases have a special syntax for modifying objects, adding and deleting columns, changing a column’s data type, altering a package, etc. Therefore, during the integration cycle, most of the time and effort is spent preparing the database migration script.
There are compare-and-sync tools that compare two database schemas and show the differences between them, but there is a huge risk in relying on these tools. The risk results from the inability to determine the origin of each change. Was the change made in a team’s development environment or in the integration environment after another team had already integrated their changes? This question is difficult to answer without comparing the database schemas to a baseline and without having an accurate audit trail of the changes in each environment (which is an important aspect of version control).
dbMaestro TeamWork has a simple and easy-to-use command line interface to automate the deployment of any database schema to any other database schema. The deployment can be from several development environments to a single integration environment or within a continuous integration environment – triggered by Checking-In a change to a database object or to the UAT (User Acceptance Testing) or production environment.
Implementing dbMaestro TeamWork in the development environment eliminates an important source of human error: manually produced deployment scripts. It is important to produce a single deployment script for structure and meta-data. dbMaestro TeamWork automatically generates a single deployment script that contains the structure changes and meta-data changes for a new application or an upgrade. This automatically generated script eliminates human errors in deployment scripts that are often not discovered until the application crashes in the production environment.