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 »
|
|
|
|
Loading...