T-SQL Tuesday is a monthly blog gathering for the SQL Server/Data Professional community  It is the brainchild of Adam Machanic (B|T) and is not limited to just things around the SQL Server database engine. Each month a blogger hosts the event and anybody who wants to contribute can write a post about that month’s topic. You can find a list of all topics at http://tsqltuesday.com/.  

This month’s T-SQL Tuesday topic is about DevOps.  It is being hosted by Grant Fritchey (B|T).

Grant asks some specific questions in this month’s posting:

1. How do we approach DevOps as developers, DBAs, report writers, analysts and database developers?
2. How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together?

We’ll discuss each one, but first a recap.

What exactly is DevOps?  Wikipedia tells us that devops is:  “DevOps (a clipped compound of “software DEVelopment” and “information technology OPerationS“) is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.”

Great.  Now we know what it is.  It is intended to be a set of practices that stress on the collaboration and communication of basically everybody (and I mean everybody) that might be involved in application development and delivery.   Ironically, this set of practices has morphed into an actual job title over the years.  My employer just recently hired a “DevOps Engineer”.

So, let’s go back to Grant’s questions.

How do we approach DevOps as developers, DBAs, report writers, analysts and database developers?

Honestly, I think it’s time for us data professionals to get out of the data center and get on board with the DevOps movement.  Let us take off the cloak of invisibility and get our hands dirty.  If we look at the overall “DevOps” role, we should want to have DevOps in our world.  While it may be a hard journey, in the long run it will make our jobs easier.  How would you like to have push button deployments or less manual code reviews?  I know that I do.

How do you do this?  Easy.  Talk.  Communicate.  Collaborate.  Break it down now.  Go talk to your respective teams (app dev, infrastructure, DBA’s, management, etc) and get them talking.  Everybody will have their own opinion and that is okay.  The important part is to get everybody talking.

If you need a starting point, ask this simple question: “What if we could implement a process to deliver application changes to the wild, that could potentially have little to no impact to our customers?”.  Think about that.  Do you work in an environment where deployments cause outages for your customers? I bet for the majority of us, that is true.

If your customers have a better end user experience, meaning little to no down time, isn’t that the name of the game?

DevOps helps to answer that question.

How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together?

In my opinion, the answer is simple.  Trust.  As data professionals, we often question the process because once you involve data (the data is the business) then we get very distrustful of changes.  This is probably rightfully so.  How many times as a deployment gone sideways for you?  Ever have to roll back a deployment because it barfed?  I know that I have been there and usually it’s not that much fun.  Hopefully every DBA has a recovery strategy in place to handle such events.

In order to reach a true “DevOps” method to deliver application changes into the wild, we have to get our hands off of it. And I mean OFF.  This means tools must be in place in order to facilitate this. This also means that we have to TRUST the tools to do their job and do it well.   Tools such as Octopus Deploy, Team City, Jenkins, TFS, Red Gate, etc.  All of these third-party vendors pour money, time and effort into making them as rock solid as possible.

Trusting the tools is difficult for most database administrators.  We want to see the guts in deployment, making sure dangerous things do not happen to our precious databases and their contents.

Experience

I was a part of a database continuous delivery project at Farm Credit Services of America in conjunction with Alex Yates (B|T) and Bob Walker (B|T), who have both blogged about the experience.  I have also been pushing a similar project at Farm Credit Mid-America.

I’ll admit when the project started up at FCSA, I was that distrusting, skeptical DBA that thought this would never work.   Yes, it was hard.  It was cumbersome and clunky in the beginning.  Then it got easier and the pieces fell into place.  Iterations to delivery changes to the wild got easier.  Quickly, I began to trust the process and how it was going to work.

I highly recommend Bob’s series of blog posts about the process.  You can find them here. Alex also has several excellent posts around the process here.

Summary

In short, I’m a large support of the DevOps movement especially concerning database lifecycle management (DLM) and continuous delivery.  While difficult, there are organizations out there that can help you get there.  I assure you that the end results will be worth every penny.

Time to shed the cloaks of invisibility.  Start talking.

© 2017, John Morehouse. All rights reserved.