Operations | Monitoring | ITSM | DevOps | Cloud

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.

In 2017, Redgate published the first State of Database DevOps report, based on a survey of IT and database professionals from around the world. Every year since then, it has provided insights into the adoption, usage, challenges and benefits of DevOps and database DevOps. We’ve just launched the fifth edition of the report, which has had over 8,000 responses to date.

One question we frequently hear from customers using the Microsoft stack is, “should I use Git or TFS?” The question requires a little decoding due to the way that Microsoft has shifted their brands over time. Here’s some background. Many people still refer to this as “TFS,” regardless of the version they are using. TFVC used to be the default type of repo for TFS projects.

Since 1999, we’ve been developing tools at Redgate to support database deployments for SQL Server. In the past couple of years, we’ve increased our effort in this space by further developing our proprietary technologies based on SQL Compare, and acquiring others like Flyway, the most popular database migration engine. As a result, we now offer tools which provide more options for SQL Server and also support deployments for 20 different database systems.

Many organizations use out-of-date architecture patterns for developing relational databases which are a pain to manage, slow developers down, and limit testing and innovation. It’s time to modernize these environments and improve standards for database development. In the years I worked as a consultant specializing in SQL Server administration and tuning, I frequently fielded questions from customers about how to best manage databases in development and test environments.

When it comes to reputational risk, a reactive approach is generally taken by organizations, with efforts focused on handling threats to their business they are already aware of. As much as this enables short term damage limitation, it may not be enough to manage and protect your risk in the long term. Instead, a more proactive approach is key to success.