Voice of the DBA

Tag: DevOps

Redgate Lives DevOps

At Redgate, we release a lot of changes to our products. In fact, this is the “About Redgate” slide I’ve been using in talks related to the company.

If you look in the lower right, you’ll see product releases from last year (2017). We have 30-ish products, so that’s roughly 38 releases per product. Not every product releases at this cadence, but a lot of them release every week. SLQ Monitor, for example, releases every Wednesday.

Of course, there’s the inevitable release-a-bug-and-need-to-fix-it-so-a-second-release this week, but those don’t happen too often. I’ve been tracking releases this year, and not too many were corrected in the same week, but it does happen.

Some people say that’s the problem with DevOps, but I think it’s the advantage. I guarantee that most software releases include bugs. If you release once a quarter, are you ready to re-release in a couple days to fix something? Or do customers live with issues for a quarter? The advantage of DevOps is we can fix things quickly, in addition to adding new features quickly.

Redgate does some amazing development work and I’m proud of the ladies and gentleman that write the code.

I still complain, and there’s room for improvement, but they do a great job and I try to remember to thank them and complement their work when I do see them.

August 28, 2018
DevOps is Really Helpful

A few weeks ago I gave a presentation at the 24 Hours of Pass Summit Preview. During my session, a demo broke and I had to ignore it. Later I found the issue and blogged about it. What was neat for me is that I didn’t need to keep my code up or apps open, but I still found the issue quickly. I found it because I have a DevOps process that instruments and tracks everything.

This happened to me a few years ago. I was at a SQL Saturday and demoing one of the Redgate tools. There was an error and I couldn’t move changes to a downstream database, which threw me off. That was the point of the talk. I decided to debug on stage (or behind the podium in this case), looking through the logs. Within a few minutes, I had found the issue and solved it. A real life DevOps story in action.

The idea of DevOps is what most talented developers and DBAs do. They ensure that they don’t just make changes on a whim, and they don’t depend on SSMS to be kept open. If they find an error, they save it, or they ensure their process captures all relevant logging. I’ve built systems like this, but many of the modern tools we use in DevOps automatically do this. Build servers and release servers make it a point of capturing all logging, so when that PoSh or CLI system runs, the output is saved and available for solving problems. And the data is available for improving the process, which is the goal.

At various times in my career, I haven’t followed a set process, I’ve “tried” things in SSMS, a configuration dialog, or a command window that haven’t worked. I’ve sometimes remembered to undo them, sometimes not. I’ve lost track of what I’ve run often, just because I was working in an ad hoc manner. That led me to learn to do better, which led me to embrace and follow many of the principles and ideas that people call DevOps today. These are things I learned to do those things 15 years ago.

Lots of DevOps is about using automation and tools, and those really do help. Having a pipeline for software changes, and one for configuration changes, reduces the chance of mistakes and problems. It also lets you instrument and track everything that happens. However, these are the easy things. These are the things that really talented professionals already do in their daily work.

The hard part of building software is building a culture that learns to work together instead of separately, or worse, adversarially. It is truly hard to work together and concern yourself with the customer first, and your job last. Or put the QA person, the DBA, the developer, or someone else ahead of what makes your day easier. It’s also hard for management to build a framework where we don’t have incentives to put our own interests ahead of others. If we can do that, and build a DevOps style process, things work smoother, and our software will be better. Maybe more importantly, we’ll enjoy our time at work.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

July 2, 2018
Republish: State v Migrations

Back in the UK, so a republish of State v Migrations

June 18, 2018
DevOps Debugs the Demo

I had my 24 Hours of Pass session today, Database DevOps to Ensure Compliance, and my demo broke. At least, it broke for me. I kept going and talked over things, but I hate that. It would have been impressive if it had worked.

Debugging

In a live session, I might have debugged this a bit more. I’ve had things fail a few times over the years, but before I was doing the DevOps thing, I couldn’t usually figure things out until I got back to a desk. With DevOps, I’ve solved a few things with the instrumentation.

In this case, I was cognizant of time, as another session was starting after mine, without the break that usually comes. Plus since it’s online, I can’t tell if anyone really wants to know what happened.

I do, and as soon as the webinar ended, I looked at the release and realized what happened.

The Error

I had this error.

I’d made four changes in Development that were supposed to deploy through to Production. I know they do because I’d done this not 15 minutes before the webinar, so the process was working. No errors, so what was wrong?

One thing I’d done was to practice a change, which created a build. I didn’t deploy this forward, so it was essentially sitting in the VCS, but wasn’t in downstream environments. When I looked at my release, I saw this:

Note the build number above, 912. This was my previous build. As soon as I clicked to the CI process, I saw that my last build was 914.

I’d been in such a hurry to kick off the release that I clicked too soon. The build completed, but the release page hadn’t gotten an update and picked build 912. Since I hadn’t deployed this, I didn’t get the warning that I was re-deploying a build that had already gotten to the QA database.

I created a new release after the webinar, and it went. With ultimate confidence in myself, I just sent it to Production from QA.

And it worked:

Apologies for the issues. I’m not sure why Visualstudio.com was so slow here. Apparently the audio worked, so I’m guessing it was their site.

In any case, I’ll be hosting a webinar doing DevOps in a slightly different way on June 28. Register and join us if you want to see something similar but different.

June 12, 2018