Building out processes and mechanisms for automated code deployments and testing can be quite a lot of work and isn't easy. Now, try the same thing with data, and the challenges just shot through the roof. Anything from the simple fact that you must maintain the persistence of the data to data size to up time, and you have real problems in front of you. However, adopting database deployment automation and testing has enormous benefits. Faster, safer, production deployment enhances the protection built around your production systems. Whether we want to use the loaded term of DevOps or not, the benefits of this style of development and deployment are easily documented and measured. So, why are so few people doing it? Conservation of Momentum If we were talking about a…
A question came up on the SQL Server Central Forums, how could you use Red Gate SQL Compare to automate creating scripts for all your databases at once. What’s the first thing that popped into my head? Yep, Powershell. SQL Compare Pro comes with a command line utility that allows you to automate just about everything you can do with the GUI. I like to use it when I’m setting up deployment mechanisms for systems because it makes one click deployments possible. I won’t go into all the methods of that type of automation here. For a lot more information on that topic, check out the Team-Based Development book. If you’re interested in exploring how you can use the command line, just type this: sqlcompare/? Now is a good time…
I'm stuck. I've been advocating that our company use composite projects for our deployments using the VSTSDBE GDR (Visual Studio Team System Database Edition, General Distribution Release for those not instantly geeky). In a nutshell, VSTSDBE offers two mechanisms for deployment across multiple environments. Both of these work wonderfully well for automation when you are doing a full tear-down and rebuild. When you're doing incremental deployments, they both fail. Option 1: Use SQL Command variables to set environment specific variables such as file location, etc., and post-deployment scripts to set security. This works. It's the method we used prior to the GDR. Unfortunately, security and other environment specific information is hidden inside scripts rather than visible to a given configuration directly within the VS interface. Option 2: Create a composite…
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…
The new book is available in a free download from Red Gate. I had a lot of fun working on the three chapters that I did for this book. The topics I received are near & dear to me because of all the time I've spent working on getting databases into source control and automating (as much as possible) the deployment of databases out of source control. Everything I go over in the book might not be 100% applicable to your situation, but I'm pretty sure almost anyone involved in database development and deployment can find some useful information there. For those who are interested, I don't just cover Red Gate tools in the book either. There's quite a bit of time spent describing how to automate deployments using Visual…
The invitation this month for #PGSqlPhriday comes from Dian Fay. The topic is pretty simple, database change management. Now, I may have, once or twice, spoken about database change management, database DevOps, automating deployments, and all that sort of thing. Maybe. Once or twice. OK. This is my topic. I've got some great examples on taking changes from the schema on your PostgreSQL databases and then deploying them. All the technical stuff you could want. However, I don't want to talk about that today. Instead, I want to talk about something really important, the concept of rollbacks when it comes to database deployments. Why Are Rollbacks Difficult? The entire purpose of your PostgreSQL database is to persist, that is to store, the data. Then, of course, offer up a way…
In a few weeks at the PASS Data Community Summit, I'll be joining several other Redgaters to put on an all-day precon where we take you on a database DevOps journey. Please let me tell you all about it. From Nothing The plan is simple. We're going to take you from a fully manual deployment process, to a fully automated process over the course of the day. We'll be deploying something about every 30 minutes. As the day progresses, those deployments will become more and more automatic. We'll be using a variety of tools, but the big driver will be Redgate's Flyway. The fact is, most people recognize the need for a DevOps-style approach to their database deployments. However, doing it just isn't easy. This all-day seminar is intended to…
One of the things I love the most about Platform as a Service when it comes to data is the fact that you get RDS backups, built in. Go to the forums. Evidently, backups are one, or more, of the following:a) insanely difficult, so no one does themb) not considered important so no one does themc) not necessary in modern systems because of X technology so no one does them Then, someone deletes a row the business wants back. Someone drops a table. Someone drops a database. Then you find that one, or more, of the following is true:a) no one has ever tried to restore from X technology and you can'tb) come to find out, X technology doesn't really do backupsc) backups are still fundamental to protecting data Enter,…
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…