Operations | Monitoring | ITSM | DevOps | Cloud

My blog post from February 1 explains that Redgate took the opportunity to purchase the assets of PASS with the main goal of supporting the community. The PASS association ran for 21 years bringing together a community to connect, share, and learn. The community of course lives on, however the association no longer exists as it once did. Working with SQL Server and the data platform is what unites us all. Data is at the heart of everything we do.

As the manager for enterprise applications and data at the University of the Sunshine Coast in Queensland, Australia, I face a lot of unique challenges. The university itself has around 25,000 students, 1,000 permanent staff and another 1,000 seasonal staff who assist with key academic sessions. They’re spread out across the flagship campus at Sippy Downs and a number of satellite campuses and research and teaching facilities in other locations.

This question was raised at the recent Redgate Summit: How does the implementation of a microservices architecture affect the implementation of a database DevOps approach? I could even rephrase it a little: Does a microservices architecture affect a database DevOps approach?

Since 2018, over 2,400 SQL Server professionals have provided valuable insights into how they monitor and manage their estates, and what challenges they’re facing, through the only industry-wide survey of its kind. The results of the annual survey have not only benefited the community but also helped us better understand how we could shape our own product development to deliver more value where organizations need it.

There’s no doubt the cloud is having a big impact on the nature and make-up of SQL Server estates. The 2021 State of Database DevOps report from Redgate, for example, showed that 58% of organizations now use the cloud either wholly or in combination with on-premises servers, compared to 46% in the same report a year earlier.

I work in computers and my son works in manufacturing, but both of us loathe a single phrase: We have always done it this way. Please allow me to be clear on this. If you can back up this statement with “Because…”, and you list out valid points, even if I disagree with them, we’re all good. However, frequently, if you follow up this statement with the simplest of questions, “Why?”, you don’t get good answers. Usually, you’ll get a repetition of the phrase.

When you begin to automate your deployments, you’re also going to start automating your testing. After all, a deployment, in and of itself, is a test. However, pretty quickly, you are going to come to the question that’s the title of this post: Who is responsible for building tests?

When I first started trying to figure out how to automate database deployments, over 15 years ago, I will freely admit, I was both skeptical and reluctant. I had to be dragged up to the notion that automating getting the database code out the door wasn’t just an excuse by the developers to find a way to bypass the DBA team. As per the traditional, biased, story, our favorite word was “No!”.

Almost every time I teach a class on DevOps, one of the questions that comes up is: How do we do code reviews in this automated process? There are actually a number of answers to this question. Let’s walk through a few.

Once you’ve committed to changing your culture in order to automate your database deployments, what’s next? You’ve already done the hard part, making the decision to shift the culture. Now, what’s involved is just lots of labor. There are three things you can do to begin your Database DevOps journey: Let’s discus these in detail. It’s important to understand, not just why these are your first three steps, but why they should occur in this precise order.