You recognize that you need to provide a pipeline for database deployments, that you need to automate as much support for your development teams as you possibly can, that you have to have testing in place to ensure protection of the production environment, that you need to speed your processes. In short, you recognize the need for taking on a DevOps approach, an Application Lifecycle Management (ALM) approach, even, a Database Lifecycle Management (DLM) approach. Cool. Now what? Well, there are three fundamentals that you need to get under your belt. You need to get your database into source control. You need to set up a continuous integration process. You need to set up automated deployments. All tough nuts to crack. Hey, we get it. That's why Redgate Software is going…
Check out this DevOps Reactions animated GIF and caption. It's funny on multiple levels, but it also makes me both mad and disappointed. I get mad because it's 2015. Surely by now most of us, especially those who have worked in the enterprise with development teams, know that the old 1970s vision of a walled off data center with DBAs in white lab coats acting as gatekeepers to the data is long discredited. As DBAs, even if you're not working with development teams at all, you're just offering a service to the business. This whole, a DBAs favorite word is "NO", meme needs to die a quick, hard, death. All those "Technology X" is going to eliminate the DBA articles that come out every six months like a comet with…
I've been attempting to expand my reach to get back to my roots in development. I'm doing this because I really believe in the concepts behind devops, that these walls we've erected between development and dba, between dba and san admin, et, ad nauseum, cetera, need to come to an end. The great news is that there are a lot of other people who feel the same. We're changing things. Come on over to the dark side, we have wine. Any way, I had a blast talking database devops with Bryan for his podcast. Have a listen and let me know what you think.
Oh good gosh. Six months without a single blog post. Most important information: I'm not dead. Apologies. The issue is pretty simple. I'm getting old. Ha! Seriously though, I am suffering a bit from a lack of energy to do ALL the things and still maintain this blog. However, to hell with that. Time for a refresh. Watch this space. I'm going to be cleaning it up. Changing a few things. Also, getting back to posting. I don't think as many of the posts will be technical though. I'm going to start posting some leadership ideas and suggestions. I've been involved in community for a long time, and I want to see it keep going. I have received so much from the communities I'm involved with, I want to give…
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…
As I've been working more with PostgreSQL, I've found that I'm basically pretty happy just issuing SQL commands to get work done. However, it's handy to have an actual programming environment to work from. A few reasons for this. First, and probably most important, a good programming environment has easy connections to source control. Also, you'll get, hopefully, some help with type-ahead for the code you're writing. Finally, having a visual of the stuff in your database can be handy while working on it, so a GUI is nice. I use Azure Data Studio for most of my PostgreSQL work. Azure Data Studio and PostgreSQL I'm not sure exactly when support for PostgreSQL was added. The two years I've been poking around with PostgreSQL, Azure Data Studio (ADS) has supported…
This is just a quick note to talk about the future, mine, yours and this blog. First, I'm not abandoning SQL Server. I'm actively working on a revision of the query performance tuning book (something I should be working on instead of writing this post). SQL Server is my first, and best, database love. We're not going anywhere, SQL Server and I. You can expect more posts on SQL Server, query tuning, execution plans, DevOps, community, #sqlfamily, and everything I've blogged about for the last, ooh, 14 years next month. Second, our family is growing. Just like when a family brings home a new baby, well, I'm adding another database. It doesn't mean I don't love my first database. I still do. We're just going to ALSO be talking about…
Hello all! I wanted to apologize to you. I haven't been keeping up with the blog well at all over the last couple of months. I have simply been struggling with motivation. I have enough for my work commitments, but extra-curricular stuff has just been lagging. So, please allow me to say I'm sorry for not getting more sharing out there. Next, I'm making a commitment to you that I will be posting regularly again from this point forward. As a part of that, I'd sure love to hear from you on what kind of content you'd like to see. Do we need more on execution plans, or on SQL Server fundamentals? Would a bunch of stuff on Extended Events or Query Store be more interesting? How much DevOps stuff…
As part of my job, I've been tasked with doing some of my work in Oracle, so I'm learning Oracle. Allow me to share a little of my pain as I explore a space I've only ever dabbled in. Getting Started in Oracle Back in the day, in order to get started with Oracle, you begin at the Oracle web site. There, you download an installation, after getting a license (or while, whatever). In our modern era, this is the hard way to get stuff done. The first place I went was Azure. There is excellent Oracle support on the Azure platform and, best of all for me, it's really easy to fire up an Oracle VM. I had a server up and running in no time. Win! Another way…
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…