Database Change Control, Part 5
We have spent a good amount of time discussing database change control. But why should we care? Why not just let people manually deploy things to SQL?
Why would we want database change control?
- Repeatability
- Trackability
- Maintainability
- Tying application code to the database code
Repeatability
Ideally, we want the ability to rebuild our environment quickly. We want a mature 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 what changes to a system. We need to track the changes to our systems. Sometimes the pressure to track who is doing what is pushed upon us by regulations, but I think it is actually a good thing.
Source control is essential for maintainability. Without the ability to track who is making changes and what changes are being made, we are severely hamstrung in our ability to maintain a system. We need to track all that is occurring with that solution.
Maintainability
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 role fixes out faster (which typically makes for happier customers). You can also create problems faster (which never makes customers happier). The desire to make random changes is very appealing, but we have to temper that with a dose of reality. We like to push all of our changes through a process for a reason. Quality software can’t be achieved with any 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 quality process helps to keep customers happy by delivering quality.
Tying Application Code to the Database Code
Some will say that the database team already has a way to roll out changes faster. 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 probably need to update our model.
Now some people just don’t want all that process. I think that is a great attitude. We want to minimize our processes as much as possible. We want to push for leaner ways to deliver software, but we do need some minimums. Database change control for me is in the bucket of minimums. There are some things we can sometimes do; database change control isn’t one of them.
Many things are essential for software delivery. We can make a long list of things that would be essential, and database change control would be one of them.
