| PeopleSoft Environment Usage | KEVIN RESCHENBERG
01-31-2007 |
Over the last two weeks I've outlined some ways of setting up
your PeopleSoft environments (databases) to enable development
and support. I've discussed having multiple testing environments
at one step on the migration path vs. multiple testing steps
on the migration path. Two common configurations are the three-step
path (DEV - TST - PRD) and the four-step path (DEV - TST - UAT - PRD).
Which is better?
As with so many things, it just depends. However, a major consideration
involves your data access policy. If developers are restricted from
seeing production data (or at least restricted from changing
production objects), then I'd recommend at least four steps on
the migration path. Here's why.
If developers cannot see production data, then obviously they
are not allowed to migrate objects to production. Another group will
do this. It might be DBAs or some separate production control group.
Now, suppose that we have a three-step setup (DEV - TST - PRD).
Developers migrate from DEV to TST, and the production control
people migrate from TST to PRD. That won't work. First, the production
control people have only one chance to practice the migration—and
it's on the production migration. That is very risky. Second, the
modification cannot be tested on "real" data, since TST would need
to be "scrambled"
to allow developers access to it. (Never restrict
developers from trying out their changes in TST!) It's just a mess,
so let's look at the four-step variation instead.
Consider the roles of four groups of people: Developers, testers,
end users, and the production control group.
In a four-step (DEV - TST - UAT - PRD) configuration, each group
has access to environments as shown below:
| Group |
Environments |
| Developers |
DEV, TST |
| Testers |
TST, UAT (and sometimes PRD) |
| End Users |
UAT, PRD |
| Production Control |
TST, UAT, PRD |
In this setup, we'll assume that DEV and TST contain "scrambled" data
and UAT and PRD contain "real" data. Developers make their changes in
DEV, test them, and then migrate them to TST. They
do another quick test in TST to ensure that the migration was complete
and accurate. The testers (functional team or QA group) check out the
changes in TST and then request migration to UAT. The production control
group migrates the objects to UAT using instructions provided by
the developers. The testers do another quick test in UAT to ensure that
the migration was complete. The end users then look at the change in
UAT. (The quality of testing at this point tends to vary wildly across
companies, departments and individuals. The value to be derived here
is mostly in the areas of "acceptance"—does the change reflect
the users' requirements?—and training of the end users.) If all
goes well, the production control group migrates the objects from UAT
to PRD, doing exactly the same steps they performed the first time
(TST to UAT). Note that production control does not ask for the instructions
again; the same instructions as before are used. If for some reason
there is a separate step for the production migration, the developers
must inform production control in advance. In almost all cases, this
migration should be the same as before.
Using this structure, everyone has adequate opportunities to test
both the actual change and the migration procedure. Both must
be accurate, of course, but the migration test is often neglected
and this results in unpleasant surprises in production. Of course, you
could have other steps along the way. But I recommend at least these
four steps where data access is an issue or where developers do not
migrate their own changes to production.
|
