Tools release 9.1.2

[culater]

We're looking to upgrade from 8.9.4 to 9.1.2 and we've had two different approaches from our implementation provider. We are multifoundation with DV one one server and PY and PD on another. One approach is the traditional install to DV test, move to PY test, then PD. The other approach is to create another foundation which would be a copy of PD and apply 9.1 there and test and when it passes then apply to DV, PY, PD. I saw a post that stated to completely uninstall E1 fat client before installing the 9.1 client. The CNC resource that is suggesting the additional foundation is concerned with TR 9.1 and any impact it might have relating to current development efforts and moving things from DV to PY and PD. The other resource says this is a non issue. We can't freeze our development as we have to many projects going on at this time. Is anyone currently on 9.1.2 and are there any thoughts on developing on the new TR and then promoting to environments that are on an older release?

 

[DSauve]

culater,

I've checked with Oracle support, and with TR 9.1.2.x there is a new ELSE-IF control structure available in event rules. As long as you don't use this new control structure, you should be okay in developing in the new TR and promoting to an older TR. If you DO use the ELSE-IF construct and then promote it into a pre-9.1.2 TR, the specs will be corrupted, as the system doesn't know how to handle the new ELSE-IF construct.

With your current foundation for both PY and PD, you won't be able to apply the TR just to PY, as that will also affect your PD. You'll need to isolate PD so it's on its own foundation.

 

[cdawes]

I've been involved with 15+ tools 9.1 upgradea and was part oflargest beta for tools 9.1 so I've been working with it since Sept 2011.

You also don't need another foundation but the concerns of resource #1 are valid and you need to be aware of this. Resource #2 isn't wrong but some extra caution is advised.

The approach I advise is simple when moving to tools 9.1. If you can freeze development then do so. If you can't then you need some additional precautions.

I typically ad another environment called QA which is really a 2nd PY environment with its own path code.

The promition cycle would be DV --> PY and QA --> PD.

DV and PY would then be put on tools 9.1.

QA and PD would be on tools 8.9X.

Developers would test in DV, promote to PY and end users would test in PY on tools 9.1.

End users would also test in QA which is kept in sync with PY with the only difference being that QA is on tools 8.9X.

This way you've done the additional sanity test to ensure that there are no tools issues.

You WILL have more issues with your custom code on tools 9.1 simply due to the way that the UI and screen is formatted THAN issues with code developed on tools 9.1 runnign on tools 8.9X.

The choice is yours and somewhat dependant on how big a shop you're in.

Colin

 

[jdel6654]

We have a very similar configuration. However, my experience has been that major tools upgrades take forever to be implemented. There are too many reasons to mention.

For those reasons alone, we have 2 QA environments - one for 8.98 and one for 9.1.x. So we share the same Central Objects with 2 tools releases.

Code changes that are intended for Prod 8.98 are tested with the 8.98 QA. Code changes that are dependent upon the tools release and/or a side implementation are tested with 9.1 QA. All mods promoted to production are promoted with an 8.98 fat client.

Oracle will tell you that publicly its not supported but unofficially it will work. We have had good success with it. 9.1 was implemented six months ago and has still not made it to production.

 

[ice_cube210]

Re: Tools release upgrade Prod cut over

Hi All,

I would like to revive this thread to get some opinions on what people are doing for the Production cut over during a tools upgrade.

Most sites have separate servers for Dev and Prod , so the need for a multi foundation is not really there , especially if they have a agreed to a code freeze till the new tools is live (i.e no promoting to production , they will continue Development work in DV and PY which will be on the new tools release)

Oracle officially states that a pathcode should not be associated with more than one tools release. So how would one go about their production cut over ?

Would you apply all the TR updates to your production environment only during your cutover down time ? Which would be the following

- upgrade HTML server (can be done before hand if a new server or new instance and just point to PY and test and then only repoint to PD during cutover)
-upgrade Enterprise server tools release
-apply required planner and tools baseline ESU to PD (technically could be done before hand , but have to review object details to be sure of no impact to existing Production)
PD full package build and apply special instructions
Full gen (or truncate F98999* tables)

Above approach is assuming that that both old and new tools release work on the same base OS and DB versions and no upgrades are needed on that front.

Appreciate all and any feedback. Thanks in advance

 

[jdel6654]

Re: Tools release upgrade Prod cut over

[ QUOTE ]

Oracle officially states that a pathcode should not be associated with more than one tools release. So how would one go about their production cut over ?

[/ QUOTE ]

You test the hell out of it in a lower environment.

 

[JSS]

Re: Tools release upgrade Prod cut over

Currently I have DV/PY on 9.1.2.2 tools release on separate batch/app & web servers from production. My PD cutover plan is something like this:
- Apply planner and other 2 ESUs to PD
- Apply TR to PD batch/app servers
- Create new HTML instance on PD web logic server
- Full package build/deploy
- Login and test

Am I missing anything? Do I need a full package? Thanks.