SURVEY: Where do you apply ESUs?

We're debating this subject and want to hear what others do. Where do you apply ESUs?
* Pristine
* Special ESU environment
* DV
* PY
* PD
* Other

We have both ESU environment and Pristine environment. If there's a new ESU
to test, we install it in ESU environment, if the ESU test
successfully(solve the problem and does not break anything), we install
the ESU in our DEV environment, do retrofitting, then promote to CRP, then
promote to PRD, after the ESU is in PRD, we then promote the ESU to
pristine.

Thanks
Jennifer Qiu





kbgus
<[email protected]> To: [email protected]
Sent by: cc:
jdelist-bounces@j Subject: SURVEY: Where do you apply ESUs?
delist.com


08/19/2004 10:41
AM
Please respond to
"PeopleSoftï½®
EnterpriseOne"






We're debating this subject and want to hear what others do. Where do you
apply ESUs?
* Pristine
* Special ESU environment
* DV
* PY
* PD
* Other


World & OneWorld Consultant

Same ESU gets applied to:
JD7333,DV7333,PY7333,PD7333

Maybe I should have specified "initially". Hopefully, this isn't done at the same time.

We apply the ESU to our DV environment first. Then it moves up to PY, then a custom environment before hitting PD. We only apply to pristine after the ESU has made it's way into production.

We apply ESU's to JD, DV and then create a project to move it to PY and PD after testing.

Patty

Initially we applied to DV and promoted forward; however, this leaves the Pristine (JD) environment behind. Trust me, you DON'T want to go there...now we move from JD forward...

First I "install" them on the deployment server. Then I update the Impact Analysis and have the B/As review for object updates requiring retrofits.
Once this is approved it is then installed to the JD9 and DV9 environments. A full package is created and tested then signed off before it is installed/built/deployed to QA9 and PY9. Once these have been tested and approved a final install/build/deploy to PD9.
Whew, that is a good two to three weeks of work right there.

I would suggest that you follow your development life cycle. If you typically start in DV put the ESU in DV. It is important to understand that installing the ESU does not give the objects involved the token. After installing the ESU I would immediately check them out and back in so they get the token. Otherwise another developer may grab the object, modify it, and promote it to production without the rest of the objects in the ESU.

I remember a day when the pristine environment was the "pristine" environment. I'm not sure what Peoplesoft's recommendation is, but I don't like installing ESU's in the pristine environment. I like to keep a pathcode that is "out of the box", but I can understand the argument for installing ESU's into the pristine environment.

I would also consider creating a ESU environment that can be used for installing ESU's for the purpose of "stealing" the code. A lot of people just want to look at a code change for a specific SAR/Object and they manually port it into their custom object. You can also use this enviroment to install all ESU's if you want an environment that is pristine + all installed ESU's.

Does this mean your pristione environment ceases to be pristine because it has ESU's installed on it now ?

It's a matter of each person's faith, environment specifics and the comfort level with either doing or not doing ESU/Update application in Pristine. It can certainly be argued either way.

Having seen comments from the proponents of keeping Pristine as pristine as possible, let me put forth some arguments to the contrary:

What do you use Pristine for? If you do or intend to use it to recover Objects, you certainly want it to be kept in synch with the rest of the system.

E.g.: what can you use pristine Pristine (no Updates/ESU's) for, if your system has U6 and some 50 ESU's in Production? - most of the Objects will be quite different and testing results in Pristine will never be comparable to what you can observe in Production.

This approach of applying everything to Pristine makes it a "moving target", but has certain significant benefits and does not really violate any rules, as far as "unaltered objects" rule is concerned, be that Update1, Update6 or any other "standard" set of "unaltered objects".

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

ESUs are applied to a project in DV with some base unit testing, promoted via OMW to PY for integrated testing, then promoted to PD. I agree with Alex that Pristine is of limited value once you start applying numerous ESUs and updates to the DV environment.

Assumption:
Stable environment - not preparing to implement or upgrade to new version.

We always apply ESUs first to Pristine as frequently IN A STABLE ENVIRONMENT we do not want all the objects in a ESU (and associated new bugs). Typically we only want to see a particular bug fixed in which case after analysis we we extract and promote only the objects needed to correct the issue we had. Sometimes this may be the entire ESU. However ESUs that include hundreds of objects rarely make it past Pristine as a whole unless we are in the midst of an upgrade where the new version is not stable to begin with.

My 2 cents worth,