The DORA organization is constantly researching how to better produce software at any organization. This is similar to work done by Carnegie Mellon Software Engineering Institute many years ago. Both groups are trying to determine what things help engineers work better and produce high-quality software.
On the DORA site, there is a database change management page, where they recommend approaches to managing database schemas. The main thing they talk about is treating all schema changes as migrations, which is something some people do. However, many teams also like a desired-state-configuration approach, where they just deploy all the changes from dev (or QA) to prod in a state-based flow. Both can work, but I do think as software matures (and becomes legacy), migrations are preferred. The article lists lots of frameworks in different languages. Flyway is among them, which is the product on which I work and sell at Redgate. If you haven’t looked at a migrations framework, I’d recommend you do so. They do really give you a tremendous amount of control and flexibility. There are trade-offs, so I’m not blindly recommending this approach, but it’s worth educating yourself on how migrations frameworks work.
The other thing they recommend is using a zero-downtime change approach. They list a few strategies that you can use make changes without impacting clients. None of these are hard, but they require a little coordination with application developers, as well as some patience in splitting changes across multiple deployments. They also require good coding practices, so many of us have a few habits to unlearn.
DORA does also recommend considering a NoSQL database since you don’t have downtime from schema changes, but my view is that you’re likely making trade-offs that aren’t worth in. If you read that paragraph in the article, my guess is many application developers read everything but the last sentence, or they dismiss that last sentence. Then they just start developing against a NoSQL database platform and expect it to magically be better. It might be, but it might not work as well.
The one thing I wish they had a better answer for was how to measure our work as database developers. This section doesn’t give you any concrete things to measure, just some suggestions, which are often hard for people to implement in their environment. Most of us don’t have salary or time numbers for others, and need more help in trying to determine how to measure changes. Maybe the one good measurement to aim for is 100% of database changes made by automation, rather than manual execution.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
