Database Change Management: DevOps’ Missing “Last Mile” in Release Automation

By Robert Reeves, Datical CTO & Co-Founder

Welcome to our new blog…Primary Keys.  As the name suggests, the plan is to discuss database issues – and specifically issues related to database change management, news, thoughts, and trends.   We’ll also look at related issues such as integration, architecture, agile, dependency management, process and, most importantly, the impact on the application release lifecycle.  Basically, if it is data or information related, it’s fair game for discussion here.

For those of you who I have not had the pleasure to meet, I am CTO and Co-Founder of Datical.  You will find my official bio here.  But, I’m basically a recovering Software Configuration Manager who just happens to be an entrepreneur and mentor to others who are involved in new technology ventures.

Most people who launch a new blog, labor over selecting the topic for their first post.  For me, it was easy – DevOps.  Truth is, many very sharp, capable people are working to figure out how to best implement DevOps in a practical sense within an enterprise setting.   It’s not for the faint of heart.  So, I decided to launch Primary Keys by explaining the title of this post:  Database Change Management: DevOps’ Missing ‘Last Mile’ in Release Automation.

I’ve thought a long time that no single aspect of release management is as difficult, time-consuming and error-prone as updating your database to support a new application.

SQL scripts have become the most common way to update database schema. They are the standard by which databases are evolved over time. Unfortunately, writing SQL scripts is only slightly less difficult than reading them. They are binary in nature; they either work or they don’t – providing you with little insight into what the cause of failure is. Finally, it is nearly impossible to identify which database instance is on which version number. This leads release managers, SCM’s and others to ask, “Which scripts do I run on which database?”

Frankly, DevOps will never be able to deliver on the promise to bridge the gap between development and operations until the problems with database schema updates are resolved.

The missing ‘last mile’ in release automation is database change management, because you can’t have an effective DevOps strategy if your database applications are not portable.  It’s hard to collaborate when you do not have the visibility to understand what’s going on with the database.  You can’t lower cost or improve service when every time you release an application, you have to manually intervene or scramble to deploy. And you certainly can’t get control when someone has hacked together an out of process schema change that no one knows about.  Without environmental intelligence, you can’t know how that change will impact your application in production or any other environment – until it’s too late.  It’s an expensive, risky problem that’s not being addressed by DBA tools.

So, the ‘last mile’ in my view is the database.  Specifically, Database Schema Change as part of the much broader and business critical application release lifecycle.

It’s the missing link in DevOps.  It’s the missing link in Cloud adoption and even Big Data (more on that later)…but for now, before you embark on your DevOps strategy, ask yourself, how am I going to manage schema change, track it, view it, automate it and predict its’ impact in the release process to enable DevOps?  Ask yourself, how am I going to leverage my existing tools and processes as part of an atomic application release process?  If you’re looking to your DBA tools to do the job, you probably want to think again.

Read more about handling database change management in a DevOps transformation by downloading our white paper, The DevOps Database.