From streamlining your workflow to providing automated change history tracking, database release automation, and automated merge and build, all with a single source of truth you can trust, DBmaestro TeamWork™ simplifies the day-to-day responsibilities of DBAs with complete Database Lifecycle Management (DLM) capabilities.

With TeamWork™, you can reap the benefits of bringing CI and CD to the database

Automating database changes
Automatically Generate Database Structure and Lookup Content Changes Script.

If you are either generating or receiving the database change scripts, you probably want to make sure that it contains all of the relevant changes as well as the order of the DDLs and DMLs statements, which are based on the objects’ dependencies. TeamWork’s Deployment Manager generates the database structure and lookup content changes script based on the objects dependencies and even for cross schema/database dependencies. TeamWork™ allows you to select the objects which will be analyzed by many criteria such as: application versions, labels, object type, object name, change request or business requirements requests.

One of the basic things a DBA will learn is how to create a backup of the schema before any major operation. TeamWork™ allows you to save a snapshot of the schema in the TeamWork™ repository. You can review the snapshot using the same interface you used to review the changes made to the objects, as well as compare between two snapshots and generate deployment script based on the differences.

Read More
Deploying to Production efficiently and safely
Baseline-Aware Impact Analysis Engine Ensures Changes are Safe to Move to Production.

A Baseline-Aware Impact Analysis engine leverages a single source of truth to ensure that all changes are safe for release, going above and beyond standard compare-and-sync tools to not only identify when conflicts exist, but pinpoint the precise location where changes were made. This saves hours of time spent retracing steps and tracking down developers to determine which changes should be deployed, which changes should be discarded entirely, and which changes should be saved for later use. When manual intervention may be required to safely merge changes from different environments, TeamWork™ issues a red flag to stop the cycle, ensuring that critical changes are not overridden in the target environment.

All of these benefits contribute to better overall development collaboration, enabling you to track down the origin of changes and discuss changes with the right team members to reduce the number of bugs and errors released.

Read More
Streamlines DBA Responsibilities
Review database change history including: Who changed a database object, What the change was, When they changed it and Why they changed it.

As a DBA, you are responsible for the database, and if a problem arises in the database, you will be getting the first call. Whether or not you’re directly responsible for problems, you are likely tasked with tracking down errors, identifying which developers introduced the errors and remediating issues promptly.

Database changes do occur; in fact, most companies report that they make changes to the database frequently. Whether it’s a bug that was found and must be fixed, a performance improvement, or even a new release, you must have the ability to review the structure and lookup value changes easily, as well as to relate them to the relevant business Change Request (CR) in order to understand the nature of the change.

TeamWork™ enables you to review the history of structure and lookup content changes that occur in any environment (development, integration, tests) even before you implement them in the production environment. It is impact analysis, not damage control – meaning you can assess the impact of potential changes and determine whether changes are safe for release before moving them to production.

In addition, TeamWork™ saves a version of each change in its repository. With the click of a button, you can easily return and examine the object definition or lookup content before any changes are shipped to the production environment. While reviewing the history of each change, you can see Who made the change (by the Windows account), When the change was made, What the change was (you can compare the definitions between two revisions) and Why the change was made (the business requirement drives this change – the CR). DBmaestro TeamWork™ automatically maps changes to relevant business CRs, saving your developers hours of time they may otherwise spend on manual documentation.

Read More
Support for Policy-Based Database Development and Deployment
Policy-Based Development and Deployment Enables Permissions, Roles, and Responsibilities Management for Streamlined Development.

TeamWork™ is integrated with the organization Active Directory, so you can use this integration and add another layer of permissions to structure and lookup content changes. Frequently, the entire development team connects to the database using the same login account, for the sake of simplicity. But this easy solution introduces potential problems. With all users relying on the same user account, everyone on the team has the same permission levels and access to changing any objects and lookup content within the database at any time.

TeamWork™ Change Policy enforcement, which is embedded in the database engine, allows you to specify which Active Directory users or groups can change certain objects in the database by object type and in which environment. This completely prevents unauthorized changes to the database, adding a layer of security every DBA will welcome. This policy-based development and deployment means that you control who is able to make changes to specific objects and content within the database, avoiding unauthorized changes that can wreak havoc on days and weeks of valuable development work.

For example: Developers can change any code (packages, procedures, functions) and lookup content in the development and test environments, but are not permitted to change the table structures, while only the ADBAs have permission to alter table structures. In the production environment, which is part of your responsibility, only the DBA team is allowed to make any structure or lookup content changes. That means even if by accident a developer or ADBA uses a privileged login & password, he/she will not be able to make any changes he or she should not do, thanks to TeamWork’s change policy enforcement.

Read More