Database Change Control – Executive Summary
We have spent a good amount of time discussing database change control. Why? Why should we care? Why not just let people manually deploy things to SQL?
The answer is four-fold:
- Repeatability
- Trackability
- Maintainability
- Ties application code to the database code
Repeatability
Ideally, we want the ability to quickly rebuild our environments. We want a mature and continuous integration / deployment platform that is continually running our scripts. The more they are running, the more confident we can be in their outcome.
Trackability
We want to know who is making changes to our systems and track those changes. Sometimes the pressure to track who is doing what is pushed upon us by regulations, but I think it is actually a good thing.
Maintainability
Source control is essential for maintainability. Without the ability to trace who is making changes, and what changes are being made, we are severely hamstrung. If we are expected to maintain a solution, we need to track what is going on with it.
Ties Application Code to Database Code
Databases rarely exist in isolation from some application code. And applications often exist with a database. Keeping those two separate from a source code perspective just means that keeping them in sync will forever be painful. Since they need to evolve together, keeping them in a single source control system makes a lot of sense.
Arguments Against
Some of the most common arguments against database change control are:
- I want to be able to make random changes on production
- I don’t want all that process
- Our database team already has a way to manage their scripts
The desire to make random changes is appealing. You can roll fixes out faster, and that makes for happier customers. But you can also make problems faster, which won’t make customers happier.
We have to temper our desire for quick turnarounds with a dose of reality. We run all of our changes through a process for a reason. We like to use a layered approach to quality. Quality software can’t be achieved with a single technique; we have to layer many approaches together to achieve quality software. Quality starts with our system design, moves on to our coding practices, is reviewed with code reviews, and is tested by a quality assurance expert. That process helps to keep customers happy by delivering quality.
But some people just don’t want all that process, and I think that is a great attitude. We should want to minimize our overhead and end up with leaner ways to deliver software, but we do need some minimums. And for me, database change control is one of those minimums. There are some things we can “sometimes do”, but database change control isn’t one of them.
Some will say that the database team already has a way to manage change control. First, I think the application tier and the database tier need to be strongly linked. We need to keep these things in sync. If we add a column to a database table, we likely will need to update our model.
Closing Thoughts
There are many things that are essential for software delivery. We can make a long list of things that would be essential, and database change control would be near the top of the list.
