Grant Fritchey

23 November 2020

Challenges to Implementing Database DevOps: How Do You Get The Data Team On Board?

I think this is my single favorite question that came up at the recent panel discussion:

How do you get DB folks who just go in and make changes to understand they need DevOps, source control, change management, etc.?

There’s a lot to answer in this question, however, to keep this down to a blog post sized response and not write a book, I’m going to only focus on a few points. The key is getting started.

Starting With Database DevOps

Like any other proposed change to how we do things, you need to first understand if there are benefits. Will the database team derive any kind of positive effect for introducing DevOps? Or, is this only a thing that benefits the development team?

Let me begin by saying, yes, the database team can absolutely derive benefits from adopting DevOps. Let’s start right at the beginning, both in terms of how you implement DevOps, and in the benefits that DevOps delivers: Source Control. From the State of Database DevOps survey, we know that while 85% of application code is in source control, only 62% of database code has been placed there. Yet, those who are doing the most automation have implemented source control of their databases at 69%.

If you’re going to create a full blown automation process for your database development, the first thing you have to do is get your database code into a source control repository. Then, you have to develop the habit that all changes to your database are made through source control. A very simple phrase has to become your touchstone: If it’s not in source control, it doesn’t exist.

There are tools, such as Redgate Deploy, that will help you manage your databases and your source code. However, they only work if you use them. DBAs and database developers, report writers, everyone who can create database objects must get in the habit of creating them through source control. Otherwise, when you go to automate your processes, you’re going to find you miss, and/or destroy, objects that were supposed to get deployed. Because you can easily bypass source control to create objects directly in the database, you have to take on the task of developing discipline around this.

Now that’s a lot of work, so beyond just the ability to automate deployments (yeah, huge, but sometimes easily dismissed) what does putting the database code into source control get you?

Benefits of Source Control

Even if you never go on to automate your deployments (which would be sad), just getting your database code into source control has benefits. I’m going to outline just a few.

First, source control automatically contains an audit trail. Who made what change, when. This audit ability means you can see who modified the database. If some horrible query was introduced, you can find the right person to provide education to make it better. You’ll know precisely when the changes were made so you can correlate that with monitoring and deployments to understand better how the behavior changes in your databases. You’ll also have a history of all the changes made. This history provides us with another benefit.

Because you have a history of the changes made to your objects, you’ve got a great little undo button now for your databases that we never had before. Without source control, if you incorrectly modify a view, or drop a stored procedure, the only way you could get back the original view or the stored procedure is to go to a backup. So, you’re actively developing something, you mess up, and now you have to wait for a 500gb restore to occur. Yeah, maybe a copy of the view is in QA or production. Although, maybe that copy doesn’t include all the changes you’ve made over the last week. The ability to get these objects back is a huge benefit.

This leads us to another benefit. Having all the objects in source control acts as another backup. Yes, it’s only a backup of the code (with the exception of some lookup or reference data, I don’t recommend putting data into source control), but it is a backup of all the code. As we should know by now, more backups means the ability to restore is enhanced. You can rebuild databases in whole, or in part, from a historical standpoint, or from the latest release, all because you have a complete backup of the code.

You’re also going to find that source control makes managing code across a team a little easier because you can each work on parts of the code, but keep a history of your changes. You’ll also find that stuff like hotfixes can be enhanced by the ability to create a branch, a copy, of the code and only work on the changes you need to get the hotfix out the door, avoiding having to differentiate development work from what’s in production from what changes you’re introducing for this hot fix.

All this taken together provides a lot of benefit for a database team, even before we start talking about automating deployments.

Conclusion

There really is a lot of work involved in setting up automated database deployments. However, you have to have a starting point. Source control provides both a necessary starting point and a whole bunch of benefits, at the same time. Before you do anything else on your DevOps journey, get your databases into source control and make it a fundamental part of everything you do. Automation from there will be much easier. All these benefits taken as a whole, should make it easier to convince your database team to move forward with DevOps.

For additional reading on this topic, I’d like to suggest:
Three Steps to Get Started with Database DevOps
Ten Tips to Building a Collaborative DevOps Culture