Full package vs Update package

adeel

VIP Member
Hello there

Just wondering question:
How you measure which package to build.e g if one ESU has 1-10 objects I choose update package as it takes less time and less space to deploy. Multiple ESUs I do full package.

Is that the right approach?

Thought to ask and keep group busy and thinking :)

Thanks
 
It depends on WHAT is in the ESU(s) not how many objects are in the ESU(s). Whether it is an ESU or just a normal change to an existing object the same simple rule applies: If any objects results in a change to a .h file - specifically a change to a data structure, enum, #define, etc. anything that might be referenced by another object's .c/.h file and that other object is NOT included in the build - then you should do a full build to force a full recompile of all the C code. Now, if you want to determine WHAT changed in the .h files you could determine whether or not an update package will suffice - but if you want a simple rule...

Having said that. We do so few ESUs that to me it just makes sense to always do a full build for an ESU and then you don't have to worry (think) about it. For every day builds the default for us is to do an update package UNLESS the developer specifically notes that a full build is required in their special instructions when requesting a build. It is up to the developer to notify our CNC group when a full build is required.
 
Normally if a full package build is required, the special instructions let you know. That being said I have had cases...but they are are found in DV pretty quick, then when things are promoted to PY/PD I do a full. I NEVER just load an ESU in PD.

Also, just as a general rule, if I have more than 100 objects I normally do a full.

Tom
 
Thanks for responses.
Tom, as per your point, "I NEVER just load an ESU in PD).

If ESU has only specs, then we are safe to just promote the Project. But for any other parts introduced in the ESU, promoting will not be enough.

1. If you are using separate copy of Data dictionary tables for DV and PY and ESU has new DD item introduced in it , those changes will not be applied.

2. If there are records introduced for control Tables such as Menu/UDCs , those will not be updated.

3. One Major Drawback, the esu grid will not show PY or PD against esu, which is misguiding. So ,it will be an overhead to maintain documentation that the esu was promoted and not applied.


Thanks
 
Per Oracle as well..............generally, if you have more than 50 merged objects, it's probably a good idea to build a full package as opposed to an update package.
 
Thanks AL
Just wondering e.g if I have applied ESU in DV and we need to data refresh from PD due to Delay testing. My approach would be assuming no object under development.

1. Refresh DV.
2. Re apply back up of DV. Which I don't know how to do using CA.
Is it the approach or do the full object refresh from PA?

Thanks
 
This should answer all of your ESU questions.
 

Attachments

  • ESU.pdf
    212.8 KB · Views: 29
Last edited:
Adeel,

Correct.

We have only one DD, so 1 is moot.

For #2 Menus get promoted as they are part of the project that the ESU install process creates. UDC's we enter manually, or if there are many I SQL them to the target environment. This is also an issue for any other ENVIRONMENT that you may have, as ESU's apply to a PATH code.

For #3, since we don't load ESU's anywhere except DV , this is not an issue.

Tom
 
At the end of the day the most important recommendation is to know your environment details and act accordingly with cause and effect approach. Some clients maintain 2 DD, some ae in various stages of development so refresh impacts are critical, UDC and other control table knowledge is needed to assess impact, ESU testing and promotion timing is critical. So while it is important to understand the basic drivers, you also should carefully whiteboard with your stakeholders to insure you address all potential risks since even a small mistake can be a major setback.
 
I hear you. AL and Tom.

I thought we have same setup.

Apply ESU in each environment is recommended from Oracle when I spoke with them last year. The CA getting smarter and many Special instructions apply automatically.
 
I still always read the special instructions carefully and of course test the ESU thoroughly.
 
I hear you also Adeel, but the problem with applying the ESU's to production is that you still have to retrofit in production. I agree you could apply the ESU to production, then promote all the retrofitted objects, but since the apply of an ESU is based on timestamps, you may end up applying some extra objects that weren't applied in DV/PY, especially if you try to rollback ESU's.

So, in just my opinion, I prefer to do it this way, it ensures the same changes happen in PD as happened in DV, although it does take more work and expertise in knowing what needs to be done.
 
Our CNC group applies ESUs to each environment I believe so that change assistant will report things correctly (I am a developer, not a CNC admin so I may be speaking out of turn). For retrofitted objects we had issues in that when we promoted, because the time stamp is the "version", it was not replacing the ESU pristine version. To solve this problem, after the ESU is applied to a higher environment we simply have to drop the OMW project with the retrofitted objects back down to DV, do a check out/in and re-promote.
 
Thank Brian. I feel better now as your CNC does same as me.

I wanted to know if have to roll back ESU in non production env.in case things go wrong. But looks like it is not straight forward.

I learned a lot in this post!
 
Back
Top