We are proud to announce that a new version of dbMaestro Teamwork™, the leading Database Change Management Solution for Oracle is GA and can be downloaded. This new release exposes many new cool features, such as:
Allowing to integrate business logic within the automatically generated deploy script. You can read more on this here.
Allowing deploying multiple schemas at once. dbMaestro TeamWork will create the deploy script(s) based on the objects dependencies even if they from different schemas.
Adding Labels on Modules. Labels can be used to name a specific revision of specific objects for later reference instead of saving the entire schema snapshot.
Major performance improvement across the product
Additional fixes in the new version include:
The internal schema (dbMaestro_teamwork) in the managed database was not refreshed when there was only one schema under TeamWork control.
Removing the dependency on Oracle User SID.
Data deployment script is based on tables dependencies.
Identifying changes of unique and non-unique indexes.
Known Issue: Add-In will not start when using ODAC 10g on 64bit. Click to see the solution.
One of the most challenges tasks in the Database Development world is to create the database migration script. There are many tools that help in this task by compare two database schemas and generate the synchronization script.
These tools focus on finding the structure differences of the database artifacts between the source and target schemas, some tools have the option to compare also lookup table content.
Up until now, you could not add your business logic in the automatic generated script. There are many scenarios the script generated automatically by these tools does not answer them. For example:
A column that allows NULL values now has a constraint that it cannot have NULL values (NOT NULL). The generated script will created the proper DDL command to enforce the NOT NULL constraint on this column but will not allow you to add your business logic that makes sure this column does not have NULL values before the constraint is enabled. Without this option, you may execute the script and it will fail in production.
dbMaestro TeamWork™ continues to lead the Database Version Control and the Database Deployment solutions. In the new version coming soon, TeamWork™ users, will be able to add their business logic for any managed objects (table, view, packages, …) and for many events types.
You can subscribe to our blog and receive the release notification.
In this post, we discuss how you can streamline the database development process, reduce development costs, and enforce change management best practices, using Database Version Control practices
Using the Check-Out & Check-In of database resources feature of our innovative database version control solution, dbMaestro TeamWorkTM Management Studio, prevents code overrides and out-of-process changes;
Checking Out and Checking In
From your dbMaestro TeamWork Management Studio console, select the database you want to work with from the tree on the left. Enter your schema password if prompted to provide it.
All of the database objects will be displayed in the center of your console. Right-click the object you want to work on and select “Check Out Object Definition”. Make sure the object you want is selected in the pop-up dialog box, then click “OK”.
Now you can update this object using the Oracle Client IDE of your choice.
Next, go back to the dbMaestro TeamWork Management Studio console, right-click the object that was changed, and select “Check In Object Definition”. When the pop-up dialog box appears, type in information about the changes in the “Comments” pane and click “OK”.
Associating Changes to Change Sets
When you Check-In your changes, you can link the changes to tasks in the “Assign to Changeset” area at the bottom of the screen. Choose the appropriate task to link to from the drop-down menu, and click “OK”.
Later, this enables you to deploy the changes made for specific change-sets while ignoring other changes. For example, you can deploy changes that fix one or more bugs while skipping other changes that are not yet ready to deploy.
Analyzing Schema Structure Changes
To review changes to schema structures, right-click the database object in the center of your screen and select “View History”. When the pop-up dialog box appears, highlight the revisions you want to compare and click the “Compare Revisions” button on the right side of the screen.
A pop-up window will display the changes made in both the base schema and the compared schema. This pop-up window allows you to review and compare changes. You can change the versions being compared by selecting different values in the combo boxes at the top of the pop-up window.
Making Table Content Changes
To change table content, right-click the name of the appropriate table in the center of your console and select “Check Out Data”. When the pop-up dialog box appears, make sure you have chosen the correct table and click “OK”.
Next, update the table’s content using the Oracle client IDE of your choice.
To check in the changed table, return to the dbMaestro TeamWork Management Studio console, left-click the name of the changed table in the center of the screen, and select “Check In Data”. When the pop-up window appears, make sure you selected the right table, then click “OK”.
In order to review changes in the table content, right-click the name of that table again and select “View History”. When the pop up window appears, select the revisions you want to compare and click “Compare Revisions” on the right side of the screen. Another window will display the changes in both the baseline and the compared tables.
The TeamWork security mechanism enables changes to Oracle databases objects to be controlled at the Windows account and group levels. TeamWork enables you to define your organization’s database change policy in order to prevent undocumented database changes and to control who can do what, to control when they can do it, and to see why they did it.
When people talk about database change control, they usually mean having an accurate audit trail of database changes. However, another factor that is often even more important is the ability to prevent anyone from making unauthorized changes. TeamWork provides both change control and prevents unauthorized changes by the DBA and IT teams.
We have found that in many of the organizations that have implemented TeamWork, developers are allowed to change database objects including packages, procedures, functions, and the content of lookup tables, but DBAs are permitted to change all objects including table structures. Likewise, QA users are only permitted to make changes in the QA environment and not in the development environment.
But, as a practical matter, all developers and all DBAs usually work with a single Oracle user account – the owner of the database objects. As a result, without TeamWork, every developer, every QA user and every DBA actually can change any object in the database at any time. TeamWork provides the ability to prevent unauthorized changes to the database structure and the data it contains, including unauthorized changes by users who do have authorization to access the database.
It is also not rare to find organizations that have the same password for the Oracle user account in all database environments: Development, Integration, QA, Pre-production and sometimes even in the Production environment. When using TeamWork, the administrator can give developers access to change packages, procedures, and functions in the Development and QA environments while restricting their access to the Production environment by only giving them access to review history.
Of course, most of our customers implement TeamWork in their Development environment before implementing it in any other environment. But we recently had one customer that had such a serious database security problem in their Production environment that they installed TeamWork in their Production environment before beginning to use it in other environments.
TeamWork provides advanced permission management capabilities that give you full control over who makes changes to your databases. This enables you to proactively prevent unauthorized modifications to database schemas and their related objects. TeamWork enables you to implement very granular access settings, giving users the right to modify only certain portions of each schema, based on their role and their responsibilities.
TeamWork not only controls the permission to make changes, it produces an audit trail of changes to the database, correlating each change (What) with the person who made it (Who), the date and time of the change (When), and the business reason for the change (Why).
For more information on these topics, see these useful links:
In this article, we highlight how to conduct routine activities, such as Checking-Out & Checking-In database changes and preventing “out of process” changes by using the Change Policy Enforcement feature of our innovative database version control solution, dbMaestro TeamWork™.
The sidebar is a pop-up window conveniently located on the right side of your console when you move the mouse to the right border of the screen. If you do not see it, open it by right-clicking the sidebar icon on the taskbar.
Assigning Objects to Modules
To get started, you need to open the project you want to work on. Click the second icon from the left at the top of the sidebar. When the pop up dialog box appears, select the name of that project and click “OK”.
You can add a new module to a project by right-clicking that project in the tree and selecting “Add New Module”. When the pop-up dialog box appears; type in the module name.
Next, under “Data Connections”, choose the database you want to select objects from. You will be prompted to enter a password for each database you select. After typing in your password, click “OK”.
All of the objects in that database are displayed. You can select multiple objects simultaneously. Highlight all the objects you want to assign, then right-click and select “Add Object to {module name}”.
When you are done, those objects will appear under the module in the tree.
By assigning objects to modules you can view the database changes from a project / module point of view and reduce development costs.
Checking Out
To Check-Out objects assigned to a module, right-click the object in the tree in the sidebar and select “Check Out Object Definition”. When the pop-up dialog box appears, make sure you have selected the correct object and click “OK”.
Go to your Oracle development environment and make any needed modifications to the object.
Analyzing Changes
To review and analyze the changes you have made, go back to your TeamWork sidebar, right-click the object, and select “View History”. A pop-up window will display all changes made to that object.
Click the “Compare to Live” button on the right side of the screen to compare the saved object definition with the live version. Another pop-up window will display all alterations made to both the saved and live objects. If all changes are correct, close the windows.
Rolling Back Changes
In case you want to rollback your changes, right-click the object in the tree in the sidebar and select “Rollback DB Object Definition”. In the pop-up dialog box, choose the revision you want to revert to from the drop down menu and click “Rollback”.
You can also rollback changes by right-clicking the object in the tree and selecting “View History”. Highlight the revision you want to revert to in the pop-up dialog box and click the “Rollback” button on the right side of the screen.
TeamWork will ask for confirmation of the rollback request before executing it. If everything is correct, click “OK” and close the History window.
Checking In
To Check-In the changes you have made, right-click the object in the tree and select “Check In Object Definition”.
When the pop-up dialog box appears, make sure you have selected the correct object and link it to any related tasks in the “Assign to Changeset” drop-down menu at the bottom. When you are done, click “OK”.
In this post, we discuss how you can streamline the database development process, reduce development costs, and enforce change management best practices.
Using the Check-Out & Check-In of database resources feature of our innovative database version control solution, dbMaestro TeamWorkTM Management Studio, prevents code overrides and out-of-process changes;
Checking Out and Checking In
From your dbMaestro TeamWork Management Studio console, select the database you want to work with from the tree on the left. Enter your schema password if prompted to provide it.
All of the database objects will be displayed in the center of your console. Right-click the object you want to work on and select “Check Out Object Definition”. Make sure the object you want is selected in the pop-up dialog box, then click “OK”.
Now you can update this object using the Oracle Client IDE of your choice.
Next, go back to the dbMaestro TeamWork Management Studio console, right-click the object that was changed, and select “Check In Object Definition”. When the pop-up dialog box appears, type in information about the changes in the “Comments” pane and click “OK”.
Associating Changes to Change Sets
When you Check-In your changes, you can link the changes to tasks in the “Assign to Changeset” area at the bottom of the screen. Choose the appropriate task to link to from the drop-down menu, and click “OK”.
Later, this enables you to deploy the changes made for specific change-sets while ignoring other changes. For example, you can deploy changes that fix one or more bugs while skipping other changes that are not yet ready to deploy.
Analyzing Schema Structure Changes
To review changes to schema structures, right-click the database object in the center of your screen and select “View History”. When the pop-up dialog box appears, highlight the revisions you want to compare and click the “Compare Revisions” button on the right side of the screen.
A pop-up window will display the changes made in both the base schema and the compared schema. This pop-up window allows you to review and compare changes. You can change the versions being compared by selecting different values in the combo boxes at the top of the pop-up window.
Making Table Content Changes
To change table content, right-click the name of the appropriate table in the center of your console and select “Check Out Data”. When the pop-up dialog box appears, make sure you have chosen the correct table and click “OK”.
Next, update the table’s content using the Oracle client IDE of your choice.
To check in the changed table, return to the dbMaestro TeamWork Management Studio console, left-click the name of the changed table in the center of the screen, and select “Check In Data”. When the pop-up window appears, make sure you selected the right table, then click “OK”.
In order to review changes in the table content, right-click the name of that table again and select “View History”. When the pop up window appears, select the revisions you want to compare and click “Compare Revisions” on the right side of the screen. Another window will display the changes in both the baseline and the compared tables.
Saving a snapshot of a golden copy is an essential step when upgrading a version. dbMaestro TeamWork enables you to use this archived version when deploying database version.
There are several events that we recommend saving a snapshot version. Whenever a schema is being deployed, you should save the source and target schema(s), for example:
From development to integration
From integration to test or additional development
From test to production or integration
From integration to development (rebase)
The “save version” procedure should be invoked in the source environment before running the Deployment Manager and in the target environment both before and after executing deployment scripts.
It is important to save the source version of the schema in order to have a baseline against which the next deployment from this schema can be compared. For example:
When deploying the nth version from the development to the test environment, saving the nth version in the development environment enables the (n+1)th deployment from development to test to be compared against the nth version as a baseline.
Saving the current version in the target environment before executing deployment scripts enables the organization to prepare a rollback script and implement a rollback, if necessary.
Saving the nth version in the target environment after executing deployment scripts enables the organization to use the saved nth version as a baseline when implementing the (n+1)th deployment to that environment. Comparing the two versions reveals important changes implemented in the target environment due to conflicts. These changes can be implemented as a quick fix to the (n+1)th version, redeployed to the integration environment of other teams, etc.
TeamWork’s 3-way analysis compares version A and version B against a baseline version. When different changes are introduced in version A and version B (a typical situation when more than one team works on the same database), TeamWork’s automatic conflict resolution engine recommends an intelligent solution whose combined code merges the changes from both teams into a single piece of code.
TeamWork’s 3-way comparison analyzes changes between a source environment (e.g., development) and a destination environment (e.g., integration) and compares each to a baseline environment (e.g., QA or a previous version).
TeamWork’s Deployment Manager (DM) highlights the origin of each change. If a change came from the development environment, the DM recommends deploying it. If the change came from the integration environment, the DM recommends ignoring it because it was already deployed by another team. If both the source and destination environments differ from the baseline, the DM recommends merging the changes by using TeamWork’s automatic merge engine that creates merged code with a mouse click.
When database development teams must work with more than one database schema to achieve the desired results, creating one project that includes all relevant schemas is the best approach to take. TeamWork provides a variety of features that make it simple and easy to effectively manage a project with multiple schemas.
TeamWork also provides advanced permission capabilities that give DBAs more control over their environments. Unauthorized, accidental, and incorrect changes to schemas and related objects can be proactively avoided by allocating granular access permissions that give members of a development team rights to only those parts of each schema that they are responsible for changing.
This document describes how to specify source, baseline, and target (destination) schemas for a 3-way comparison. It also describes how to use the 3-way compare and merge module to automatically resolve schema and data merge conflicts. Finally it describes how to automatically generate an upgrade script.
This document describes how to save database content, how to compare versions, how to review specific changes, and how to automatically generate a script.
In this post, we’ll explain the various steps required to save a database version (or label), and use it in our innovative database version control solution, dbMaestro TeamWorkTM. Saving a version will allow you to create a “snapshot” that can be referred to at any time, for any purpose and it uses mostly as a baseline when deploying changes. For example, it can be compared to other versions, referred to as a baseline, used to generate scripts, etc, you can roll back to the version whenever needed and even used as a backup for your development database.
Saving Database Content
The first step is to take a snapshot (Save Version) of your database schema. During this action, dbMaestro TeamWorkTM reads all the objects’ metadata and for save them in the database version control repository, it also saves the content of the configuration table in the repository, as they are part of the version.
Since this can take time, the best practice is to change the schema state to Freeze, which prevent from anyone to check-out the objects and modify them during the Save Version operation.
Freezing the schema requires all objects to be in check-in state, thus making sure that the snapshot will not include partial definition of the objects.
Once you freeze the schema, you can save the version by left-clicking on the appropriate database in the center of your console, and selecting “Save Version”.
A pop up window will appear, where you can enter the name, description, and other version details, and link the version to your CM tool. If you wish to archive table content, be sure to check the “Select data tables to save” option at the bottom of the window. Click “OK” when you’re done.
Another pop up screen will display. Check the boxes next to those tables whose content you wish to archive. Click “OK” once you’ve made your selections.
Comparing Versions
In order to compare database versions to one another, left-click the database in the center of your console, and select “View History”. In the pop-up window, highlight the versions you’d like to compare, then click the “Compare Versions” button on the right side of your screen.
The next pop-up screen will allow you to compare schemas and their associated data, indicating where objects and sub objects have been previously modified.
Reviewing Specific Changes
To drill down to more detail about individual changes, click on the button with the three dots next to the object in question. A pop-up window will display the specific changes made in both the baseline and compared versions of the database.
If all changes are correct, simply close all pop-up boxes, and return to the “History” window. Click on “Generate Script” on the right side of the screen to create your schema script.
Getting started with dbMaestro TeamWork™, our robust and unique database version control, is fast and easy. In this post, we will guide you some of the basic procedures, and demonstrate how to use a few of the core features.
Creating a New Project
First you should create a project in the project tree and sub project for the development, QA and other environments you may have.
To create a new project, left-click TeamWork Projects at the top left corner of your screen, and select “Add New Project”. When the pop up box appears, enter your project’s name, and click “OK”.
Assigning Schemas
Once a project has been created, you’ll need to add your database schemas. Choose the environment within the project from the tree on the left side of your screen, and select “Assign Schema to Project”. When the pop up window appears, add the schema connection details, click “Test”, and then click “Next”. Note that you will be required to enter your SYS credentials for the first schema you add. When the Summary box appears, click “Finish”.
At this point, dbMaestro TeamWork™ will analyze the schema, but will not yet be managing it. This means that any changes or modifications can still be made by anyone and are not documented. At this time, dbMaestro TeamWork™ will also identify the objects in the schema (it may take a few minutes until you see the objects in the GUI). In order for dbMaestro TeamWork™ to manage the schema, you’ll need to add the objects to source control.
Adding Objects to Source Control
To add individual objects to source control, highlight the appropriate database in the tree on the left side of your screen. All objects associated with that database will then be displayed in the middle of your console. Any of these objects can be added to source control by simply left-clicking it, then selecting “Add Object to Source Control”. Include any important notes in the “Comments” window of the pop-up box that appears and then select “OK”.
To add all objects to source control simultaneously, left-click on the database, then select “Add All Objects to Source Control”. When the pop-up box appears, enter any notes in the Comments window and then click “OK”.
Managing Schemas and Their Content
Changes to database objects must be made from your Oracle development environment. dbMaestro TeamWork™ change policy is embedded within Oracle engine and will prevent any unauthorized or unapproved modifications from being made.
For example, a table cannot be altered if it is in “Check-In” status. Your console will display a red lock icon next to any objects that are unable to be modified. Left-click the object you want to change, and select “Check Out Items”. When the pop-up window appears, highlight the object and click “OK”.
If you try to make the change again, you will see that now it will be completed successfully.
Enforcing Change Management on Lookup Data
To enable change management rules on lookup data, left click the relevant table, and select “Enable Table Content Management”. When the Confirmation box appears, click “OK”. Another window will then display, where you can select the appropriate objects to have their content under change management. When you are finished, click “OK”.
Note that in order to invoke Table Content Management, the table must have a primary key or unique index(es).
Once you’ve implemented your change management guidelines, go back to the database version control software, dbMaestro TeamWork™, console, left-click on the table the rules were applied to, and select “Check-Out Data”. When the pop up window appears, click “OK”.
Next, go to your Oracle development environment, and choose the appropriate object from the tree on the left. From here, you can define data rules, set constraints and dependencies, etc.
For example, selecting a specific data element, such as Postal Code within the Location table, then clicking on the red X at the top of the screen, will lock it so it cannot be altered.
After performing a commit in the database you can Check-In your changes in dbMaestro TeamWork™, console, left-click on the table the rules were applied to, and select “Check-In Data”. When the pop up window appears, enter a comment describes the change and click “OK”.
The TeamWork security mechanism enables changes to Oracle databases objects to be controlled at the Windows account and group levels. TeamWork enables you to define your organization’s database change policy in order to prevent undocumented database changes and to control who can do what, to control when they can do it, and to see why they did it.
When people talk about database change control, they usually mean having an accurate audit trail of database changes. However, another factor that is often even more important is the ability to prevent anyone from making unauthorized changes. TeamWork provides both change control and prevents unauthorized changes by the DBA and IT teams.
We have found that in many of the organizations that have implemented TeamWork, developers are allowed to change database objects including packages, procedures, functions, and the content of lookup tables, but DBAs are permitted to change all objects including table structures. Likewise, QA users are only permitted to make changes in the QA environment and not in the development environment.
But, as a practical matter, all developers and all DBAs usually work with a single Oracle user account – the owner of the database objects. As a result, without TeamWork, every developer, every QA user and every DBA actually can change any object in the database at any time. TeamWork provides the ability to prevent unauthorized changes to the database structure and the data it contains, including unauthorized changes by users who do have authorization to access the database.
It is also not rare to find organizations that have the same password for the Oracle user account in all database environments: Development, Integration, QA, Pre-production and sometimes even in the Production environment. When using TeamWork, the administrator can give developers access to change packages, procedures, and functions in the Development and QA environments while restricting their access to the Production environment by only giving them access to review history.
Of course, most of our customers implement TeamWork in their Development environment before implementing it in any other environment. But we recently had one customer that had such a serious database security problem in their Production environment that they installed TeamWork in their Production environment before beginning to use it in other environments.
TeamWork provides advanced permission management capabilities that give you full control over who makes changes to your databases. This enables you to proactively prevent unauthorized modifications to database schemas and their related objects. TeamWork enables you to implement very granular access settings, giving users the right to modify only certain portions of each schema, based on their role and their responsibilities.
TeamWork not only controls the permission to make changes, it produces an audit trail of changes to the database, correlating each change (What) with the person who made it (Who), the date and time of the change (When), and the business reason for the change (Why).
For more information on these topics, see these useful links:
Loading...