give IT a try


When Database Source Control Goes Bad 翻訳 Part2

The Impedance Mismatch


Why aren’t Database DML and DDL subject to the same level of source-control as the application? Why don’t developers think about databases the same way that they think about source-code?


The most obvious reason is that database changes are fundamentally different in many ways. While source-code is usually just a collection of files that are recompiled, versioned, and released at any given time, databases are much more temperamental. They have existing data, and they have history. Sure, source-code has history, which you can review for reference purposes, but in databases the historical lineage of a table is actually very important. In C#, if you added a field to a class, and then a week later someone else changed the type, and then a month later someone else changed the name, it usually doesn’t really matter too much when or in what order those changes happened, all that matters is the current state of the code and that everything builds together and works in its latest state. However, if you were to do the same thing to a new field in a table, it definitely makes a difference, because there are data implications at every step of the way. This alone scares a lot of developers away from maintaining the database.


To many developers, there is something fundamentally uncontrollable about databases. They don’t fit into the safe model that we’re use to. Managing those changes is definitely introduces new challenge, and many developers just don’t want to be bothered. Another major reason for the difference is just cultural. Developers want the database to work well, and they may even like tinkering around with some stored procedures from time to time, but at the end of the day they like to be able to wash their hands of anything that slightly resembles being a “DBA”.


Developers often see themselves as the general of a utilitarian army of code that they build and train and then order off to carry out their mission, and they usually won’t hesitate to trash it all and replace it if it proves itself unable to complete the mission. DBAs on the other hand are used to dealing with a gentle lion that could easily lose it temper and kill everyone in the room if it’s not treated with kindness and respect. Developers often have the option to wipe the slate clean and start over, and usually want to, especially when they are dealing with someone else’s code. DBAs however are stuck with the original version and they need to keep it alive and make it work until the point that the data can be migrated to a better system, and we all secretly know that is never going to happen.


Silently Killing Software Quality


Let’s take a fictitious example: At some internal IT department, a group of developers is toiling away on a set of dull yet fabulously ‘enterprise-y’ software that no more than five people will ever use. Jimmy checks his code changes into his company’s version-control system of choice, where it is automatically held at the gates until it is code-reviewed by a senior developer, and then it is checked into the team’s current release branch. Meanwhile the continuous-integration build server will download, compile, package, and unit-test the code to make sure that Jimmy hasn’t broken anything, and that nobody else’s changes broke Jimmy. The package code is then migrated through an integration environment, QA environment, UAT environment, and staging environment on its way to production. All the while, as the changes are validated from one environment to another, version numbers are automatically assigned to allow anyone to trace back the exact revision for a given build, and the corresponding code changes slowly work their way towards the code-release Promised Land, the Main Trunk. Those branches can get pretty damned complicated, even when everything is going smoothly, which it never does.


Hopefully this is a process that Jimmy’s company evolved out of mixture of necessity and forethought over the years. The other, less attractive, and far more common scenario is that the company hired an astronaut trapped in a developer’s body, bored with his work and not bound by any sense of urgency, who assured the company that he was going to implement a lot of big complicated processes because that’s just want professional companies do.


In the end, a whole lot of people are paying a whole lot of attention to managing the source code. Hopefully at your company, you are paying attention to this to.