Hey developer! DevOps doesn’t mean what you think it does

Put down your kombucha. Close your Mac. Listen up.

Yes, I’ve read the same books and posts about DevOps as you have. I went to all the same conferences as you did. I heard the apocryphal tale at Agile 2015 about how Facebook developers can push to production anytime they want. That sure sounds great! Trust me, I’d love to set my fantasy football lineup instead of explaining why it’s a bad idea to add columns with default values to tables with over a million rows.

Yes, I’m sure you can do it with (insert your favorite NoSQL database here). I notice you have that sticker on your Mac.

Yes, I’m sold on DevOps; the entire database team is as well. Frankly, we’ve been waiting for the time when the tooling would allow us the same flexibility we see our system administrators and release managers enjoying.

And yes, we have noticed them using more Macs, too. They’re nice.

But, as the database administrator responsible for the most valuable asset at a Fortune 500 company, I’m still not going to allow you to push directly to production. That’s not what DevOps means.

Years ago, when we first felt the initial rumblings of the DevOps movement, it was just an idea, just an ideal. There wasn’t any evidence to prove the approach would work or that it would catch on in the long-term.

There was nothing but belief and supposition underpinning the push for enhanced communication, collaboration and technology decisions between dev teams and their ops counterparts. Still, DevOps’ credence and community of disciples expanded via both DevOps Days events and Twitter conversations, and before we knew it, it was a very real thing. It’s about time. We’re sold.

These days, DevOps as a concept is almost a foregone conclusion for IT organizations. Everything is still sometimes easier said than done, but DevOps has seen enough success that it’s being applied from the first phases of application prototyping all the way through to application deployments. As with all successful initiatives, the marketing machine inevitably commandeers the term and spoils it. Now you developers have fallen for it.

Until we get a plan in place to take those SQL scripts from dev to test to production, I’m not letting you anywhere near the production database, even if you invoke DevOps.

I know a DBA that worked at that company across the street. She let a developer push a script to production. Once. Now she’s a dog groomer. Actually, she seems happier and I’m a little jealous.

So, for all of our careers’ and families’ sake, I think it’s high time we took DevOps seriously for the database. Let’s talk about collaboration and breaking down silos. Let’s innovate! (Weird hearing that from a DBA, huh?)

I’m recommending a DevOps litmus test. If your application’s database changes don’t meet the following criteria, spare my team the time and headache of weeding through the B.S., and don’t bother demanding that we let you push to production.

1. Your database change method must be designed to allow build, test and release to happen at the speed required by the business. If it doesn’t actually align with Velocity and Agile methodologies, it’s not satisfying two of the three forces that DevOps originally triangulated. (Hint: We’re looking for graceful failure here.)
2. Your database change method must actually make both dev AND ops’ lives easier. Too many alleged DevOps tools give dev a boost but largely ignore ops. Those two teams are represented equally in the term, and any solution described as DevOps should have equal impact on both parties.
3. It must create new efficiencies through automation, not add work. Although the fundamentals of DevOps pertain to helping two human teams better integrate their cultures and workflows, automation is an integral component. If you’re creating more processes and activities that still require a person to man the controls (no matter how altruistic), you aren’t doing it right. The DBA team reviewing your scripts counts as manual labor!
4. It must promote the sharing of responsibility rather than creating a power struggle, inhibiting progress or wresting control from dev or ops. Vendor lock-in is becoming less and less of a concern in today’s service-based, startup-led enterprise environment. But if your method or vendor’s value is rooted in the lockdown of steps or technologies until your (or their) expertise saves the day, you’re simply not working in a truly DevOps-ian way.

DevOps simply shouldn’t be a term abused by developers who want to make the direct push to production. It’s well on its way to no longer holding any real meaning, rather than serving as the force for good that we need for the database. In an effort to salvage DevOps’ significance, I’m willing to challenge every developer wanting production access “because it’s DevOps.” This DevOps hollowness epidemic has to stop, lest we provide a severe disservice to our customers and cost ourselves our jobs.

Oh and hey developer, next time you ask about this, I’m making you read the Sarbanes-Oxley Act and telling the CFO.

TL;DR: Dropping your hundreds of SQL scripts in a directory and having the DBA team run them is not DevOps. It’s you being lazy.

Read next: Infinit’s new product is a decentralized p2p file system for DevOps

Image credit: Giphy