I've been writing, talking, and practicing DevOps for nearly 20 years. It wasn't called DevOps back then, but in the early part of this millennium, I worked in a software team that embodied many of the three ways of DevOps.  We made small changes, we worked rapidly in short cycles, we adapted to our business needs, and we released often.

And we included the database.

At the time, this was a small team of about 15, and I had good control of the database processes, able to influence, debate, and demand our developers improve their skills regularly. We didn't think about the database as anything more than one more challenge to overcome in order to build and release our software rapidly. Others feel that way as well and the ACM notes that a SQL database is no excuse to avoid DevOps.

This articles covers many of the things I've been preaching for some time. We use automation, we adopt good techniques, we instill discipline in our work, and we continuously improve. The article provides a few techniques for using deploying database changes. I do think some of these are good ideas, but as with many things, the devil is in the details. This is a high level look at what you want to accomplish, but the actual mechanism for making changes will vary, depending on your environment.

My employer is constantly searching for ways to improve database development, and we follow many of these techniques in principle. We recognize that testing and deploying changes needs to be easier and more reliable. As we build solutions, I think we've helped customers in many ways, however, my fellow advocates and I continue to preach a few things not in the article.

First, we need to continue to improve our code skills, which include data modeling. Moving faster doesn't mean we get to shortcut good design principles. Second, everyone working on software touching the database needs to work closely together. The data is the most important part of this process, and we can't afford to let anything happen to it.

I implore you to become better code writers, better software developers, and better team players. I also encourage you to look at DevOps as a set of principles, not as something you buy or install. Like much of life, adopting DevOps is a journey, just like your work with SQL. I'm sure that journey isn't complete.