Version Control Meets Data Control

October 14th, 2013

 


 

 

Webinar: DB Maestro and Delphix

 

 

Three part post

Source Control

charleskenny

Imagine being tasked with writing a twenty-page paper. In pen. How would you ensure a complete paper without any mistakes? Sure, you can rewrite a page if something goes wrong, but that’s a lot of extra work that could potentially set you back hours. In fact, even though each completed page is a saved document and therefore safe, if you are ever asked to rewrite even a single word you will have to rewrite an entire page.

So what could you do to minimize the risk and ensure you don’t waste much time? One option is to make a copy of each page after every sentence. In the event of an issue on any sentence, you can revert to a copy and begin from there and save yourself at least some work. When a page is confirmed as being good you can commit it, and when all the pages are confirmed you can merge them into a final document.

Obviously there are better solutions than this (like not using pen in the first place). But in application code, we face similar issues. Thousands of lines of code that have to be written, checked, crosschecked, put through QA cycles, subjected to UAT, and finally merged together into a cohesive package for production that may or may not be what the customer is looking for. And in that world we have a similar solution called source control.

Source control is widely used for development projects in languages like Java, .NET, C++, Ruby, PHP, JavaScript, and more. In some organizations, teams are actually built around the source control solution the company uses. Without proper source control it is next to impossible to keep track of all the pieces of code, releases, bug fixes, and requirements of the business. It not only holds the project together, it helps orchestrate the flow of the development cycle.

Sadly, in the database world we have no widespread source control. Some organizations do track changes in development, QA, and production databases as they are made. But a complete solution incorporating data versioning, change repositories, development merging, and rollback capabilities is out of reach for most organizations. Surprisingly this is even true for code such as PL/SQL, T-SQL, etc. in many cases.

Databases Pose Unique Source Control Problems

Screen Shot 2013-09-05 at 9.52.45 PM

Database development poses unique problems for source control compared to traditional code development. This is because the database is not a flat code object; instead, it is constructed from various parts:

  • Schema Structure
  • Content
  • Database Code (PL/SQL, T-SQL, etc.)

The simple truth is that databases can’t be given to every developer like source code.

Until now.

More to come tomorrow and join us for a webinar with DB Maestro Thu, Oct 24, 2013 12:00 PM – 1:00 PM EDT.

Screen Shot 2013-10-14 at 1.36.47 PM 

 above photo by Charles Kenny

 

writing


Uncategorized

  1. Trackbacks

  2. No trackbacks yet.
  1. Comments

  2. October 29th, 2013 at 14:52 | #1

    I’ve blogged about this kind of thing in the past i.e. how you manage changes to a database’s structure over time, which is radically different to managing changes to source code. Source code “evolves” with a next generation completely replacing the previous one. Databases must “metamorphose” and change in place – the same database with the same data in it but with some structural changes.

    My 2 main posts are on the challenge itself (http://databaseperformance.blogspot.co.uk/2009/10/challenge-of-agile-database-design.html) i.e. evolution versus metamorphosis, and how to deal with it (http://databaseperformance.blogspot.co.uk/2009/10/solving-database-design-in-development.html). The original context for this was the adoption of Agile Development where I was working, but the principles and solution are not unique to Agile at all.

    John


− two = 3