I’ve been surfing around the interweb trying to find educated opinions on a database version control question I’ve been batting around in my head. Here’s the situation: you’re the Release Manager. You’ve got a project in one of your Development environments that’s coming to a close for a new version. Most of the updates have been checked-in and you are getting ready to promote this version from Development to the QA environment for testing. Your database is under Oracle version control using dbMaestro TeamWork.

Now, the question: how can we make sure all our updates are in the version control, and how do we stabilize the SCM? A couple of programmers are still making updates and the DBA is already making changes to support the next version in development. This is a situation we’ve been asked about by our customers and prospects on more than one occasion. This reminds me of a saying a good friend of mine uses on occasion… “It’s like herding cats“.

We at dbMaestro have been contemplating a new product feature to help solve this. The feature (provisionally called “Freeze”) would allow you to “Freeze” a schema such that no check-outs will be allowed; check-ins will be allowed to make sure we can catch any straggling updates. One of my colleagues is actually also advocating a “Force check-in all” option which will immediately commit any open (checked-out) changes.

Once everything is checked-in, we can save a schema-version that has all the changes we want as a baseline version, at which point we can use dbMaestro Deployment Manager to deploy this version in it’s entirety to QA for testing. We can also “Unfreeze” the development environment to allow everyone to continue their work on the next release or bugfix.

We’d be real happy to get some feedback on this issue, as we’d like to integrate this feature into one of our next releases. Feel free to leave us a comment – we’d really appreciate it.

Recently, ZDNet published an article on the reasons for application failure. One of the main reasons mentioned in the article is Data Corruption. The article notes that developers have unfettered and uncoordinated access to database values which can cause a ripple effect on incorrect reports, bills and inventory problems. This seems to be a common problem for development teams and DBAs.

dbMaestro TeamWork can help address these issues by applying standard SCM methodology to the structure and data-content of the database. TeamWork can apply locks to schema and values in the database in order to ensure that any modification is performed under the project’s guidelines for change. TeamWork ensures that a developer must first check-out the data in a table before modifying it. This provides a number of advantages:

1. Ensure that only one developer can make changes to an object at any given time;
2. Data or schema cannot be changed without adhering to change-control procedures;
3. A complete audit-trail is maintained (you can track what change was made by which developer, and when);
4. All changes are kept in a versioned time-line which allows a rollback to any previous (and known good) version of data or schema.

TeamWork can assist development teams and DBAs by preventing the introduction of costly data-corruption into the database development process and facilitating recovery from such situations.

Three-way analysis & merge are very different to traditional compare and sync tools, both from a technical point of view, and from a practical point of view.

Using a traditional comparison tool – we compare A to B, performing a two-way-compare (development to testing for instance).  Comparing A to B will result in very shallow results.  For example, “A is different than B”, or “object X is in A and not in B.”   There is no way of knowing if either A or B has changed, or if X was added in A or deleted from B.  As a result, you have to start looking for additional information, go ask the developers, the DBAs, etc.

This is incomplete information, and of course, after you investigate and understand the reason for change, and decide what is the safest thing to do – relying on compare and sync tools will only enable you to either deploy A or deploy B, nothing in-between!

Using dbMaestro TeamWork will get you a deep examination of changes, leveraged by a three-way-analysis:

All changes are analyzed and examined with relevance to previous versions or a reference environment (this is an A vs. B vs. C analysis, hence a three-way-compare).  When deploying changes from development to integration, TeamWork will also analyze the previous revisions of the relevant database objects, and return with very informative and final results.  If A is different than B, you will know if A changed or B changed, because you know what their previous state was.  The result is a perfect understanding of changes that enables TeamWork to recommend the appropriate action.

If an object has changed in development – TeamWork will suggest you deploy it to integration.  However, if another team has updated the integration environment, and it is different to development, TeamWork knows it will cause damage to overwrite integration, and will recommend you ignore the change, or take it back to development.  All of this comes with complete documentation of each change, and the reasons it was introduced.

But the good stuff doesn’t end there – TeamWork will also deal with conflicts: if a change was introduced to both A and B (typical when more than one team develops for the same database), an automatic conflict resolving engine will come into play.  Based on all the analyzed information, TeamWork will suggest combined code, taking all changes into consideration and merging changes from both development and integration into a single piece of code.

The TeamWork three-way-analysis and automatic conflict code resolver is a unique offering for the database world.

Our co-founder and CTO, Yaniv Yehuda was recently published in the latest CM Journal from CM Crossroads.  Yaniv wrote extensively about the challenges facing organizations today when dealing with the migration of databases as a critical part of their overall software release management process.  While most organizations today have developed or implemented solutions for moving code, the database poses additional challenges and existing software configuration management tools and capabilities have not been extended to this layer.

In the article Yaniv proposes a number of key changes that can be made to significantly improve control and work processes related to database change management and migration.  The proposed changes are centered around the creation of a “staging” environment as the preferred approach.  While there are additional costs associated with this approach, the savings, coupled with an automated approach to the actual migration between environments are significant.  This approach can also significantly improve the number of bugs found in earlier stages, while drastically reducing the rate of malfunctions that may appear during the migration to production.

dbMaestro TeamWork is the only solution available today that allows for the complete monitoring and synchronization of database development teams and DBA’s as part of the overall development life-cycle.  dbMaestro also provides a central versioning repository that enables users to analyze and compare all database objects, highlighting changes between different versions and ultimately automating the deployment of database changes across environments. 

You can read the full CM Crossroads article here.  For more information you can also visit the dbMaestro TeamWork pages at dbMaestro.com.  We look forward to continuing and expanding the dialog relative to database change management.

A couple of months ago I watched a webinar put on by Agile Journal and Serena. This webinar demonstrated Serena’s Dimensions CM and it’s ability to support parallel streams development and the Agile process.

This got me thinking… dbMaestro TeamWork provides a set of tools that support a similar process for Database Development.

It occured to me that SCM and a streams development process for database objects can be the next logical step. A DBA/development team working on objects (tables, triggers, stored procedures, etc, etc) in the database would definitely benefit from a similar, streams-based approach (maybe even more so than the developers working on the source code).

In particular, the TeamWork Deployment Manager would allow the developers to manage the streams process in a very controlled and repeatable manner. Deployment Manager is very good at both the deployment to the streams and (more importantly) the merge process where several streams need to be merged back into the main trunk. Because Deployment Manager does the merge on an object-by-object basis, this would greatly simplify the merge process.