|
January 10, 2007
PeopleSoft Support Environments
I once started at a new client assignment where I had been told, in
advance, that some cleanup and reorganization was needed. This company
had both HRMS/HCM and Financials. There were multiple development
databases and multiple testing databases. I had a change to make and
asked which development environment to use. Just pick any one, I was told.
Well, my first choice wasn't a good one because it turned out to be
rather unstable, so I tried another one. Now, which testing
environment(s) should receive the migrated change? That depended on
what type of change it was. Of course, some of the environments had
been patched and others hadn't, so some might be appropriate for
testing this change and others might not...
You get the idea. But I'm not picking on this client. Although the
people there knew about the problems, they might be surprised to learn
that this situation wasn't very special at all. I've seen variations of this all over the
place. It often occurs at newer installations and hopefully is cleared up
over time as the development/support team gains experience. Or maybe
it just keeps getting worse.
So here are a few thoughts on what I'd consider a simple, clean setup.
First, it's important to know that there is no one "best" way of doing this
that applies in all situations.
It all depends on your particular circumstances. What I'm going
to suggest below might be generally appropriate for typical installations, but not
for very large, active development projects.
Let's start with the basics. Oracle delivers an "empty" SYS database and
a version populated with sample data, called DMO. Both of these are
necessary. We can call them HRSYS and HRDMO (or FS___, etc.).
We need a development environment, typically called DEV (or HRDEV, FSDEV, etc.).
We will also need one or more testing databases. I'll get into that a
little more later. Finally, there will be a production database.
So a very minimal configuration might look like this:
SYS, DMO, DEV, TST, PRD.
(A quick aside about the database names. Keep them short, to five characters
or less, as in HRDEV. When you do an upgrade, you will want the extra space
for a version number or similar.)
SYS is used to create your initial environments. It contains only the basic data
that has been delivered along with the system. SYS can be kept for creating
additional environments later, but in my experience most customers just
set it aside and forget about it because it is more convenient to copy
another, customized environment.
DMO is used for the initial test of delivered patches and fixes. These should be
applied to DMO and tested before they are migrated to the other environments.
DMO is also used to recreate problems that will be reported to Oracle.
This means that DMO is a real, important environment. It should not be
considered a sandbox or play area. No customization should
be moved to DMO. It also doesn't work as a training
environment since it does not include any customization.
Customization is done in DEV and then migrated to TST. Once it has been
approved, it then migrates to PRD. Everyone on the team—technical,
functional, management—must understand this basic flow. Everyone should
be able to look at the name of a database (to which he or she has access)
and immediately understand what
it's for. If this is not the case, you are inviting problems.
Now, you might be objecting to this one-testing-database setup. It is typical
to have a number of different testing environments, in what could be called two
dimensions.
First, we have the migration path itself. If TST is used within the team
for initial functional testing, we might also want to set up a User Acceptance Test
environment called UAT. Changes will then migrate from DEV to TST to UAT to PRD.
There could be other levels of testing as well.
Some customers also set up a staging environment just before production.
This might be another testing stop, or it might just be a true staging area.
Whether you need one depends on whether you are trying to manage "releases"
of your custom changes. For now I'll assume that each change moves along the
migration path at its own pace, and that we therefore do not need a staging
database.
The second "dimension" of testing databases is represented by several
testing environments at the same step along the migration path. For example,
you might have several TST databases. There are many possible reasons, including
data considerations, timing, access issues, training considerations, and
politics. Yes, politics—and I'll dive into this unpleasant subject
next week.
Until next time...
|
