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 »
Wednesday, March 23rd, 2011
Time-to-market (TTM) is a major concern for company management and especially for project, product and sales managers. TTM is influenced by the content of a new release and size of the team working on the release. When a new release includes database changes, dbMaestro TeamWork for Oracle™ can greatly reduce TTM.
Sometimes the content of a new release must be cut because of business needs. For example, an important sale can be closed only if one of the features in the next release is made available immediately. Based on this requirement, management may decide to postpone all other release content and approve only this one feature for immediate release.
Reversing changes made to an application’s code is a tricky task. Luckily, Software Change Management products provide a good solution for native code (C#, C++, Java, etc.). However, these products do not handle code changes that occur in a database. As a result, team members and DBAs work days and nights to reverse changes that were made in database code.
TeamWork for Oracle™ is a next-generation database change management solution that amongst other things, solves the problem of reversing database changes. TeamWork for Oracle™ integrates completely in the application development process.
Database changes can be instantly associated with change-sets via TeamWork Management Studio. When Teamwork users Check-In a change, an “Assign to Change-set” area is displayed at the bottom of the screen. They then choose the appropriate task to link to from a drop-down menu. This allows only those changes that have been associated with specific change-sets to be implemented.
When generating a database migration script, TeamWork for Oracle™ allows the team leader or DBA to select only changes made to objects that belong to features whose changes have been approved for release (based on business requirements). Changes made to other database objects are ignored.
Read about the ability to upgrade schemas based on activity and about many other powerful and innovative Teamwork features on our Web site.
Posted in General | No Comments »
Friday, March 18th, 2011
When application development and testing are completed, and it is finally time to prepare the release, the biggest challenge might not be preparing the application’s release. It might just be preparing the database deployment.
Preparing the database deployment is time consuming work. You must prepare the database deployment script, which includes sections for schema deployment and data deployment. And this is no small task; rather, it is a tremendous challenge.
Database changes are by far different than application code changes. With application code, the Software Change Management tool forces check-in and check-out modules and tracks changes and versions. If the code changes were made correctly and the testing was precise and thorough, then with the help of the SCM, the process of putting together the release flows.
But database deployment is huge challenge because database changes are generally not managed, nor are they documented, and there is generally no simple way to determine all the objects that were changed.
So in the end, the DBA or Team Leader who works on this task has the unenviable task of trying to secure the list of changed objects. And once that list of changed objects is secured (assuming it is correct and comprehensive), the DBA / Team Leader must now generate a database deployment script for all the changed objects. And each object can have different change command, based on its status.
And as if that wasn’t enough, this task is made even more difficult by the fact that the sequence of the commands is critical, because there are constraints between the objects. And finally, to make this task almost impossible, the DBA / Team Leader must also prepare a data deployment script for the configuration tables.
Of course, it need not be this difficult. Clearly, what is needed is a database change management to complement the SCM. This is all the more important because databases often contain significant amounts of code for data –driven applications. This code can appear as pure code (for example, procedures, functions, packages, and triggers), or as initialization values (sometimes referred to as Lookup / Metadata / Configuration tables).
You would not think of doing application development without an SCM to help manage and secure the process. Shouldn’t a database change management solution be axiomatic? Yet, for some reason, recognition of the need for database change management seems to fall between the cracks.
Well, it need not be this way.
dbMaestro TeamWork for Oracle does it all, automatically. It ensures that no changed database objects are overlooked, eliminates the need to manually put together deployment scripts, and reduces the time spent on integration of the database schema database content during deployment. All of this, in addition to providing enforced Check-out and Check-In procedures, database version control and an audit trail during the development database change phase.
Isn’t it time for you to bring management of your database changes up to the same level as your management of application changes?
Posted in General | No Comments »
Tuesday, March 15th, 2011
Many times developers or DBAs make changes to lookup data tables, and after performing a commit in the database, they want to roll back the database to how it was before the change.
What they need is an “Undo the Change” capability. But without a saved definition of the lookup data prior to the change, the developer / DBA only has personal memory to rely on, trying to remember what was changed and how to undo it. This, of course, can increasingly become a mission impossible as the days since the changes turn to weeks and then to months.
If only you could roll back changes to your database as easily as you can roll back changes to your apps. In fact, you can – if you use dbMaestro TeamWork for Oracle.
Roll back of application code development changes is simple with existing Software Change Management products. First of all, developers work locally on their particular section of code, and perform check-in when the work is complete. Furthermore, with SCM tools, application change versions are saved, and if the need arises, development managers and project managers can roll back to an earlier version.
Database version control is a more complex issue. Databases are centralized, so database developers work directly on the database. A strong database change management system is needed – one that compels and enforces check-out and check-in of database schema and content. And such a system must provide an audit trail that provides for versioning and version control.
Enter dbMaestro TeamWork for Oracle.
TeamWork compels Check-out of database objects before work can be performed on them, and Check-in when the work is completed. It provides an audit trail of changes and responsible parties, and saves different versions with each check-in.
Thus, if the need arises for lookup data rollback, the user can undo changes and roll back to an earlier version with just a few mouse clicks.
So implement dbMaestro TeamWork for Oracle before you have to rack your memory to undo lookup data changes and find yourself wishing you had implemented TeamWork earlier.
Posted in General | No Comments »
|
|
|
|
Loading...