A book you say?
A book you say?
The blog has gotten a little dusty over the last 9 months.
What’s been going on? Business has been booming at Emerging Solutions and our Q4 FY11 was busier than ever for my Hyperion and OBIEE Infrastructure Practice.
Cameron Lackpour my partner in crime on Network 54, OTN, and of course KSCOPE somehow convinced quite a few people it was a good idea to write a book. I was the lucky first choice to write about Essbase infrastructure and put forth a good effort to write what I hope is a mostly timeless (as much as can be said with technology changing so rapidly) chapter.
An excerpt from Developing Essbase Applications: Advanced Techniques for Finance and IT Professionals follows:
Patching and upgrades
“Typical code bases for commercial software have hundreds of thousands of lines of code and can run into the millions of lines of code. There is intensive effort on software quality assurance in order to reduce, locate, categorize, and resolve defects. When releasing software vendors weigh the severity of known defects with the impact. If there are no “show stopper” defects and the product passes their quality tests within acceptable parameters, it will go to a generally available status.In the case of the Oracle Hyperion suite of products the known defects are communicated to end users in the product README documentation.”
|Patch||Individual patch applications usually take less than an hour and the system can be tested in less than a day. Only apply patches which have been released for longer than one month. Always apply patches to your non-production environment and allow it to burn in for two weeks.|
|New install||Select the most recent version when you are implementing Essbase for the first time and your timeline is greater than three months. This will provide the best feature set, support the most recent client software, support the most recent server software, and provide more longevity over older releases.|
|Service pack||A service pack is a mini in-place upgrade. Wait at least one month before applying a service pack. Perform full regression testing in your non-production environment and attain formal sign-off to install in production.|
|Major upgrade (migration)||Select the most recent version which has over three months of release time.Major upgrades can run from a few weeks for a very small user base with a minimal number of applications to several months for a large global user base with hundreds of applications.A few upgrade best practices:• Enact a change freeze
• Do not upgrade in-place; use new environments
• Perform full regression test using a POC environment