I’ve been an advocate for database DevOps since before DevOps was a thing. When I first switched from being a developer full-time to being a DBA full-time, the first shock to my system (and there were a lot of them) was that people didn’t put their database code into source control. Turns out, at the time, more than 20 years ago, the reason was because it was brutally difficult to do.
Fast forward to today, and there are no serious impediments to implementing source control for your databases. Further, the impediments to automating more and more of development, testing, and deployments for databases are shrinking faster and faster all the time.
Whether or not you’re doing a literal DevOps process, the concepts of breaking down the barriers to communication, adopting shift-left methodologies, self-service, automation, all the things that make up DevOps, are becoming the way that successful organizations are getting the job done.
Don’t believe me?
Redgate Software has just released the State of Database DevOps 2020 report. Follow the link to get your own copy. We talked to over 2000 respondents about how they’re getting their database development, testing and deployment done.
Let me call out a few of the things that I found exciting or interesting.
State of Database DevOps 2020
There’s a lot of great information in the report, but, I’d recommend you start by reading the introduction by Kellyn Pot’Vin Gorman. I’ve benefited from Kellyn’s insights to various things for several years now. She’s absolutely worth listening to and does a great job of rounding up the unique challenges and fantastic opportunities that adopting a DevOps approach to databases offers.
DevOps by it’s nature delivers code faster. You’d think that would result in more errors. However, the addition of lots of automated testing helps to ensure that, in fact, the error rate is reduced:
37% of those who have adopted DevOps across all projects report that 1% or less of their deployments introduce code defects which require hotfixes, compared to 30% for all other groups.
State of Database DevOps 2020
Another point that rang really true for me was the blockers for implementation:
Disruption to existing workflows/business squeezed into the #1 spot, up from 21% in the 2019 report.
State of Database DevOps 2020
Lack of appropriate skills in the team was selected by 22% overall in the 2019 report as well. We’ll call this concern “upskilling” for brevity
Because I teach DevOps, both in public courses, online, and in private consulting, the one thing I hear the most is, “But we’ve always done it this way” and that is that first point. Disruption to your existing work flow is painful. Inherently so. It doesn’t even matter for some people that, yes, we’re going to slow down for six to eight weeks while we figure this stuff out and then we’ll be delivering more code, faster, and safer. That disruption is a blocker. Getting around it is hard because of the second blocker, a lack of appropriate skills on the team. So if you’re sitting there thinking you don’t know how to implement this and even if you did, the disruption would be painful, you’re right in line with where others are.
But, it brings up a couple of more points from the survey. The biggest pain points for IT are the fact that it takes so long to get code out the door and this causes the organization to lose the ability to change what they do and how they do it quickly enough to keep up with the market:
Even the third pain point, the risk caused by deployments, is also one of the reasons that people won’t implement DevOps. Since deployments are painful, why would we do more of them? But, DevOps and an increased deployment cycle, means safer, smaller deployments. Also, deployments are painful, at least in part, because people do them so infrequently. This means little practice, which means more errors, more problems, and more pain.
For me personally, one of the biggest takeaways from the survey was that larger organizations are adopting DevOps. It’s easier with a small to mid-sized business to change the way you do things. Enterprise-level organizations can be slow to adopt to change, let alone take on something that will literally accelerate change. Yet, more and more larger organizations are diving into DevOps in order to respond more quickly to changing business needs. In my opinion, this is huge, and probably the biggest driver for your career. Learn database DevOps, because you’re going to need it for your continued employment.
Conclusion
That’s just a few of my takeaways from this excellent report. Read it yourself and find the ones that you think are the most important. The simplest thing that can be said, we’re moving faster with databases than ever before. That’s great news because we’re no longer seen as a roadblock or a problem to be overcome. Rather, we’re active and supportive members of the team. That’s the right way to be.
I hope this information proves useful. If you want to get started on learning how to implement automated processes for your database, I want to help. I’m hosting a training day at SQLBits on April 1 (I promise, very few April Fool’s jokes). Go here for more information:
I might try and get down there, don’t think the company will pay though (train+hotel+conference) cost is getting up to £700
but I would love to add that “disruption to workflow” completely goes away with continuous integration/automated pipeline builds…. you just have to bite the bullet and take the pain away from the build/release process
I agree. Ultimately it’s completely removed. Initially however…
Thanks for that, Grant. Can you share also what percent of the 2000 orgs surveyed are indeed using DBA Devops, or even just using source control for DBs? I do realize your main point was to promote the concepts, and especially to address the main reasons folks folks report for being slow to adopt.
But it would be interesting (for many I’m sure) to know what percentage of respondents are indeed already there (or not). Sure, we could all download the report, but if you may agree that this could be interesting enough to share for readers of this post, it would be appreciated.
That’s a little hard to define since the respondents self-define as to whether they’re doing DevOps or not. 36% claim across some projects, 18% across all projects, 14% in proof of concept, 18% planning to adopt, 14% no plans. It’s in the report.
The CAB section, the section about obstacles, and all industry-level comparisons I found to be really interesting. I have had a difficult time finding out what skills companies are lacking, but in general I’m finding that PowerShell scripting is becoming increasingly valuable and I would like to know more about the relationship between PowerShell and DevOps adoption rates. I would expect larger organizations and those who are investing more into the cloud are more likely to utilize PowerShell and DevOps effectively – but just a guess, no data to back that up… thank you for the post!
Interesting. We have additional data that didn’t make it into the report. I’ll check to see if there is anything around adoption of PowerShell.