Pristine Objects and ESU's

[pfaloney]

Pristine Objects and ESU\'s

We have been doing to auditing of Objects in various tiers (8.12) to see what has been applied and what had not been applied to various tiers (DV812, PY812, PD812) and when they were applied.

One of the audit reports I have created also contains pristine (PS812) which no object has been updated since the migration from 8.10 to 8.12. This means any new object from Oracle do not have a copy in Pristine Objects.

I am wonder, what are other companies' policy on updating Pristine when ESU's are applied.

 

[Adrian_Chimirel]

Re: Pristine Objects and ESU\'s

We keep Pristine updated with all the ESUs we applied to Production.
We have both Dev and CRP updated with all these ESUs, as well.
Next, we test the issue we discovered in Production (or Dev or CRP) in Pristine, and there are basically two scenarios:
S1 - The issue happens AS it happens in Production (or Dev or CRP) - now we can open a service request with Oracle ..., or
S2 - The issue does not happen, therefore we could suspect our mods to be the reason we have the issue.

 

[Null Value]

Re: Pristine Objects and ESU\'s

Updating Pristine with all ESUs that have been applied to Production apart from helping resolve issues like Adrian has pointed out, also helps figure out the customizations that were done on vanilla objects. This is especially helpful during upgrades (read retrofits).
Documentation of customizations is not a strong practice amongst many companies.

 

[Larry_Jones]

Re: Pristine Objects and ESU\'s

What Adrian said (of course)

 

[Oliver]

Re: Pristine Objects and ESU\'s

Hi,

This is what I have in my mind...

Pristine - update using Update Packs (cumulative ESU's)
DV, PY - update using singular/multiple ESU's
PD - promoted ESU's after testing in DV and PY...

Most of the time scenario 1 is happening wherein the ESU breaks another code that is being used in other modules...since Update packs only comes out after some time (yearly?) one can still refer to the pristine code that you can compare with the applied ESU's that have created issues in DV, PY or PD.

Can some of you guys comment on this?

Thanks.

 

[m@dm@x]

Re: Pristine Objects and ESU\'s

Once in a while a developer will get smart and ask us to update Pristine to our FIX Current we have in Production. More often than not, we kill that developer.

All kidding aside, at my last job we kept Pristine Fix Current with Production. However, at my current location, we really don't care about Pristine.

Max

 

[dschleicher]

Re: Pristine Objects and ESU\'s

We install ESUs into Pristine when we install them into PY, do our initial testing in PY without our customizations, reapply our customizations but then only promote our customizations to PY for testing. This way if we encounter issues testing an ESU in PY after our customizations have been reapplied, we can test in Pristine.

Dave Schleicher
LOGIS
E1 8.12, 8.98.3.1, Windows 2003, SQL 2005, OAS 10.1.3.1

 

[DRezanka]

Re: Pristine Objects and ESU\'s

Our process is a little elaborate to allow for different approaches to taking the ESU. But if we take the whole ESU, we also apply it to PS when we promote to PD.

I'm not far from you in Southfield here. Let me know if you want to talk about it more.

 

[Adrian_Chimirel]

Re: Pristine Objects and ESU\'s

[ QUOTE ]
(of course)

[/ QUOTE ] You really HAD to add that, had you not?
Adrian Sarcasman

 

[Larry_Jones]

Re: Pristine Objects and ESU\'s

 

[Jack_Crouch]

Re: Pristine Objects and ESU\'s

Two questions.

1) Sounds like some use OMW to promote an ESU from PY to PD? I have always applied the ESU to PD once it is testing rather than use OMW. What is recommended?

2) Let's say an ESU put into PY does not help the issue and becomes irrelevant. Do most people just let them fester in PY and continue to make PY more different from PD as more occur like this? Then eventually one might refresh PY code from PD... but then the ESU history would show the wrong thing at that point. What is normal practice for this type of thing?

 

[adeel]

Re: Pristine Objects and ESU\'s

I thing this is very good post.

Same here we do apply ESUs in PD and PS togethar after testing from DV and PY. We do not build full package right away for PS and do occassionally.

We dont have customized objects and just wondering from those companies who update the objects in all environments and if some object get corrupted and user did not find during testing then how developers recover that objects?

Thanks
AD

 

[Larry_Jones]

Re: Pristine Objects and ESU\'s

Here's the perspective from one shop that does customizations.

We have a fair amount of customizations (about 600 objects).
Whenever we upgrade (such as our upgrade to 9.0) we go thru the installation / upgrade process.
We do initial testing against areas/issues that appear in every release (just to see if by some miracle they've been fixed).
We also look to see to see if we can eliminate customizations due to changes in the software or the business.
We apply ESUs (so many ESUs) to all environments (generally only PS, DV at that point) and finally re-apply customizations to standard objects.
Then we do user acceptance testing.
If issues/bugs are detected and a ESU will resolve we will apply the ESU (now to PS, DV, and PY), test to see if issue resolved, redo any customizations if needed, and perform acceptance testing again.

Once we go live on a new release its rare for us to apply any more ESUs. It does happen - but its very rare (1 a year?).
In part this is due to the cost of re-applying customizations to affected objects. But more because once we have gone live we undertake the burden of fixing bugs ourselves if its within our capabilities.

Because of our process I can't remember having the problem of trying to roll back a "bad" ESU from all environments because once we go live the opportunity rate to get a bad one is almost negligible. I can see where its an issue for others though - if indeed "bad" ESUs are common