Database Schema Ownership
It’s been a while since my last article. Now, feeling fresh and energetic, I want to highlight a problem that has been bothering me for quite some time. As a bonus, I have created a solution right away that you can leverage in your projects.
I have over a decade of experience working in big companies with hundreds of contributors to the same projects daily. Apart from the many consequences of such workflow, there is one that I want to discuss today.
Let’s say we have Project X with a database attached. We store information about our users in this database. From a business perspective, team A owns the code about users, while other teams have their own domains. Now, assume another team needs to extend users’ data. Usually, the team needs to contact team A and ask for their opinion on the subject because they own the user’s domain. Unfortunately, engineers can sometimes overlook such changes because of a lack of automation.
There is a nice feature from GitHub called GitHub Codeowners to manage the collaborative work of big teams. It basically helps you automatically assign particular teams to be owners of specific files in your project, so every time a file is changed, the team will be pinned to review the pull request.
Unfortunately, the same cannot be done on a per-line basis; therefore, in worlds like Ruby on Rails, where a single file represents the whole database schema (schema.rb or structure.sql), we cannot use such a feature.
But what if we split the file into multiple files per table and assign responsive teams to those files? This way, any change applied to a schema would be appropriately reflected, and the right team would be asked about leaving a review for a pull request.
This is where DatabaseSchemaOwnership comes in handy. So far, it only works with ActiveRecord, but it can be extended easily. Check the repo for more dive-in examples, and I hope you will find it helpful.
