Rubbing DevOps on your Database

I’ve had quite a busy year and one of the things I’ve done was attend a 3 day Database Lifecycle Management (DLM) training.
If you’re into DevOps, Continuous Integration (CI) , Continuous Delivery or Deployment (CD) or you’re just automating as much as possible, then it’s very likely you’ll run into some challenges regarding your databases.

For most people, overcoming these challenges cost a lot of time.
But even before you can spend a lot of time overcoming your challenges, you’ll notice that there are a ton of tools out there that can help you.
So you’ll first have to pick the tools you’re going to use and then you need to learn how to use them.

This brings us back to the training I got to attend thanks to my employer Ordina.
More specifically, they were 3 workshops lead by Alex Yates (blog | twitter) from DLM Consultants (website | twitter).
In total they covered the 3 different main parts of the Database Lifecycle Management process.

• Database Source Control
• Database Continuous Integration
• Database Release Management

Read on for my experience with these full-day online workshops.

Generic vs product specific training

Before we continue, I’d like to point out that I was very skeptical about this training at first.
In general I’m not a fan of product specific training, especially not for a broad topic such as DLM.
You always risk just getting a sales person in front of you that wants to rant on about how great their product is.
If you’re unlucky you get comparisons to the leading competing products that apparently are the worst in the world.

Since these workshops are part of Redgate’s training program you can imagine my fear before entering them.
I think most people in the community know Redgate as a positive company that’s very active in the SQL Server Community.
I also don’t think I’ve ever seen something bad written about them, either on a blog or just on twitter.

Luckily the training focused mainly on principles and use of common software.
Redgate’s DLM software did get it’s time in the spotlight, but the focus was on how it makes your process even easier.
Redgate’s tools extend the standard DLM software like source control and release management and make your life easy.

---

Online vs in-person training

Another concern I had before starting the workshop was the format.
These workshops were offered online. Not something I’m a big fan of since it tends to limit interaction and it takes a really great trainer and good program to bring a live full-day workshop to a good end.

At the start, Alex told everyone present that it was the first time he delivered these workshops online. I immediately thought everyone in the workshop as having taken part in the twisted movie “SAW”, having to undergo the cruel tortures of this online workshop.
To my surprise, there was none of that.

I actually enjoyed the workshop and just like in a regular workshop, there was time beforehand, in-between and afterwards for everyone for some smalltalk and topic related discussion.
The pace, the content, the interactivity, everything was at least as great as a regular workshop.
Just as in real life, sometimes some people get stuck at a certain part of a lab and sometimes people finish a lot faster.
The first day it was clear that Alex hadn’t foreseen this and there were some uncomfortable moments. But the 2nd day, Alex had adjusted and solved this very elegantly with extra lab content and external reading material to go more in-depth.

If you aren’t convinced yet, you really need to experience these workshops for yourself.
But on to the content of the workshops!

---

Workshop 1: Database Source Control

Instead of skipping the workshops with content I already had experience with, I opted to attend all 3 days.
So we arrive at database source control.
Putting your code in source control is something you hopefully already do.
If you didn’t already, think of it in this way: Source control should be the source of all your deployments.

How you do it, either model driven or change-script driven, is up to you. As long as you version the hell out of that database, your dba or database developer is probably fine with your method.

But most people don’t put their database code in source control yet. So in his workshop, Alex provides you with the basics and then through exercises works you up to a point where you’re very comfortable with versioning a database.

And of course, you learn how Redgate’s tools, SQL Source Control in this case, can assist you in developing and versioning your database.
If you ask me, SQL Source Control is a great product. It proved very easy and intuitive to use and it would’ve made my life a lot easier in many cases. So I’d love to use it every day.

Except, I don’t use it, I almost always develop my database in SSDT. Mainly because I don’t own any budgets to buy tools but also because customers already work in a certain way before I arrive. As a consultant I adapt to the customer. When and where possible I suggest improvements that can actually be adopted to help them forward.

---

Workshop 2: Database Continuous Integration

In the 2nd workshop of the series, you learn what Continuous integration (CI) for databases is and how you can practice it. To oversimplify, CI is basically an extension of your source control system. From the source code (aka, the SQL code that creates tables etc), the CI Server (or build server) takes all your code – and hopes – and “builds” it into a working database.
At least when you’re lucky, because you can imagine all sorts of different problems that pop up.
Your code doesn’t always run correctly at first try, someone else already made a change and your changes don’t play well with those, etc…

For most people, this still is a manual process that has a lot of trial and error. Code some stuff and put it in source control. If you’re lucky, your next step isn’t deploying the loose scripts but you package all the code in something that you can deploy more easily.

If you’re really lucky you have some sort of testing of your SQL code in there as well. But if you’re like most people, you’re not lucky at all.

These steps, from putting all the code into a deployable package up to testing it, are something that a build server automates for you. Of course you need to do the coding the precedes the automation.
And this workshop teaches you how to do it all with common tools like Team City and tSQLt.
The format again, was the same as the first workshop. A guided lab experience with clear and concise explanation throughout.

Apart of the common tools, of course this workshop also included coverage of Redgate tools. In this case, DLM Automation was showcased as an excellent extension of your existing CI Server and build processes. And although there can be a lot of use for it, you can succeed without it. In my eyes, the biggest bonus is that you don’t have to develop any of these solutions yourself and can use the extensive experience of the people at Redgate.

---

Workshop 3: Database Release Management

The 3rd and last installment of the workshops covered Database Release Management. Or in other words, how you can automate deployments from the CI Server to the different DTAP environments and still include all the different checks, green lights, reporting and everything else that you want. Among other things you learn to work with Octopus Deploy and PowerShell.

At the end of this workshop it becomes very clear to you that you now have all the tools that you need to start automatically delivering code up to or even including to production environments in a very controlled method. But you don’t just learn to deploy code, you learn to create your own releases with Team City.

You might not know it yet, but creating releases, just like everything, can be set up in a very simple way. Just automatically straight through the DTAP environments. But you can also create advanced releases, where you have D-T-A and perhaps P environments in the development network segment and separate (D)-T-A-P  environments in the production network segment.
Or you can deploy only certain databases or block deployments based on OK’s from management or testers or based on the result of several parallel environments.
Basically, if you can dream the scenario, you can probably set it up.

Deploying through a release management tool allows you to do all kinds of reporting that you couldn’t do before. (Deployment duration, audit trails, number of errors and in what parts of the deployment process, …)

Of course Redgate has tools to make this part of DLM easier as well. And in this part of the DLM cycle they provided a lot of value.
In my opinion, if you’re not yet doing anything described here, the value you’ll get from Redgate at the start of your DLM journey will have a much greater impact on the way you work and the costs you’ll save compared to the latter parts.

Having said that, I am a huge fan of the free DLM dashboard, which also gets covered in the workshops.

---

Summary

Overall, I would certainly recommend you to attend all 3 workshops by Alex Yates (blog | twitter) who’s delivering them as part of the services of his new company DLM Consultants (website | twitter).
If you’ve made it this far, it’s interesting to know that, although Alex used to work for Redgate and he’s transparent about it, at no moment did he feel like just another sales guy trying to push a product.

Throughout the workshops, you’ll learn

• About all good and best practices related to DLM
• How to implement and work with all the standard DLM tools that basically becoming industry standards
• You learn about the extra value you could get out of these tools with the additions made by Redgate’s software

In the future, you can certainly expect more content on the topic of “Database DevOps” or “Database Continuous Delivery” or however you want to call it.

As always, if you have questions or there are things you want me to blog about or clarify, you can contact me in the comments, on twitter or other social media.