Voice of the DBA

I’ve spent quite a bit of my career as a DBA/sysadmin/Operations person. However, I’ve had my share of development positions as well. As I work with customers who look to mature their database development to be more like other software development, I’ve noticed that PRs sometimes don’t get handled as smoothly as we might like. In some sense, they are like help desk trouble tickets that never get closed.

One of the first things I caution people about is specifying specific reviewers, especially DBAs. There are often DBAs who are the gatekeepers for code, but if we require them to be the only ones to review code before a CI or test process, we really slow things down. This often happens in smaller environments where one DBA wants to avoid anything impacting their job. They want to review everything before it commits.

That’s a bottleneck that will slow you down. Train others, agree on the types of changes that can be approved by multiple people, and learn to handle the problems, not try to prevent them all.

Another issue is that lots of people are often overloaded with their workload. It’s a big reason people want to adopt a more DevOps view of the world and try to reduce time spent on handoffs and the friction in the process. However, until things get better, they can get worse. PRs can languish when people are overloaded. Like the first item above, choosing specific people for a review can make this worse, but even if you have a group to review requests, you might find everyone expects someone else to look at the request.

There’s no good solution here, but establishing a rota for reviews or setting aside time in a calendar can help. There will still be cases when you need immediate review, so there needs to be some escalation process, at least until everyone acts like a team and tries to ensure the others aren’t waiting a long time for their work to be reviewed.

The last thing about PRs that I find similar to trouble tickets is the content. I have had tickets where I have MB of multiple text logs, and at the same time, a bare-bones description like “this doesn’t work.” PRs can be the same way, with too many changes and too sparse a description. Your commit message(s) might not be good for a PR. Use the PR space to give the reviewer some context. Try to limit the changes, though I know sometimes this can be hard. As much as possible, focus on making non-breaking changes in code, tying schema alterations to feature flags so that you can merge in smaller bits of work without breaking the system.

Learning to create a more mature database development process takes work. Software developers have gotten better, though they still face some struggles in managing their PRs. Learn from them, ask questions, take advice, and above all, work as a team.

Steve Jones

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

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