Change Management

Hurry up and wait.

Hurry up and wait.

In a couple of the large enterprises I’ve worked in, that might have been the IT motto. It seemed as though the internal developers were always under pressure to get applications finished as soon as possible. However we often found that when applications were finished, there would be a delay in deploying the new code to the production servers, usually because of a strict change control process that required documentation and testing of the changes on related systems. In many smaller companies I’ve worked in, we had no change control process at all and could deploy updates at any time.

I’m not sure which of those two systems I prefer. In general, I prefer to have some change management process to ensure that I can easily determine what changes were made at any time. However I’ve found that any change management quickly becomes a bottleneck devoid of common sense and full of bureaucratic nonsense. This Friday, I decided to ask a question about change management, but not about your opinion of whether it’s good or not. The question this week is:

Do you follow a change control process 90+% of the time?

By this question, I mean is change control a habit, an ingrained sense of the way you work and deploy updates to a live environment. I’m not asking if you have a formal process, if it’s a team process, or anything about the details, but rather do you actually follow some methodology to track and manage changes?

I’d like to think most of us would, if for no other reason than to answer the common “what changed?” question that always comes up when something breaks. However I’m curious to see the results.

Steve Jones

The Voice of the DBA Podcasts

We are still having hosting issues with the podcasts. We hope to resolve this and be back to releasing the podcast versions of the editorial next week.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.

1 Response to Change Management

  1. weowls says:

    Answer: Yes.

    This is heavily on my mind at the moment, as I’m in a small “informal” shop and implementing DB change control *THIS WEEK*. I live and die by change control – even small changes to stored procedures in insignificant databases that I myself make, I follow my own process. I have to, or no one else will.

    Further commentary: You’re right in that IT shops tend to go to extremes, and neither All nor Nothing works well for what you’re actually trying to achieve. A big shop that uses lots of documents and teams and outdated procedures bogs down development progress; a small shop that has nothing is in a constant state of siloed information and panicked firefighting.

    My goal for change control (in a small shop) is: Get eyes on code, pre-deployment, for sustainability, quality, and information sharing. With any luck, change control is an expected part of the process, so there’s a little time to make and test necessary changes before production.


Comments are closed.