April 2, 2025 at 12:00 am
Comments posted to this topic are about the item Database DevOps Metrics
April 3, 2025 at 7:41 am
I've found that smaller releases at more frequent intervals is more reliable and is far easier to co-ordinate with other initiatives that are going on within an organisation.
In the old days there would be a big release, perhaps monthly or a longer interval. If things went wrong deciding whether to roll back or forward fix was a big decision. Lots of change in a single release often obscured the root cause of the failure when we were under immense pressure to make a rapid decision.
We used to rehearse deployments and rollbacks so failures were rare but not unheard of. The thing is, if a rehearsed deployment can go wrong, so can a rehearsed rollback.
One metric that I think is missing is a measure of the benefit of what is delivered. Did it reduce costs and/or increase revenue and/or increase engagement with customers that is likely to have a financial benefit. Heaven forbid, the opposite. I'm not sure that such a measure is part of DevOps though collection of OpenTelemetry statistics can be useful for tracking running costs in the cloud.
We know the pitfalls of reading SQL Server metrics in isolation. Taking the DORA metrics isolated from business impacts also has pitfalls.
April 3, 2025 at 8:04 am
I think using deployment frequency as a metric is a bit like measuring programmer productivity by counting key strokes. You'd need a means of subtracting deployments that were necessary to fix something introduced by a previous deployment, ie. you'd need to categorise deployments as "good" or "bad" in some way to make the metric meaningful.
April 6, 2025 at 2:52 pm
I didn't see this issue until the following Sunday. This is an important topic to me. I've been interested in DevOps for many years and have been somewhat involved in DevOps because I am one of our GitHub administrators. However, change takes a long time to happen. I work in State Government, so the phrase "If it ain't broke, don't fix it" morphs into, "Never change anything for years or decades until it breaks beyond repair". And trust me, I have seen things break to the point that no reboot, replace the server, etc. will fix it so it must be updated, to many people's extreme displeasure.
Another cultural restriction involves deploying to production during my state's legislative session. Under NO CIRCUMSTANCES may anything be deployed to production during the legislative session. If that's months long, so be it.
Another cultural restriction is our Change Management Board (CMB). They have godlike power. And as has been identified by DORA reports in the past, the CMB is one of the greatest impediment's to becoming a more performant organization. Every change, no matter how small, must be brought before the CMB, then fully explained to members of the board who are far removed from the situation, before approval is given.
I'll finish by saying that it took me, arguing for 6 years, to get us off an old on-prem TFS server that was long out of support, to GitHub, due to cultural restrictions. That experience has shown me that many people where I work have hidden reasons for keeping the status quo in place. Some day they may upgrade servers or databases quicker than once every 15 or more years or allow less important decisions to someone other than the CMB, but I don't think I have the patience anymore to try changing this culture.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy