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…
I've said it before and I will repeat myself on this because it's an important concept: DevOps is about culture and communication, not tools Now, that said, to implement the automation required in DevOps, you're going to have to get into some degree of tooling. There are a whole slew of possible tools to support you: Jenkins, Team City, Octopus and more. All these tools offer excellent solutions with variations on limits, methodologies, etc. You'll need to explore them to understand which ones are best for you and your processes. I've been doing a lot of work lately in another tool, Azure DevOps. Let me show you a little of what I've done. Azure DevOps Pipelines I don't mean for this to be a complete tutorial on setting up Azure…
In preparation for my upcoming DevOps training days (see the bottom of this post for details) and for some articles I'm working on, I've been building all new automation processes for database deployments. In the past, I've been using a fairly simple (and far too simplistic) example to do most of my demos. I haven't built a full process in a little while. OH MY GOD!!! IT'S PAINFUL!!!!! Automation Ain't Easy The easy part of getting your DevOps done is the tooling. I say that all the time because it's true. The hard part is changing your organizations culture to support the level of communication necessary for a successful DevOps implementation. However, easy by comparison doesn't mean just simply easy. There's a lot of work involved and making mistakes early…
I've been working in and around data for over 30 years now. My title has changed a number of times and is poised to change again. My responsibilities have also shifted fairly continuously over that time. Even though it has been more than 20 years since I first took on the title of DBA, some aspects of the job are the same. However, over that 20 years, a stack of new technologies and processes have fundamentally changed a whole swath of what I do. The DBA Song Remains the Same Are your servers online? Are all databases available? Did the data load process run successfully last night? When was the last time a backup was run on this database? I honestly don't care if you're in the cloud, on-premises, or…
I find that I'm using containers more and more to get things done with SQL Server. They're so easy to set up for testing, spin 'em up, do stuff, turn 'em off, done. So, as I learn more and more about them, I figured it was time to start to share that learning here on the blog. First up, I'm NOT an expert on this topic. The two best people I know currently on this are Anthony Nocentino and Andrew Pruski. Those are the people you really should be learning the details from. I'm going to try to start to cover the introductory level of containers, Docker, and, at some point in the future, Kubernetes (maybe) and other orchestrators. However, I know that as my knowledge of how to work…
I spend a lot of time showing how to use tools to automate database deployments in support of DevOps. However, the one message that I always try to deliver with DevOps is that it's fundamentally not about the tools. No, the single most important thing in DevOps is communication. Therefore, the single most important thing in DevOps is people. People Are Good Are there evil people in the world? Unfortunately, yes. Can even good and decent people do evil? Again, unfortunately, yes. However, most people, most of the time, are trying to do the right thing. I would say that you need to arrive at this position first in order to implement a DevOps solution effectively. You can't be all "Developers are EVIL" or "DBAs are mean" or "My SAN…
I've been reading about the death of the DBA ever since I first made the jump from full time developer to full time data professional. The first time I heard it was when SQL Server 7.0 was released. Did you know that SQL Server 7.0 was self-tuning? In fact, it was so self-tuning that the DBA is a relic of the past and no one will be paid for that kind of work any more. Right. So, twenty years later, several versions of SQL Server with tons of improvement from back in the day, and I'm still working (and I hope you are too). Object databases were going to eliminate the DBA. ORM tools were going to eliminate the DBA. Then of course, NoSQL absolutely eliminated the DBA. In fact,…
Moving your database development, deployment and management into a DevOps methodology does involve choosing and implementing tools and tooling. Tools are a necessary aspect of DevOps because, one of the fundamentals of implementing a DevOps approach is automation. To automate, you need the right tools. However, tools and automation, while they represent a lot of work, are actually the easy part of the process of moving into DevOps. What's the hard part? Changing how you do things. Change is Hard One of the fundamental questions you need to learn when you start to implement a DevOps approach consists of a single word: Why. "We always manually run a script in staging prior to running it in production." Well, why? Why can't that be automated? Is there a reason that the…
With all the options available within T-SQL these days, it's more and more imperative that our code be clear and consistent. For example, there are clustered indexes and nonclustered indexes. Oh, but those are rowstore indexes. You also have clustered columnstore and nonclustered columnstore indexes. When you write T-SQL that says "CREATE INDEX MakeMyQueriesFast ON dbo.MySlowTable" which one do you mean? Well, the default there will be a nonclustered rowstore index. How do I know that? I checked the documentation. Oh, same thing will work with a columnstore index. You don't have to specify that it's nonclustered, but doesn't that seem unclear to you? It does to me. Clarity and Understanding You can write T-SQL a bunch of ways. Further, you can do some pretty crazy stuff with it that…
Thank you to everyone who participated in T-SQL Tuesday #091 which was on databases and DevOps. As I anticipated, this brought out quite a bit of variety on the posts. This is because DevOps is still... not quite cooked...(?) in many peoples minds. I think with the range of posts we saw here, it'll be a lot more clear to those who are just getting an introduction to it. Here are the posts (in no particular order) and a few comments on each: Databases and DevOps: Rob Farley - I like Rob's approach to this intro to DevOps. He's a consultant. It'd sure be nice if you had the protections that DevOps offers in front of your systems before he starts recommending changes. What Playing at Minecraft has Taught Me…