Safe, Productive and Secure Agile Enforced Database Source Control
DBmaestro Source Control is the leading database configuration and change management platform, enabling software developers and DBAs to add real Source Control Management functionality to their database world. DBmaestro’s change policy enforcement is a unique technology designed to ensure that your database’s source control follows change management best practices and delivers a single source of truth. Undocumented, out of process changes and code overrides can become a thing of the past.
DBmaestro Source Control is designed to interface with leading SCM software packages, enabling a complete and safe collaborative development process – akin to processes you’re accustomed to working with and have proven effective for native /application code development (Java, C#, C++, etc.).
With DBmaestro’s Source Control database enforced source control, you can:
- Guarantee a Single Source of Truth for your Database Schema and relevant Data
- Enable teams to work safely and simultaneously within the same environments eliminate the possibility of overriding critical changes made by another developer
- Rapidly implement changes without lengthy development cycles that include time-consuming, frustrating manual processes
- Associate database changes with task based development (Tasks, work items, trouble tickets etc.)
- Integrate with existing development tools, allowing your team to work within the environment they’re already comfortable with, while taking advantage of advanced functionality
Safe, Productive and Secure Agile Database Build Engine
Automatically generating deployment scripts, can save hours of valuable development time otherwise spent on manual processes. Utilize an effective and safe 3-way merge and build engine to support your agile team development, making sure your database is DevOps ready!
- Automate database branches and merges
- Consolidate changes into an integration environment
- Safely build changes to be released to production with a fully automated, bullet-proof deployment process
- Build database changes in accordance with business requirements
- Easily create rollback packages
DBmaestro Source Control is the only solution offered which covers Database Lifecycle Management (DLM) for Oracle, SQL Server, from development through build and release automation.
Simple Check In and Check Out Functionality
DBmaestro TeamWork enforces source control through robust Check-In/Check-Out policy enforced mechanisms at the database level. This enables development teams to safely work in the same environment, all while ensuring accurate tracking of changes and protecting all development environments.
This functionality makes it possible to use the same process of building native application code – using only changes which are documented in the source code repository – for database changes. Without the check-out, check-in process, it’s possible for two developers to make changes to the same object script simultaneously. In this case, when updating the script in the database, one could easily override or revert changes introduced by the other developer. DBmaestro’s database enforced source control process completely eliminates this possibility and enables true development team synchronization across dispersed development teams.
With DBmaestro TeamWork, changes can be deployed quickly, enabling companies to rapidly implement changes and improvements without the long, drawn-out development cycles rife with manual processes and frustrations.
Database Source Control on Both Objects and Data
It’s not enough to enforce source control for database objects, ignoring the meta-data that influences application behavior and can create equally frustrating conflicts in different environments and deployment phases. DBmaestro TeamWork enables enforced source control for the entire database – schema objects (table structure, columns, indexes, foreign keys, etc.), database code (procedures, functions etc.) and meta-data (parameters tables, lookup content, dictionary tables etc.), all using the same check-in, check-out process that prevents out-of-process changes and conflicts resulting in the overriding of objects or data that should be protected. DBmaestro ensures that due process and development best practices are followed.
This process allows you to leverage a single source of truth for database safe deployment automation. And by correlating the check-in with a specific task, it’s no longer a mystery which database changes relate to which tasks. Information regarding changes is saved in the repository, allowing the retrieval of only relevant changes and objects when building a list of tasks.
By utilizing database version control, development teams are able to perform comprehensive roll back and keep track on object versions and revisions, seamlessly and efficiently.
Integration with Existing Development Tools Offers Advanced Usability
DBmaestro TeamWork provides working interfaces for multiple IDEs and development tools, allowing developers to stay within the development environments they’re already familiar with. That means onboarding is a breeze, as your team can continue to work with the tools they are comfortable with while reaping the benefits of DBmaestro’s unique enforced source control functionality.
TeamWork enables consolidation of development information and change history from several development branches or servers, achieving one single, trusted point of control. You’ll always know who made what changes, where, and why, with DBmaestro’s sophisticated, automated tracking functionality. With DBmaestro TeamWork, you can bring effective, enforced source control to the database, achieving a single, trusted point of control.
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.
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.
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.