Database Merge and Build Automation

Continuous integration and delivery is becoming the norm for application code, particularly in today’s agile environment, but databases are frequently being left behind. DBmaestro TeamWork bridges the gap between application code and database development, enabling true merge and build automation for the database.

DBmaestro TeamWork’s merge and build automation offers numerous benefits, including:

  • A 95% reduction in deployment costs
  • The ability to deploy database changes in accordance with business requirements
  • Utilize impact analysis – not damage control – with three-way, baseline-aware analysis
  • Merge database code with unparalleled ease
  • Build a continuous integration environment containing all database changes
  • Deployment risk mitigation and substantially reduced downtime
  • Achieve true database release automation

Empowering Agile Team Collaboration

With only 13 percent of surveyed companies reporting that they are able to automate the continuous delivery process for the database, and the rest plugging the automated process with various manual steps, the need for a true automated solution for the database is clear. DBmaestro TeamWork offers simple, yet highly effective tools for mitigating the risks typically associated with automation.

System Integration is Both Risky and Time-Consuming

During the typical integration process, several teams merge their code changes in order to build a single environment that reflects all changes. Today, using agile methodologies, merging the code produced by several teams is a day-to-day reality.

As all teams work on the connections (integration points) between their code during the integration cycle, environments are prepared and the integrated modules are tested. But following every integration failure, a blame-storming game ensues in effort to determine which team was responsible for the integration issues. It’s messy, complicated, and wastes valuable development time.

Even if we don’t have teams working in parallel development, database configuration drift is not an issue to take lightly. Changes that we create in the development environment might fail in QA or crash in pre-production if the database structure is not as expected, or code overrides might occur if the target environment holds more recent code than our source holds.

Of course, existing SCM solutions make the integration of changes to native code (C#, C++, Java, etc…) much easier and more manageable. It’s easy for one to review changes implemented by each team and determine how best to merge them, discover conflicts, and determine whether individual changes should be implemented, postponed, or discarded entirely.

Database code is equally as (if not more) important as your native code, yet successfully merging changes made by multiple teams, or dealing with configuration drift, is not so simple when it comes to the database. You can’t simply copy-and-paste code changes to database objects; SQL and Oracle databases have a special syntax for modifying objects, adding and deleting columns, changing a column’s data type, and so forth. Because of this complexity, most of the time and effort spent during the integration cycle is dedicated to preparing the database migration script.

Read More

Compare-and-Sync Tools Fall Short for Database Merge and Build Automation

Standard compare and sync tools are unaware of changes made in the target environment, introducing the possibility of overriding production hot-fixes or work done in parallel by another team. Compare and sync tools are great for finding out what is out of sync, but not so great for automating deployments – it requires manual inspection, which isn’t compatible with the ever-growing need for speed in today’s development climate.

Typically, the build process requires manual inspection and analysis in order to determine whether changes should be reflected in the script in the target environment. DBmaestro TeamWork’s Baseline Aware Analysis offers complete, automated three-way analysis, comparing not only the source and the target, but the baseline as well. This automated process effectively identifies configuration drift which prevents developers from safely executing scripts.

Read More

Baseline Aware Analysis Enables Database Merge and Build Automation

DBmaestro TeamWork utilizes Baseline Aware Analysis, a three-way analysis and the only solution for obtaining the key information necessary for ensuring that all changes are ready to be released. It’s the only way to avoid overriding critical changes that exist in the target environment: through a three-way analysis of the Source, Target, and Baseline. A baseline is a reference point of view – for example, your previous development label/version — so if you are about to deploy v6.3 of your database changes, a baseline can be version 6.2.

DBmaestro TeamWork automates the merge and build process by identifying which changes are safe to deploy and providing a safety net for out-of-process updates using the following criteria:

  • If the Source, Target, and Baseline are identical, no change was introduced and no action is needed.
  • If the Source differs from the Baseline, but the Target and Baseline are identical, that means a new update was introduced to the source environment, and no conflicting change is introduced to the target – hence source changes should be deployed to the Target.
  • If the Source and Baseline match, but the Target and Baseline do not, that means the source environment has not changed, but a change was introduced to the target environment (another team has deployed their updates, a hot fix was introduced to production, etc.). In this case, target changes should be protected in the Target environment, and should not be overridden with out-of-date revisions from the source.
  • If the Source and Baseline are different, and the Target and Baseline are also different, that means that we have a conflict: changes where introduced to the source environment, and were also introduced or deployed to the target environment for the same exact object. It is clear that you can’t use the source revision – and override changes in the target environment, and also, you can’t use the target revision – and ignore source changes. A merge action is required and the safety net is activated in order to allow the merging of changes.

In the modern, complex development climate, the database is getting left behind. DBmaestro not only makes continuous delivery for the database a reality, but it allows you to once again make your database the strongest link – as it should be.

Read More