|
Software Configuration Management (SCM) systems have been available for over 20 years and have provided significant benefits to application development teams as well as the companies that supported and sponsored their implementation. The most important benefits include:
- The ability to deliver revisions and updates faster
- Higher productivity of the development teams
- Less time wasted fixing old code
- Confidence that each release addresses all of the requested changes
- Improved customer satisfaction.
And with the exponential increase in complexity due to the web and e-commerce applications, developers are now expected to do more with less, meet tighter deadlines and provide more frequent updates due to business needs while maintaining code quality and compliance (which are all reasons why SCM was adopted in the first place). And to add to this increased complexity, database development processes are every bit as important to successful application deployments today, but they have been neglected by traditional SCM systems – that is until now.
Introducing Database Change Management from dbMaestro
dbMaestro’s TeamWork is a Database Change Management solution that now brings all of the benefits of application SCM systems to databases.
TeamWork allows database development to become an integral part of a disciplined SCM process instead of a manual or, at best, a semi-automated process. The benefits of SCM are significantly enhanced for organizations that treat both database development and source code development equal from an SCM perspective.
The Challenges of Database Development without TeamWork
Without TeamWork, the major challenge organizations face is the typical two-step process of checking-in and checking-out database object DDL. This often results in the wrong DDL being checked-in or the wrong DDL being applied to the database. There is a manual work-around for this, but risks always exist with a manual process.
For example, there is no validation that the right DDL is being checked-in to SCM or applied to the database. Also, the database object itself is never locked and can be changed at any time without a corresponding change in the DDL of the object that is stored in the repository. This can lead to discrepancies and loss of synchronization between the object in the database and the DDL in the repository. This change is also not logged or audited in any standard fashion, so repeatability, accountability and auditing are also hampered.
|