No tour this year, but Redgate does have a few DevOps events scheduled. I’m hoping for more, and the first one for me this year is Atlanta. You can register for the DevOps Day Atlanta Workshop on May 15, just a few weeks away.
I’ll be there to set the stage and give a high level view of how Redgate approaches better database code management and deployment with Flyway. We’ll also have a whiteboarding session if you have questions to solve some architectural challenges.
If you can make it, please register today and come enjoy a day with us.
One of the challenges in software development is coordinating database and application changes when one depends on the other. I find many software development teams struggle with this, especially in today’s environments when no one wants to take a system offline. While some companies can stage and manage deployments, many of us find our systems need to keep running 24×7 with minimal outages (if any).
Lots of you work in environments where your software is changing on a regular basis. Plenty of you will either be developing those changes, or managing the systems to which those changes are deployed. You likely will be coordinating with other people (in either case) to deploy a software artifact (C#, Java, Python, etc.) and a set of database changes in order for your clients to use whatever new functionality is being delivered.
My question today is do you deploy database changes first or application changes first. Certainly you can deploy both on the same day or in the same pipeline. However, even if you use parallel pipelines, likely one side will finish first, and you likely have some preferred order for deployments. My question today is what order do you prefer (or is mandated to you).
Maybe you don’t care. After all, with modern coding and feature flags, you can deploy either side first (front end or back end) and not disturb your clients. I’ve seen many successful deployments from organizations both ways. Some like letting application developers deploy their code with expected database changes hidden behind flags. Others want the database to get patched and the software changed later to use the database changes.
Lots of people want everything deployed at once, but if you assume that is the case, I hope you have downtime scheduled, as you can’t usually get everything deployed simultaneously.
I tend to prefer database first, with dark deployed changes that don’t affect the front end. Of course the front end needs to support these dark deployed changes, but that’s easy by just following good coding practices, which aren’t that hard.
Let me know today what you prefer and why. Or if you don’t care and can deploy in either order.
The DORA organization is dedicated to helping others build software better and faster, at a higher quality, and in a way that is more efficient. They continue to compile and publish the Accelerate State of DevOps report every year, which is a fascinating read.
As a part of the report, they have identified four key metrics that identify high performing organizations in terms of software. These are divided into two areas: throughput and stability. Throughput measures are change lead time and deployment frequency. Stability measures are the change fail percentage and failed deployment recovery time.
For a long time, as I chatted with various people doing database work, it seemed that most people deployed relatively infrequently. They might deploy a couple times a week for software changes, but database changes were often less than once a week. There have always been people moving faster or slower, but that felt like the pace for a majority of people. These days, in the 2024-2025 timeframe, many people seem to be able to deploy database changes every week, often multiple times a week.
Lots of people have moved to more throughput, with more frequent deployments and less change lead time. Most of us can’t get more work out of people, so if we deploy more often, their completed work gets released quicker. Those two metrics make some sense, and I think those are good measures, but not goals. What I find is that people often need to make changes quicker either to respond to changing needs of their organization or to fix bugs they’ve introduced. I wonder what the ratio is of the former to the latter? I suspect it might be less than one, if most of your deployments are fixing bugs. I don’t mind deploying software quicker, but the design, modeling, and testing can’t be shortened.
The stability metrics are often high for most people I speak with about deployments. I don’t see a lot of failures at deployment time as code usually compiles and deploys. It’s often a day (or week) later that someone notices the code doesn’t do what they expect. Is that a deployment failure? I think not. What’s the MTTR if it’s fixed an hour after being reported a day after the deployment? Is the MTTR an hour or a day plus an hour? I don’t know how these metrics apply to databases, especially if data gets mangled and has to be corrected manually over hours/days/weeks. Is that in the MTTR? Can you even track it?
Metrics are good ways to measure you progress or health, as long as the metric doesn’t become the goal. I’ve run into a lot of customers using these metrics to measure their development, and it does help most for a period of time. Whether this continues to help them improve often depends on whether they keep focusing on their goals of delivering better quality software faster, or they focus on the metrics.
I had to demo the Flyway Autopilot system recently and created a GitHub Actions runner as a part of that. This post documents how this went.
First, if you go to the settings in a repo and click the Actions area, you see a Runners item. Click that. Notice I have no runners.
In the upper right corner, I can click a button to create one.
This gives me the instructions to get a new one. Note, these are PowerShell commands, and the first command doesn’t quite work right. Still, this is what I need.
I opened a CMD window and stared running these. Note, I need to repeat the change directory.
Now start PowerShell as the next commands are PoSh ones. When I copy the next command, it starts downloading a zip file. As of this writing, this is a 600-ish MB file.
Once this is done, you can run the next commands, which unzip and configure this. For the config, I just hit enter as I don’t have multiple groups or tags, and I leave it named as my machine. I also don’t bother to run this as a service.
The last command runs the runner agent.
If I go back to the Runner screen in Settings, I see I have an idle agent set up.
And that’s it. If I pick one of my workflows in the Actions tab, I can run it and I’ll see the job started in my runner folder. Here are my actions with the Run workflow button on the right.
If I click this, I see the job start in the CLI.
If I get back to the Actions, I’ll see things in progress. As you can see, I was slow here.
That’s about it. Now I can run local automations in my repo that connect to things like local databases, which can be handy.
Video Walkthrough
I’ve got a video of this process if you want to watch it.
