June 3, 2019 at 12:00 am
Comments posted to this topic are about the item The Change Failure Rate
June 4, 2019 at 12:13 am
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
April 8, 2022 at 9:24 am
This was removed by the editor as SPAM
April 9, 2022 at 4:46 am
This was removed by the editor as SPAM
April 9, 2022 at 4:47 am
This was removed by the editor as SPAM
February 17, 2025 at 8:35 am
One of the downsides of a Polyglot DB world is that having worked out how to do a large deployment reliably for a particular DB platform you end up having to work out how to do it for all the other DB platforms you run.
It is hard enough getting there the 1st time. At least you have the pattern as a guide for the other platforms and once you get there then you have a granite bedrock under your processes. It is a lot of effort to support polyglot DBs and I am dubious if it is worth it for most companies.
There are a few things to work towards in order to get to a low change failure rate.
You need all DB artefacts under source control.
A mandatory and bomb proof deployment pipeline. If you cannot deploy using the deployment pipeline then the pipeline is not fit for purpose. The pipeline deploys directly from source control. In extreme cases there is break-glass access but the dust on it should be an inch thick. Its use really is for extremes.
Where possible developers, whether DB, App or other, should be able to rehearse deployment/rollback locally. That may not always be possible because platforms like BigQuery and Snowflake only run in the Cloud, but in many cases it is possible. Even with cloud only DBs with careful design it is possible to have separate DBs per developer.
If you have a local DB then you need a local version of the deployment/rollback mechanism. Again, you need careful design to avoid the old "it works fine on my machine".
If you are developing locally you need to be able to do the equivalent of git pull and git merge to prevent drift in the development DBs. I'd be tempted to make the development DBs short-lived. The capability to teardown and rebuild environments before production is highly desirable. Again, this prevents drift.
You need mechanical and automated testing both in your pipeline and the same mechanism available locally.
No system is 100% reliable but getting to 95%+ completely alters the landscape. So, the most important thing to add to the list is continuous improvement.
February 18, 2025 at 2:56 pm
Completely agree, David. This was one reason I pushed for Flyway to underpin all deployments at Redgate. We need a known, reliable way across multiple platforms. Otherwise it doesn't become an efficient process in an org.
I also love that with VCS integration, we can always have emergency PRs that run adhoc scripts from DBAs through the same pipeline to limit the need to ever break glass.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply