|
January 24, 2007
Multiple Environment Strings
Last week's post
discussed the issue of having multiple testing environments at one
particular step in the migration path. There are many good reasons
for this, but I recommended migrating all changes to all of the
testing environments by default (unless there is a good reason to
exclude one of the environments). I also wrote that it is generally
not a good idea to allow project managers to claim separate
testing databases and exclude unrelated changes from being migrated
to them.
However, there is a more difficult situation that you might face.
Suppose that you have ongoing support and development, but also have
a large project that will completely transform the entire system. It could
be an upgrade (the most common situation) or another major project
that affects many different parts of the system. This project would
be expected to take a long time to implement, while the ongoing
support and minor modifications would proceed much more quickly.
How can this be handled?
In these situations you would probably need two different "strings"
of environments. One string (for example, xxDEV, xxTST,
xxUAT, xxPRD) would be used for ongoing maintenance and a new parallel string
(xxDEV2, etc.) would be created for the major project. The project
isn't affected by the maintenance and vice versa. Everybody's happy...
Well, except for the fact that the maintenance and the big project
are logically connected. Since the project affects large parts of
the system, it almost always overlaps the areas affected by the
maintenance. This means that the code and objects from the two strings
must be merged in a consistent, controlled way.
Here is how it can be done. Let's follow a normal maintenance change.
It starts out in DEV and then migrates to TST, then UAT, then PRD.
At some point it must also be applied to the other string (the one
containing the upgrade or other major project). At what point is this
done? You must decide this and be consistent about it. For example, you
could decide that the merge should be done after the modification has
been moved to production. However, this may tend to cause people to
put it off until it's forgotten. Another way would be to merge the
code after it has reached the user acceptance test (UAT) environment,
or after testing has been completed in UAT.
It could be done even earlier, but then you might find that you are doing
extra rework due to bugs that are found in testing. In any case,
a standard should be set.
The change is moved first to the major project's DEV environment
and then it migrates from there.
Who should merge the code? This effort should involve at least the original
developer and one developer from the other project team. It may also
involve the project's functional team, because the modification must
be evaluated to determine whether it will even be needed in the new
system, and if so, how it should work.
This can be a difficult situation and a prime source of bugs. It's
easy to let things slip so that some changes are merged with the
new code line and others aren't. This can lead to all sorts of surprises
at the end of the project. Monitor the situation closely and you can
largely avoid these problems.
Until next time...
|
