If you're attempting to implement automation in and around your deployments, you're going to find there is quite a steep learning curve for DevOps and DevOps-style implementations. Since adopting a DevOps-style release cycle does, at least in theory, speed your ability to deliver better code safely, why would it be hard? Why is there a Learning Curve for DevOps? I recently did a presentation on a simple Continuous Integration process. Here are the tools that I used in the demo: Local Git repositoryVS CodeAzure Data StudioAWS CodeCommitAWS CodePipelineAWS CodeBuildAWS RDS PostgreSQLShell commandsYAMLDockerFlyway Also, I regularly present using Azure DevOps Pipelines too. Here's the list of tools that might be in a given demo: Local Git RepositoryVS CodeAzure Data StudioAzure Git RepositoryAzure DevOps PipelineAzure DevOps AgentRedgate DeployAzure SQL DatabaseYAMLPowerShelltSQLt While there…
I've just completed my first, successful, AWS CodePipeline. I'm sorry to say it took me weeks to figure out just how simple this was. Frankly, it's embarrassing. I already posted how I used the example code supplied by AWS to build a full blown CI/CD process. However, I went back into all the tools and tore it all apart so that I could build it, myself, by hand, in order to better understand it. Code All The Things Let's first talk about the tools I used. I have my code sourced in CodeCommit. It's Git. I'm using AWS CodePipeline to manage the flow control. It's triggered by a commit to the main branch. It sets up an Ubuntu instance that I can use to do things with (you can use…
Next week, July 22 and 23, I'll be presenting at Redgate Summit. Summt is our smaller, focused sessions. This one is about the concept of how DevOps, or, more accurately, a DevOps mindset, can enable you to do more with less. The idea that someone will automate themselves out of a job is something I've always found humorous. I say this because, when I first started figuring out how to automate database deployments, I was only actively supporting 1-2 teams of developers. When I finally had a mostly automated deployment methodology, I was supporting 5-7 teams. In short, I didn't have less work because of the automation, I had more. The trick is, you need to engender a mindset that does two fundamental things. First, focus on automation. If you're…
Actually, these two topics don't have anything to do with one another. I just ran out of days to promote everyone individually who was taking part in putting on Redgate Streamed. Steve Jones Steve is one of the better people I know when it comes to the wisdom and need for testing. Speaking only for myself, I kind of hate setting up tests. Yes, I know how vital they are. Yes, I know they make an enormous positive impact on our ability to generate better code, faster. Yes, I know they're a fundamental aspect of DevOps. Yet, they're a pain the bottom. However, Steve has a way with them. He really does make them look easy. If you're like me and not a huge fan, then his session "The Basics…
I sincerely believe the key to your future as a DBA is your ability to automate everything you do. However, the single hardest thing that you have to do is keep up with the changing business and IT environment, which means, deployments. Lots of deployments. How are you going to get that done? Cathrine Wilhelmsen I have to admit, publicly, when I first met Cathrine, I was not the nicest person. I just couldn't believe that this person who sounded like they were from Ohio was actually Norwegian. I asked for her drivers license. Thankfully, Cathrine forgave me my rudeness and I'm very grateful for that. The reason I'm grateful is, she's seriously on top of her game when it comes to automation. At the upcoming Redgate Streamed event, April…
I absolutely love Query Store and the ability it provides to force a plan is amazing. However, there are a lot of little gotchas in this functionality. I just recently found one that has quite a far reaching effect. Let's talk about what happens when you DROP and then CREATE a stored procedure. Query Store and Plan Forcing Let's quickly recap how Query Store works and how Plan Forcing works. First, Query Store is driven by query, not by procedure, not by batch, but by query. Second, plan forcing is also by query. However, there are queries and there are queries. Let's take this as an example: CREATE PROC dbo.AddressByCity @City NVARCHAR(30) AS BEGIN SELECT a.AddressID, a.AddressLine1, a.AddressLine2, a.City, sp.Name AS StateProvinceName, a.PostalCode FROM Person.Address AS a JOIN Person.StateProvince AS…
I've been an advocate for database DevOps since before DevOps was a thing. When I first switched from being a developer full-time to being a DBA full-time, the first shock to my system (and there were a lot of them) was that people didn't put their database code into source control. Turns out, at the time, more than 20 years ago, the reason was because it was brutally difficult to do. Fast forward to today, and there are no serious impediments to implementing source control for your databases. Further, the impediments to automating more and more of development, testing, and deployments for databases are shrinking faster and faster all the time. Whether or not you're doing a literal DevOps process, the concepts of breaking down the barriers to communication, adopting…
Maybe you're using DevOps within your database development and deployment. Maybe you're not. Maybe you're automating all the things or maybe you've got a completely manual set of processes. Fact is, Redgate would like to know. If you can spare a couple of minutes to swing by this link and fill out this survey, I'd sure appreciate it. The fact is, database deployments, regardless of the database, regardless of it being relational or not, can be very difficult. The core of the problem is retention of the existing data. If it was possible to deploy databases the same way we deploy code, throw away the old one, install the new one, usually in a single step, that would be great. However, unfortunately, throwing away databases usually gets organizations quite upset.…
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…
Yeah, Redgate is only one year younger than my children. What's really frightening is that I've been using Redgate's products since my kids were a year old. I was a VERY junior DBA twenty years ago having just made the move from full time development. I'll tell you though. I think I had Redgate's SQL Compare open on my desktop non-stop from the moment it was available. I know I personally ensured that four different organizations purchased at least one license. Now here we are, twenty years later. My kids are grown, but I'm still gleefully using Redgate Software. Yeah, I know, now I work for them, but that's just a bonus as far as I'm concerned. I've been praising and promoting Redgate for twenty years and I hope I…