Upgrade Woes, Take 2

I've been once again been put into a tough spot by our upgrade policy. Just recently I had to upgrade a client to a build not even a few weeks old in order to give them a bug fix. In case you're wondering why we didn't just patch the branch that they were on, it's because we don't generally do this for branches more than one or two months old. I think this is silly, considering that other ISVs will support a branch with patches and fixes for months or even years. I can't think of another software product released on such an insane build schedule as ours.

Anyway..

Today the customer called in (for the 4th time this week) with another interesting bug. After spending about an hour tweaking a stored proc thinking it was a change I had made two days ago, another guy came and told me that it's likely a code change he included in a couple of builds. It comes as a *complete* surprise that there might be bugs in a new, untested build. The fix, of course, is to put them on a newer build. This build has had even fewer minutes of testing. Any guesses on where this is going?

Upgrade Woes

First blog post! My goal is to make this an informative and occasionally amusing account of the perils and pitfalls of web and database programming. I work at a small software company where I do a bit of everything, so what better source of inspiration is there?

Just recently, a client of ours requested a software update to address a certain issue. The update went smoothly enough, with the biggest step being the update to their database. We have a utility that automates a Red Gate compare and updates based on differences. Usually this works smoothly and requires only a bit of coaxing once in a while. The only problem is that while the update seemed normal, it isn't smart enough to notice changes in the old version so it overwrites any existing database object with the new version.

Soon, the "bug reports" started rolling in...

To make a long story short, I can't help but wonder if there is a better way to extend a data layer with customer-specific changes. We already have a mechanism which which we extend a few key stored procedures, but it's only a 'if exists run XYZ' call to an extender proc. These extender procedures are ignored during an update and are thus safe from overwriting, but they are of somewhat limited value for coupling in additional functionality. I have begun looking at borrowing a few pages from the OO playbook for this problem. Specifically, I think some good'ole polymorphism would allow customers to extend our product in a safe way.