| Upgrading, without an Upgrade | KEVIN RESCHENBERG
04-04-2005 |
Last week's discussion
was about scheduling patches. I mentioned that the "pick and choose"
approach can lead to problems. Here's an example of how one customer got
into and out of trouble. As I said last week, the solution in this
case was sort of a cheat. So here's the disclaimer: I'm not
recommending this approach! It's just something that happened,
once upon a time...
The environment: HRMS 8.3 with a moderate
amount of customization.
The situation: The client was implementing a new high-profile
module and needed the latest patches. These patches
required the installation to be at version 8.3 SP1. In the past,
some patches had been applied and others had not. Due
to some missed updates and misplaced documentation, the system was
essentially in an unknown state somewhere between
versions 8.3 and 8.3 SP1. Time was short; if the system was not
brought immediately to SP1, the installation and
customization of the new module would be stalled.
The options: An upgrade of some sort was required—fast.
The most obvious solution would have been to suspend
development on the new module, assemble an upgrade team, and perform
a standard upgrade to SP1. Quick estimates
of the time required, however, showed that the implementation
project would have been unacceptably delayed.
Another option involved finding all of the missing patches by
searching existing documentation, downloading all
updates, and analyzing the changes needed by comparing against
delivered and customized code. But the time required for
the research and analysis, and the risk of missing a patch,
made that option impractical as well. The lack of
time available forced us to find a different way.
The solution: After we had discussed the various options,
I suggested a different method. Reasoning that the objects in a service
pack would, on average, have a much higher probability of
impacting delivered code rather than customized code, I wondered whether
we could simply synchronize all objects with an SP1 version of DMO.
We would install an SP1 DMO, compare all objects,
and reconcile the differences. For the few delivered modifications
that impacted customization, we would merge
the code as usual. After analyzing and applying any applicable
Data Mover scripts and other manual steps
included with SP1, we would be at SP1 and could prove the
accuracy of this "upgrade" with compares.
We decided to start down this road to see if it would work.
Our first step was to do a full database compare
between the SP1 DMO and the current DMO. The project generated
by this compare contained over 14,000 objects (!), indicating
that there were that many differences in delivered objects
between the current patched DMO and SP1.
However, the next compare (between this project and the
current development environment) showed that,
as expected, a very small number of the differences
touched the existing customization. Instead of analyzing and moving all of
the existing customization, this method required us to merge
only a small portion of it. This reduced not only the
time and effort required, but also the associated risk.
In addition, we avoided moving data (with all the risk
that entails) and creating
additional environments.
We migrated the new delivered objects
into DMO and the development environment, merged the custom code,
and reconciled the differences. The few applicable scripts
were applied and the environment was released to the testing team.
The client already had an organized, well-documented test suite
that had been used for previous updates. These
tests were run smoothly.
The result: The entire project, from the initial
discussions through implementation, testing and migration to
production, took less than three weeks
and was completed with no significant issues. The module implementation
proceeded on schedule.
Again, not something I'd necessarily recommend. Also, this probably
would not work for a major release upgrade (recall that this was
a service pack upgrade).
|
