I've been traveling in Europe this week, partially for holiday and partially for work. It's been a nice break, and it's always interesting to experience the world in different places, away from the United States where I've spent most of my life. I get to come often, and I enjoy the experience, but I'm sometimes annoyed.

For example, I often find service at restaurants to be very different in Europe, and somewhat annoying as well. I worked in restaurants for many years and learned to be attentive to my customers, checking on them and being ready to provide more food and drink or present the bill in a timely manner. I know European customers prefer a more hands off approach and will call a server over when they want something or are ready to pay. The servicing model isn't better or worse, just different.

I thought about this when I saw a new Cumulative Update for SQL Server was released this week: CU #8 for SQL Server 2022 came out. As I was updating the build list, I saw the last few updates were August and July, which seemed like the proper pace. The servicing model from Microsoft is an update every month for the first year of a new release.

However, as I dug deeper, it appears they haven't quite met that target. The RTM was in November, but there wasn't a CU until February (along with a security update). Then we had updates in March and April, but nothing in May. Two in June, which I assume the first of which was a delayed May update. Since then, we've had monthly updates.

I can understand the delays, as software development isn't always clean. Perhaps tackling some patch in May didn't go smoothly in test and there was a delay in ensuring some bug was fixed. However, I'd hope that with an embracing of DevOps, Microsoft would be able to release some update around 15 May and if needed, release another one on 2 June. The goal is repeatable, reliable software deployments, with releases, or at least deployments, being an everyday occurrence, not a big event. Certainly patch releases for large customer bases still require some coordination for publication, documentation updates, etc., but this should still be easy to add in an extra release if necessary.

My approach hasn't been to update as soon as releases are available. Instead, I've typically lagged by one or two releases, depending on workload. I don't want to have breakage, but I want to keep somewhat current. I have found most of these patches are non-issues, but once in awhile that's not the case, and I don't want to have to unwind a patch from my environments. Perhaps if I used containers more, I'd feel differently, but for other instances, I want to ensure no one else encounters major issues before I install something.

For the software I've built and maintained, especially inside a company, I do think that a regular servicing model is a good idea. Many of the customers I work with release changes to their database every week, with a regular expectation set with their customers that their application might change.  They sometimes release application changes more often, but a weekly cadence for databases seems to provide a good balance of meeting the needs of software developers and providing some amount of stability to ensure that customers aren't impacted by too many changes at once.

If you build and manage software, it might be worth considering some sort of regular cadence of deployments. I often find that many applications don't need to chance the database every week, but there are index changes or other tuning enhancements that DBAs might want to ensure are deployed in lieu of schema alterations. There might be patches from Microsoft or even some cleanup (add/removing FKs, archiving data, etc.) that could be made when there aren't other changes needed.

I am a big fan of DevOps in general, with repeatable, reliable deployments that are easy to make. I like regular deployments, after good modeling, testing, and review by multiple people that ensure we are constantly delivering value to customers, even if some of this isn't obvious. I'm also a fan of rolling forward when we find mistakes, because we will. Having a smooth deployment process for my servicing model means I can meet those goals.