In this fourth session in our DevOps 101 series, we’re going to delve into Database DevOps specifically. But before we get going, I just want to do a quick check to make sure we’re all on the same page. Donovan Brown’s definition of DevOps seems to have been adopted by almost everyone nowadays because it’s very clear: “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users”.

I’ve written before about building your own monitoring systems versus buying a monitoring tool like Redgate SQL Monitor. There I talked about the time that someone tasked with managing and maintaining data gets back in their day when they purchase a monitoring solution. However, that’s not where the business focuses. The business frequently wants to know one thing and one thing only: what’s the return on this investment (ROI).

I was recently joined by Chris Yates, Senior Vice President, Managing Director of Data and Architecture at Republic Bank for our webinar, Gain the competitive edge with a monitoring tool. The session sparked an insightful conversation around estate monitoring from the perspective of a Senior VP, and I wanted to share some of the key take-aways.

This is the third part of my DevOps 101 series, so before we get going, let’s do a quick recap of what we’ve covered previously In DevOps 101: What, who, why, and how, I talked about how the definition from Microsoft’s Donovan Brown encapsulates DevOps succinctly as: The union of people, process, and products, to enable the continuous delivery of value to the end users.

Development teams are under increasing pressure to keep up with the demand for faster delivery of database changes, while ensuring code quality isn’t compromised. This pressure comes from both business requirements and industry expectations. The 2021 Accelerate State of Database DevOps report reveals that the number of teams who are elite performers is increasing year-on-year (making up 26% of those in the study) and these teams have more frequent code deployments and a lower change failure rate.

The desire to release features faster and deliver value to customers sooner is prompting many IT teams to adopt DevOps and Agile practices. By automating parts of the development process where possible and working in shorter cycles to release small changes more often, those teams that do well experience fewer errors and produce higher quality code. All of which is good news, until it comes to the database.

Data masking is a technique of hiding sensitive data from certain users who should not be able to view or access the actual values. This post will look at the reasons why you might choose to implement data masking and discuss both dynamic and static data masking techniques, and when it is appropriate to use each of these.

In the first part of my DevOps 101 series, we tackled the fundamentals of What, who why and how. In this follow-up, I’m going to focus on how to gain buy-in across your organization. That said, who do you need buy-in from? DevOps is the union of people, processes and products to enable continuous delivery of value to our end users, according to Microsoft’s Donovan Brown. That’s a good explanation, because the focus is not on tooling, or processes, or even just people.