Thursday, June 16th, 2011
Developers need an environment that applies proven software change management (SCM) methodologies to the database world and seamlessly synchronizes database development activities with SCM processes. The best way to accomplish these two goals is to deploy a next-generation database change management (DCM) solution and link it closely with an SCM system.
Seamless unification of DCM processes with an SCM solution can enable development organizations to ensure that changes are not made in a vacuum. By facilitating improved communication and coordination among software and database developers, this type of integration helps avoid conflicts and provides end-to-end products development life cycle.
Integrating software change management and database change management activities makes database development a truly integral part of the SCM process. Because both database development and source code development are treated equally from a change management perspective, manual and semi-automated processes are eliminated while efficiency and accountability are increased.
dbMaestro TeamWork facilitates integration with these widely used SCM products:
- Microsoft’s TFS (Team Foundation Server)
- IBM’s RTC (Rational Team Concert)
- IBM’s RCQ (Rational ClearQuest)
Microsoft’s TFS (Team Foundation Server)
Integration with TFS enables you to perform the following actions:
- Assign a check-in to work items (changesets)
- Update TFS history with information from TeamWork
- Correlate a “Saved Version” to a TFS Label by matching a native code “snapshot” with the corresponding database code
- Review history by changesets
- Deploy changes by changesets
- Deploy changes by TFS Label
IBM’s RTC (Rational Team Concert)
Integration with RTC enables you to perform the following actions:
- Assign a check-in to work items (changesets)
- Review history by changesets
- Deploy changes by changesets
For more information about TeamWork integration with IBM’s RTC, follow these links:
IBM’s CQ (ClearQuest)
Integration with CQ also enables you to perform the following actions:
- Assign a check-in to work items (changesets)
- Review history by changesets
- Deploy changes by changesets
For more information about TeamWork integration with IBM’s CQ, follow this link:
Summary of Benefits
Integrating TeamWork with RTC, CQ or TFS provides numerous benefits. For example, companies can better align development projects with business needs and ensure that the end result meets any and all strategic requirements. This integration also eliminates the information “silos” that make it difficult to comprehensively track change histories – giving all stakeholders complete visibility into all the modifications made to both the software code and the database schemas and objects. Perhaps most importantly, SCM-DCM integration enables organizations to implement and enforce comprehensive change policies that effectively meet both internal and external compliance guidelines.
Linking software development projects with database development activities is fast and simple with dbMaestro TeamWork. The TeamWork Management Studio Console provides a simple and intuitive way to configure TeamWork to work directly with RTC, CQ, TFS, and other software change management environments. This allows developers to link any database schema to any project within the software change management system.
Posted in General | No Comments »
Tuesday, May 17th, 2011
dbMaestro TeamWork™ is a state-of-the-art Database Change Management solution that brings the benefits of Source Change Management (SCM) methodologies to database development.
Because the implementation of TeamWork involves changes in methodology and organizational behavior, a quick and successful implementation of the solution is very important. Failure to make the required modifications in work methods will reduce or delay the benefits that TeamWork can provide and may have a negative impact on user satisfaction.
In particular, employees who had become accustomed to performing the manual activities that are automated by TeamWork may feel threatened by the loss or reduction of these activities and try to prevent the successful implementation of the new methods. It is important to demonstrate that the time saved by automating these tasks will enable them to spend more time on other tasks that are more interesting and less repetitive.
Topics covered in this post
This post describes the best practices that have helped our clients make a successful transition to the type of work environment that maximizes the benefits that result when using TeamWork to manage database changes.
This post will talk about the preparation the organization needs to do before using TeamWork. It will not cover the mechanics of the TeamWork installation procedure. For information about system pre-requisites and installation instructions, see http://www.dbmaestro.com/dbmaestro/594.aspx
The actions you need to perform to properly use TeamWork can be described under the following categories:
- Selecting the right team
- Selecting the implementation leader
- Compare & Synchronization operations
- Mapping database objects
- Defining Modules and assigning objects to them
- Adding objects to source control
Selecting the right team
It is important to select a development team that has adequate time to properly implement the new solution. A team that has a release date in the near future may not have time to invest in planning and implementing the transition to a new solution.
Selection of the team actually influences the schema to be managed in TeamWork. The team should have development and test environments.
Selecting the implementation leader
This person should have in-depth knowledge of the customer’s application and the database schema.
Compare & Synchronization operations
We have found that the initial synchronization of the development environment with the production environment can reduce the amount of work that is later required to prepare deployment scripts. The development environment often contains objects that were created but were not deleted even though they are no longer in use.
Mapping database objects
The implementation leader must determine which database objects need to be under version control and which tables are lookup tables whose data also needs to be under version control.
dbMaestro TeamWork for Oracle can manage the content of lookup tables.
Lookup tables changes are part of release deployment.
Defining Modules and assigning objects to them
In this stage, the implementation leader creates modules in TeamWork and assigns the database objects that need to be under version control to those modules. This enables the development team to easily locate a working object within TeamWork. See our previous post on viewing the database schema from a module point of view.
Adding objects to source control
This action enables the TeamWork change policy to be enforced on the database objects that need to be protected at the database level. If anyone attempts to update a protected database object (by using a development environment such as Visual Studio, for example) before checking it out, a message is displayed indicating that the object is protected and must first be checked out.
Conclusion
Following these simple steps makes dbMaestro TeamWork of Oracle implementation quickly and smoothly.
Posted in General | No Comments »
Thursday, April 28th, 2011
In our previous How TeamWork Can Prevent Human Error in Production we discussed on the new feature of dbMaestro TeamWork for Oracle™ – Access Roles.
This new feature enables organization to add another layer of security on top Oracle. Usually when developers, DBA connect to oracle database if it the development, test or even production environments, they connect with the owner of the objects. During this connection any object can be changed since the owner has full permissions on its objects.
The organization needs another layer of security and this can be done using TeamWork for Oracle Access Roles. With this the organization can give specific permission to Active Directory account or group.
We recommend using Active Directory groups, assign them the right privileges in TeamWork and add the right members to this group.
Here is an example from real customer implementation:
This customer manages three environments: development, test and pre-production. They created the following Active Directory groups:
- DBA – Will be able check-out/check-in any object
- Developers – Can check-out/check-in only PL/SQL code (packages, functions, procedures)
- Read-Only – Can view object history but not change
- Release Managers – Can save version, freeze schema, remove and add objects from source control
People were assigned in Active Directory to the relevant group and each group was assigned with the right privileges based on the environment.
For example: Developers can check-out/check-in only PL/SQL code (packages, functions, procedures) in development and test environment, but in production they have Read-Only permissions.
You are welcome to contact us to hear how you can add another layer of security in your organization, just send us an email to sales@dbmaestro.com.
Posted in General | No Comments »
Tuesday, April 26th, 2011
One of our clients recently implemented dbMaestro TeamWork for Oracle in a rather unusual way. Most clients start their TeamWork implementation in the development environment when developers begin documenting changes using Database Change Management methodologies. But this client started its TeamWork implementation in its production environment to solve a critical database access problem.
The access problem existed because the same Oracle password was being used in every environment. It is not unusual that the password for the Oracle user is the same in the development, Integration, QA, and pre-production environments and sometimes even in the production environment. As a result, without Teamwork, changes to database objects could be made by any developer or DBA at any time without leaving an audit trail that indicated who did what when.
With TeamWork for Oracle the administrator can give developers access to change packages, procedures, and functions only in the development and QA environments while allowing them to review history in the production environment. This client assigned a role (developer, QA tester, release manager, DBA or read-only) to every person who could access the database for any purpose. Only people who were authorized to check-out objects in the production database could do so via TeamWork for Oracle. Everyone else could no longer do this.
Because the TeamWork security mechanism is integrated with the corporate active directory, this client achieved immediate control over access to the database in its production environment. For more information about database security, see Database Security.
Because TeamWork for Oracle’s change policy enforcement is integrated with the database engine, changed DDL files could not be executed in Oracle until they had been checked in via the TeamWork application. Only people who are authorized to check-in database objects can do so via TeamWork, so no one else could change the production database objects. In addition, only files that implemented changes associated with the work-plan for a release could be checked in to the version for that release.
When Teamwork for Oracle is implemented in the development environment, another source of human error is eliminated: manually produced deployment scripts. It is important to have a single deployment script for structure and meta-data. Meta-data is an essential part of the application logic. Deploying code changes without meta-data can cause an application to crash. Deploying structure changes to a meta-data table without the meta-data changes can produce incorrect values in the meta-data tables.
TeamWork for Oracle automatically generates a single deployment script that contains the structure and meta-data changes associated with an upgrade. This automatically generated script eliminates human errors in deployment scripts that are discovered only when the upgraded application crashes in the production environment.
In addition to gaining control over changes to the production database, this client now has an accurate up-to-date audit trail for every change made to its production database objects. This audit trail enables the client to determine what database changes were made after the people who made them have forgotten the details or even left the company. It also enables the client to satisfy the stringent accountability requirements of outside auditors. For more information about how TeamWork helps you comply with audit requirements, see Auditing.
Posted in General | 2 Comments »
Thursday, April 14th, 2011
Part 1 of this topic described the general characteristics of a next generation Database Change Management (DCM) system. A successful DCM system must not only maintain database version control, it must also facilitate the comparison and deployment of database schema and data. To see Part I, click here.
The .NET framework provides:
- A Common Language Runtime abstraction layer for operating system independence
- Base Class Libraries containing pre-built code for low-level programming tasks
- Development frameworks with customizable solutions for larger programming tasks
Developers working in a .NET framework typically use Microsoft Team Foundation Server (TFS) to handle Software Change Management (SCM) and work items for change requests. TFS provides extended functionality in the same working environment that the developers use to upgrade and debug their code. TFS is available as stand-alone software or as the server side backend platform for Visual Studio Team System (VSTS).
This is why a dedicated Microsoft Visual Studio add-in was created for dbMaestro TeamWork. The TeamWork Add-in for Microsoft Visual Studio integrates dbMaestro TeamWork functionality into the VSTS environment. This gives VSTS users the ability to track database modifications in tandem with application source code changes and enables developers working with VSTS to use dbMaestro TeamWork functionality from within the Microsoft VSTS environment.
A new panel that has been added to Visual Studio enables VSTS users to perform change management activities such as check-in, check-out, view history, and rollback database objects.
Every check-in performed in TeamWork is also documented in the TFS history.
Additionally, developers working in a .NET environment can leverage TeamWork’s Visual Studio add-in to create a single, centralized workspace for changing .NET code and updating the status of work items, as well as for altering database objects and linking them to those work items. This approach:
- Allows users to correlate VSTS and TeamWork projects, including linking database changes and updates with VSTS activities
- Enables users to save extended information about database activities in VSTS
- Automatically adds TeamWork check-in comments to the linked TFS work item’s history
- Provides a single location for impact analysis, task tracking, and managing and auditing changes to the application source code and the database
- Enables access to merged information about code and db changes from within VSTS
- Provides a single vocabulary to drill down into project tasks and impact analysis
(what was changed when feature X was developed or bug Y was fixed) from both
source code and database perspectives
- Creates a unified process for achieving code and database deployment based on Microsoft VSTS definitions of activities and work items
In a typical VSTS environment, each development team uses a separate database that is managed by TeamWork for Oracle and linked to the TFS tree. This enables each team to work on its own version without interfering with another team’s changes. A common database environment is created for integration.
Database changes in the common environment are managed by TeamWork for Oracle and used for deploying each team’s change scripts into a unified environment. However, if each team works on different objects and the risk of conflict is low, a single database environment may be sufficient.
Posted in General | No Comments »
Tuesday, April 12th, 2011
This topic will be divided into two parts. Part 1 describes the attributes of a comprehensive but easy-to-use database change management system. Part 2 will contain information about using dbMaestro TeamWork Add-in for MS Visual Studio Team System (VSTS) in a .NET framework.
For general information about dbMaestro TeamWork, click this link:
dbMaestro TeamWork | Database Change Management Software
For years, application development organizations have relied on software configuration management (SCM) solutions to ensure seamless updates and modifications to software code. Although SCM has provided comprehensive tracking of alterations made to application code, it has done little to help manage related changes made to the underlying application databases.
Traditional SCM systems work well with software code changes but are not designed to handle changes to databases. A major disconnect exists between software and database development activities, with software developers using automated tools while database developers struggle with manual processes and workarounds. As a result, changes made in the development environment are not linked, creating failures in the production environment just after upgrading to a new version.
Additional problems are caused by the fact that SCM solutions save scripts in their repository (the vault) and retrieve these scripts from the repository as opposed to saving definitions in and retrieving these definitions from the database. Therefore, the DBAs must follow a multi-step manual process that requires them to:
- Export the appropriate object DDL from the underlying database
- Check-out the object DDL from the repository
- Update the script
- Run the script in the database
- Check-in the object DDL to the repository
What DBAs and their teams really need to successfully manage change is proactive database change management that applies proven SCM principles to the database world and enforces those principles in the database engine.
DBAs and their teams need solutions that follow traditional SCM concepts that:
- Implement Database Change Management (DCM) solutions and methodologies
- Eliminate cumbersome, inefficient, and error-prone manual activities
- Improve collaboration and coordination between software development and database development teams, as well as among individual database developers
- Mitigate the risk of database change loss – a major cause of application failure
- Provide proactive detection of problems that can cause production failures before the changes are implemented
- Facilitate the comparison and successful database schema and data deployment
In order to accomplish this, the next generation of Database Version Control solutions needs to bring the complete array of software change management functionality to the database development environment. Unlike the current generation of database tools which are little more than “compare and sync” applications, the next generation of Database Change Management solutions must include much more comprehensive capabilities. In addition to compare and sync, they must deliver object locking, check-in/check-out, baseline setting and comparison, code merging, tagging and labeling, and change rollback capabilities.
Part 2 of this topic will provide information about using the dbMaestro TeamWork Add-in for
MS Visual Studio to provide TeamWork functionality in a .NET environment. Stay tuned for the 2nd installment.
Posted in General | 1 Comment »
Tuesday, April 5th, 2011
Each day, database administrators (DBAs) interact with a variety of different stakeholders throughout the business. Yet, according to an article published by Database Trends and Applications, “the DBA, often respected as a database guru, is just as frequently criticized as a curmudgeon with vast technical knowledge but limited people skills”.
But, truly savvy DBAs know exactly how to interface with a variety of different people in different roles. While reporting structures and responsibility hierarchies vary greatly from one company to the next, there are certain folks that all DBAs will encounter on a regular basis.
The CIO and Other IT Management
The CIO will be at the top of the chain of command for any DBA, although it likely won’t be a direct-report type of relationship. In most companies, the DBA will report to the head of Technical Support, or the head of Application Development, who sits directly under the CIO on the org chart. Some companies even have a Data Resource Management division within its IT department. In these scenarios, the DBA will report to the supervisor of this unit, with a dotted line to the heads of Technical Support and Application Development.
For the majority of senior-level IT management professionals, compliance is a key concern. So, as the DBA embarks on his day-to-day tasks and responsibilities, he needs to ensure adherence to regulatory guidelines through the creation and maintenance of a complete, accurate audit trail of all activities.
Software Programmers and Administrators
These professionals will be making modifications to the applications that access information in the databases that the DBA oversees. Collaboration, combined with full visibility into each others’ activities, are crucial in this relationship, to minimize conflicts, data loss, and other problems that can negatively impact database performance.
Database Developers and Analysts
In the majority if IT organizations, DBAs will oversee the activities of developers and analysts – whether directly or indirectly. It is critical, however, that DBAs have complete visibility into the activities of each of these developers and analysts – for example, they need to be able to track and monitor the modifications they make to schemas and other database objects. This is particularly important when multiple database development teams are working in tandem.
Business Management
Nobody influences the activities of a DBA more than end users, such as line of business managers. Since, ultimately, it is their needs and requirements that the database environment must satisfy, their demands will be the primary driver behind many of the projects a DBA oversees. To keep these relationships intact, DBAs must be able to report on the progress of their activities to business managers, to demonstrate responsiveness to end user needs.
While it can be a challenge to maintain strong relationships with all key stakeholders – and to keep everyone happy – a database version control solution, which can enable comprehensive end-to-end tracking and handling of the entire database change management lifecycle, can help.
To learn more about dbMaestro TeamWork™, our next-generation change management software, and how it can help DBAs collaborate effectively with various constituents throughout their organizations, visit our Web site.
Posted in General | No Comments »
Tuesday, April 5th, 2011
We are proud to release a new version of dbMaestro Teamwork™. Some of the exciting new features include:
- TeamWork SideBar will remember its setting (location and size) on exit.
- Adding new schema to TeamWork on a new database allows you to choose the tablespace for dbMaestro_TeamWork schema.
- Adding support for managing table content with more than 32 columns.
- Access role supports Active Directory groups.
Additional fixes in this new version include:
- Improvements of the deployment script and supporting values that contain the NUL value.
- Supporting saving password with special characters.
- Performance improvements across the product.
- Identifying the difference between unique and non unique index and create the correct DDL commands to reflect the change
Posted in General, Release Updates | No Comments »
Thursday, March 31st, 2011
Compliance audit – a veritable nightmare. No one loves an audit; no one wants to be in the hot seat. But compliance is a major issue, and it continues to be one of the topmost priorities for IT organizations. And there is no end in sight for the foreseeable future.
Hopefully, you will not face an audit. But if and when you do, you had better be able to account for your data, including what changes were made to the database, when and by whom they were made, and for what reason.
Given the fact that SCM solutions do not track, or provide audit trails for database changes, this can be a real problem. Just where will the needed details come from? And audit is not the time that you want to rely completely on memory to explain database changes.
The solution? dbMaestro TeamWork for Oracle™.
TeamWork enables IT organizations to meet their compliance requirements for their Oracle databases, including COBIT (Control Objectives for Information and related Technology) and Gramm-Leach-Bliley Act (GLBA) compliance requirements.
Does the auditor want to know what changes were made to the database? TeamWork’s database version control and auditing saves and tracks all database change versions.
Does the auditor want to know the reason for the change and/or who made the changes? TeamWork integrates with major software configuration management products, such as IBM Rational Team Concert® and Microsoft Team Foundation Server®. Through this integration, changes to an application’s database can be linked to a work item or change set, which identify the reason for the change and the person responsible.
TeamWork provides you access to a reliable audit trail for the managed database object definitions as well as the ability to manage content. In fact, using proven change management methodologies at the database level, TeamWork becomes an integral part of the development process.
It enforces compliance with change policy through all stages of the development process, from development through testing to production:
* Changes to database objects must be documented and approved
* The audit trail of object changes must be reviewed
* Database changes made in development must be deployed to testing and production
So before you face a compliance audit, implement dbMaestro TeamWork for Oracle™. And then relax. And breeze through the audit.
Posted in General | No Comments »
Tuesday, March 29th, 2011
Creating a product upgrade is like creating and assembling a giant puzzle. From beginning to end, there are so many pieces to the upgrade process. It begins with application and related database development, which must be properly performed, controlled, and tracked. And it ends with a script that ties all the pieces together to produce the final product upgrade. And a successful upgrade will ensure that the database and application configuration will correlate to your business requirements.
Along the way, at every step in the process, there are pitfalls. But thankfully, products and methodologies exist that enable you to bypass those pitfalls.
The standard, of course, is SCM, for managing application development. It ensures that code modules, which are worked on locally, are properly checked out and check in so that no one’s work is overwritten. And it provides audit trails and rollback capabilities.
But data analysis applications usually have a large portion of the application in the database, in packages, procedures, table structure and even in configuration tables. It therefore becomes necessary that the SCM methodology that is so routinely applied to software configuration also be applied to the database configuration (database schema structure and data content).
But SCM solutions do not manage databases. They do not require check out and check in of database objects. They do not provide audit trails and rollback capabilities for databases. And when it comes time for generating a script, they do not deal with databases.
There is a solution, however. dbMaestro TeamWork for Oracle™ is a best-in-class Database Configuration Management solution.
TeamWork enforces proven SCM methods and applies them to database configuration. It also integrates with other configuration management products, such as IBM Rational Team Concert® and Microsoft Team Foundation Server®, thereby becoming a part of the development process. This integration enables users to link changes made to an application’s database infrastructure to a work item and to the responsible person.
TeamWork:
- requires check out and check in of database objects
- provides database version control, and the ability to rollback to earlier versions
- provides comprehensive auditing
- provides managers with an accurate view of the database objects that were changed
- lets managers know to which change sets (or work items) changes were linked
Those last capabilities ensure that when it comes time to generate the database migration script, nothing is left to memory or chance. The Release Manager can generate the database migration script, knowing with full certainty that the script is correct, and that no database object has been forgotten or left behind.
With dbMaestro TeamWork for Oracle™, all the pieces of the puzzle seamlessly fit together, flawlessly providing you an upgrade version that correlates to your business requirements.
Posted in General | No Comments »
|
|
|
|
Loading...