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.
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.