Practical Database Change Management (Part 1)

Step 4: Coordinating the release

As a matter of fact, we classify our releases into one of these two categories:

The difference between them is what type of objects are touched and changed during the release.

A major release is defined as a release that changes existing table structures and/or existing data. A minor release is every release that is not a major release. This classification has an impact on when the release can be performed. We do major releases out of business hours. Usually in the evening. Minor releases are performed during local business hours. Why during business hours? Because of the global user base we have there is never a good time for a release, so we decided that the most acceptable time is that time where all involved parties at the location implementing the release are available on site. That way any issue arising from a minor release can be reversed or resolved quickly. It is obvious that major releases require more coordination between DBA’s, support, and business users than minor releases.

Major released needs to be planned ahead. First thing we do is talk to the DBA’s to find a time slot for the release that we then propose to the business users. This usually happens by means of a first notification mail one week before the planned release date. While there is never a good time for a “downtime” of a system, at least such a notification mail involves the business users in the planning and gives them the chance to prepare themselves accordingly prior to the release. If no one objected to the release date in the first notification mail we send out a second notification mail 1 or 2 days before the actual release and a final mail on the release day.

What does the notification mail contain?

First, keep in mind that the primary audience of this mail is business. So keep your use of technical lingo at a bare minimum. Otherwise you might end up opening a can of worms by introducing misunderstandings or even misgivings on the riskiness of the release on behalf of the business users just because they don’t fully understand what you are really talking about.

If needed, a separate email for your “power” user can help pacify “normal” users.

Secondly, if the business users needs to take some action (such as restarting some calculation spreadsheet or the like) state that in the mail. Though you can be sure, that most business users won’t read it anyway, at least you have covered yourself.

Thirdly, give information about whom to contact when things are not “working as expected”. This might be the support hotline number or a mail address.

Fortunately our systems have reached a level of stability and maturity that make major releases quite rare. At the time of writing this, I’m still undecided whether to write an article or not which will describe the chaos and desctruction caused by my last major release. 🙂

Minor releases on the contrary occur quite frequently as we tend to aim for a release every 2 or 3 weeks. The business user is not that heavily involved in such a release. The main actors here are the DBA’s and the support team who do the post change testing. Whether we send out a mail to our business users informing them of the release depends on the changes done with it. If the release fixes some issues the users face or introduces new functionalities, we send out a mail. If the release is “just” a maintenance release without any user effect, we don’t send out a mail.

Pages: 1 2 3


No comments yet... Be the first to leave a reply!