Docker, Git and DBATools

For those who don’t know, last week was the PASS Summit. It’s an amazing event every year, but this last week, I saw a ton of indications that our peers are spotting the changing technology landscape largely defined by three tools, Docker, Git and DBATools. None of those indications resonated quite as much as this tweet from Kevin Hill:

3 things I can no longer justify ignoring: #dbatools Git and #Docker for my dev SQL work@cl @sqldbawithbeard @Kendra_Little and @unclebiguns @GFritchey, I blame you 🤪😂

There’s more but those are top 3— SQL Cyclist (@Kevin3NF) November 9, 2019

There are a million things to learn about in our rapidly shifting technological landscape, but I think this assessment, especially the way it was put, “no longer justify ignoring” really nails some of the fundamentals.

Let’s talk about why you can no longer ignore Docker, Git and DBATools either.


To say that the DBATools are an open-source, PowerShell module in support of automating your Microsoft Data Platform is a severely gross understatement. DBATools are an automation engine that go far beyond simply being a PowerShell module. You must, for the sake of your job and your career, learn, and implement, all the automation you possibly can. DBATools are how you’re going to get a lot of this done. Best of all, you don’t really have to know a ton of PowerShell (yeah, in theory, you don’t have to know any, but you’re going to be better off knowing a little).

I don’t generally promote DBATools a ton, although I do promote them and talk about them regularly. I’m just overwhelmed and I think others are doing a great job generating material here. Start with the source, linked above, and start automating pretty much everything you do.


I’ve talked about containers before (including doing a bunch of introductory blog posts on Docker). I’m going to repeat myself a little here.

Containers, probably through Docker, and possibly Kubernetes, will fundamentally change the way you do development and testing. Through the use of containers, you have the ability to more or less treat SQL Server instances as a service that you can spin up & down locally (or on other machines) for dev and test completely as needed, in an automated fashion.

This is so different than having to install and maintain an instance locally, or do the same through a virtual machine, that it’s a little hard to convey all the possibilities. Certainly a single blog post isn’t going to cover enough. Let’s just say the ability to get a new version of SQL Server and have it running in 30 seconds or less is pretty darned powerful.

You’ll be able to automate so much more of your development and testing because you can directly control, through code, what and instance is, how long it lives, and more.


And let me state up front, it doesn’t have to be Git, but you do need source control. Third party surveys and my own impromptu ones when I present tell me that more and more of you are using source control (most of it one form of Git or another). However, it’s only risen from around 25% to around 40% over the last couple of years. It should be at 80% or better.

Getting your code into source control is step number one of building out a fully automated development, deployment and testing process (AKA DevOps). However, putting your code into source control is rewarding, all by itself. You gain an undo mechanism that just isn’t possible with a database. You add documentation and change tracking. These benefits are more or less immediate and highly useful.

Twenty years ago when I first switched from being a developer to being a DBA, I looked for source control in the database. Because, of course. It wasn’t there, or, it was, if I was willing to do lots of manual, time consuming, error prone, work. During the intervening time, everything has shifted. It’s now actually very easy to get your database in, and out of, source control. That you’re not doing it is shocking. Heck, I know some third party software that can help <cough>Redgate</cough>.


Our landscape is shifting and you must shift with it. This isn’t just about SQL Server either. More and more of us are multi-platform with a little PostgreSQL, Hadoop, CosmosDB, and others, tossed in to our data management mix. If you’re not using tools like DBATools to automate your processes, you’re going to fall behind. When you don’t have Docker containers as a fundamental part of what you do and how you do it, development and testing will be harder for you than for your peers and your competitors. If you are not launching yourself into fully automated development, testing and deployment starting from source control, you will not be as nimble.

If you haven’t already started down the path with these tools, Docker, Git and DBATools, now is absolutely the time. To take a phrase from PASS, future proof your career by learning these tools.

PS: Kevin also has a nice write up on what he learned at Summit

4 thoughts on “Docker, Git and DBATools

  • Tom Uellner

    Great post Grant. I’m in the middle of using dbatools to save copies of all our SQL Server configurations to make DR easier. Learning PowerShell as I go. I’m also giving and in-house presentation on Docker and the presentations I’ve seen you do were a big help. I also have SQL Source Control setup to save our databases in Git. Git and I still aren’t on the best terms but it’s getting better. Redgate and GitKraken are helping that relationship.

    • Excellent stuff. You might look at SQL Change Automation. It has a better love affair with Git currently than SQL Source Control does. However, it is a very different model too, so might entail biting off too much change all at once.

Please let me know what you think about this article or any questions:

This site uses Akismet to reduce spam. Learn how your comment data is processed.