I am looking for the best practices for managing ESUs so that they don’t get abandoned in DV or PY.
I’ve heard many discussions on the subject with no real “Best Practice” determined just a bunch of different ways to do things.
So, how do you manage ESUs and/or how do you think they should be managed?
Update with a better explanation…
One of our biggest concerns is what to do with ESUs that do not fix our issue. Say we have an issue. We call Oracle. They suggest applying an ESU.
The first question is “to what environment do we apply the ESU so that it can be tested?”
1. Apply the ESU to Pristine
+ if the ESU fixes the problem, YAY! Apply the ESU to the rest of the environments and do any retro-fits necessary
- testing is difficult because of not using our real business data
- if the ESU does not fix the issue, you can no longer compare those objects with the ones in the other environments for subsequent modifications or troubleshooting
2. Apply the ESU to Pristine & DV
+ Pristine is more “fix current”
+ testing is easier because of using our real data
+ if the ESU fixes the issue, we do the retro-fits and go
- if the ESU does not fix the issue:
a. try to back out the ESU and hope for the best
b. wait for Oracle to issue a superseding ESU. Then after applying the new ESU we could delete the original one
I’ve heard many discussions on the subject with no real “Best Practice” determined just a bunch of different ways to do things.
So, how do you manage ESUs and/or how do you think they should be managed?
Update with a better explanation…
One of our biggest concerns is what to do with ESUs that do not fix our issue. Say we have an issue. We call Oracle. They suggest applying an ESU.
The first question is “to what environment do we apply the ESU so that it can be tested?”
1. Apply the ESU to Pristine
+ if the ESU fixes the problem, YAY! Apply the ESU to the rest of the environments and do any retro-fits necessary
- testing is difficult because of not using our real business data
- if the ESU does not fix the issue, you can no longer compare those objects with the ones in the other environments for subsequent modifications or troubleshooting
2. Apply the ESU to Pristine & DV
+ Pristine is more “fix current”
+ testing is easier because of using our real data
+ if the ESU fixes the issue, we do the retro-fits and go
- if the ESU does not fix the issue:
a. try to back out the ESU and hope for the best
b. wait for Oracle to issue a superseding ESU. Then after applying the new ESU we could delete the original one
First of all ESU should not be installed to pristine Env, it should keep as it is because a copy foundation is also important. Whatever ESU is there you need to attach you can try it on DV,and of-course this is my suggestion.
ReplyDeleteSee If you apply ESUs to your Pristine Environment and path code, you will then have the ability to restore object from the pristine path code.you will also have an idea where you can test the result of an ESU against Enterprise-one Pristine data.This will help to isolate whether your custom data or configuration is the reason an ESU is not don't what you think it should.
Delete