Tag: DevOps

We had a Simple Talks podcast recently where we discussed roll forward vs roll back. You can watch the episode and listen to our thoughts, but one interesting place was when we talked about deployments. Grant mentioned that he deployed from version control/source control at a previous employer. I asked him whether he did that for every system.

His response: “Well, …”

He admitted that most, but not all, databases came from a controlled source. There were some systems that had a more ad hoc change process. I wonder how many of you have consistent processes throughout your organization. I suspect not many of you do, especially if an organization isn’t small. Often, different groups and applications are in a constant state of flux, with lots of different processes and protocols.

Some groups are more mature and have stable staff who expect to deploy changes in a certain way. This might be on a known cadence, with documents or processes in place already. Others applications might have been developed quickly; perhaps they are newer and use more automation to deploy changes. Some might even use things like packages from an ORM or a vendor that takes control of database changes away from anyone managing the database. Does anyone deal with Spring Boot and very optimistic developers?

I wonder how many of you have a consistent process for promoting database code to production across all your teams. Maybe 80% is a better metric, as this accounts for those groups severely limited by legacy technology or those that might be experimenting with new ways of working.

Even those companies that have platform engineering groups in place to ease the flow for both developers and operations often aren’t consistent throughout the organization. Often, getting everyone to adopt a standard is hard and takes time.

That might be the biggest challenge with standardizing database deployments: time. Organizations grow and change, new technologies come, and by the time we think we’ve gotten everyone to agree to change, who everyone is has changed. We have someone or something new, and we’re forever chasing standardization. Even when we might have a great DevOps process or a platform engineering team for software, we don’t do this for databases.

I believe having a consistent, standardized process is a worthwhile goal, but one where 80% success is probably good enough in most organizations. If you can get most teams to follow the same process, you’ll increase efficiencies and ensure a better software development life cycle.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

I have the opportunity to work with a variety of customers on their database systems, often with the focus on how they can build and deploy changes to their databases. Often, they have a process around how and when they make changes. Some have maintenance windows, though often these are approved times for changes rather than a true window during which a system is shut down.

I ran into a customer recently who scheduled a system shutdown for their deployments. This was a surprise to me in 2026, as I thought most people would have learned to deploy changes to live systems. However, I know that many teams make changes that would render portions of the database inaccessible for a period of time, so maybe that’s not true. Maybe they just make changes and deal with the impact on clients.

I wanted to ask this question today: Do you shut down your system completely for a deployment? Not all systems, but the one you’re patching and possibly a few related ones, while preventing client access?

Or do you have to make changes while the system is still in use?

A lot of DevOps analogies revolve around the idea of cars and performing maintenance or improving them. One that I like is learning to replace all the parts of the car while it’s still running and in use. That can be hard in the real world, but we can often find ways to do this in software, including with databases. A little creativity can go a long way.

I love watching the evolution of Formula 1 Pit Stops as a way of visualizing the problem. This video is kind of amazing, but it shows the power of thinking about a problem and finding ways to improve it. In the 50s, pit stops could take 45-60 seconds or longer. If you look at the video, in 1990, they dropped this to less than 9 seconds. That seems amazing, but the power of continuous improvement shows this dropping to 7s in 2000. In 2010, 4 seconds. Then in 2020, 1.82 seconds for 4 tires changed.

This is still a full shutdown, albeit a few short one.

I constantly deal with people who think that they cannot find a way to make deployments easier, faster, or less impactful. I know that car racing teams used to feel that way about their pit stops. Once they tried to creatively work on their challenges, they found solutions that are truly amazing. Using new ideas and tools, they reached speeds no one could have imagined a decade ago.

I bet many of you can do the same thing to your databases with an open mind and a little tooling.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

That last one only comes if you use testing and try to ensure your code is well-written. It’s easy to just use DevOps to throw out more poorly written code that doesn’t perform well.

Recently, I went to a presentation on Fabric CI/CD, looking to see if I could learn something about how you might handle Fabric in a DevOps software development flow. What I came away with was the idea that DevOps is really just DevOps. In this case, Azure DevOps was being used to orchestrate the CI/CD flow, and the pipeline looked the same way as one I had set up for a relational database.

There are differences, such as the need to have multiple Fabric workspaces and a need to understand how the code is stored and managed in Git, but the idea is the same. We use a build step to verify that any code changes can be successfully compiled and that those changes can be deployed to a new location. A workspace instead of a database, which means the automation doing the work is slightly different, but the process is the same.

Testing? You want tests to verify that the code does what is expected. A lot of people skip testing with data, but I’d argue it’s as important in Power BI or SQL Server as it is in C#. We ought to include tests, not because we don’t know how to write code, but because others might maintain/extend/refactor our code, and we want their changes to pass our tests. Again, the details are different, but including a step to run tests is still there. The same idea.

Using a flow to approve and deploy changes between environments? This is no different, and having an automated process reduces the effort, time, and risk of mistakes. This is again the same, though the details are different specifics because the automation is different. Deploying a semantic model is different than pushing out a new .exe or running database changes, but the idea of an automated deployment is the same.

We, as an industry, have learned over time how to better move code through a software development life cycle. The ideas work for data-based projects as well, and we ought to be learning and adapting these to ensure we can be just as agile as application software developers.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.