Environment management - PUM strategy.

Hello, we are in the process of upgrading to PS 92 and are reviewing our PUM strategy. I have questions specifically on environment management.

1. I am wondering how we should manage the PUM images. For instance, which environment do we apply the images to (DEV or a PUM dedicated environment)?

2. How does that impact the ongoing development efforts while the new images are being applied and tested in a particular environment? Do we retrofit the new development back into the environment where PUM images are applied?

3. How long is a cycle to apply and go live with a new image assuming we apply PUM twice a year?

It would be great if someone can share his/her experience on this with us.

Thank you so much! Alex.

Hi Alex, at a high level here's how it works:

1. Download the image and bring it online either in VirtualBox or on a server using the Native OS option.

2. Using Change Assistant and the image's PIA site, define your change package - whether you're choosing get-current or some subset of fixes - the process is the same.

3. Apply the change package to your Demo environment in Initial Pass mode (we've begun doing our Demo environment LAST, however)

4. Apply the change package to your Dev environment in Initial Pass mode. This will include reviewing/reapplying custs and in the end will package those back into the change package for MTP mode.

5. Apply the change package to your subsequent environments in MTP mode.

During this process, you'll have to decide how to manage your ongoing development. If your development overlaps with objects that are touched by your change package you'll need to work around that. Ideally you'd have a development freeze during this process. If your development doesn't overlap then you're fine. If you're doing development as a result of testing or after the change package has been applied to the environment then you may want to merge all of that into a "follow-on" project to be applied to the next environment immediately after applying the change package.

As for timing, that can obviously vary depending on a lot of factors. Some of them outside of your control - one image might touch a huge customization and another might not. Personally, we're getting current 2x per year like you. The first cycle took us 3 months. Our current cycle is schuled (and on track) for about 4 months because we're including a Tools upgrade.

Your mileage may vary. One thing I'll note is around testing. A struggle for our company (and many others) has been to determine what exactly to test. The tendency is to try and figure out everything that gets touched by the change and to come up with a test plan for all of it. You'll quickly learn that is a losing battle. When you're looking at thousands of bugfixes that touch potentially tens of thousands of objects it's impossible to boil that down to a useful list without spending a decade on the analysis. Our approach, and the approach that Oracle recommends and other companies are adopting is to not focus so much on testing everything that's touched, but instead focus on testing your critical processes and customizations. For everything else, trust (yes, I said it) that Oracle is testing all of these bugfixes before releasing them (after all, they are specific fixes for specific bugs) and you don't  need to re-test them. Know that some things might fall through the cracks and just be prepared to address them post-production. Even if you spend 100 hours on analysis and feel like you have a comprehensive test plan, something will inevitablly fall through the cracks anyway. I bring this up because testing typically has the biggest impact to your timeline.

Charlie