OIPA Release Management

Overview

The purpose of this Release Management document is to provide an overview of the Oracle Insurance Rules Palette (OIRP) Release Management functionality. It is intended solely to help current customers understand the capabilities of Release Management, as well as to provide an example of how it might best be used within product releases. It should be noted that each customer may have slightly different needs. As such, it is suggested that customers also work with Oracle Consulting, who may also involve Oracle development resources, to adjust the procedures cited here to best meet individual needs.

Customer Support

If you have any questions about the installation or use of our products, please visit the My Oracle Support

website: https://support.oracle.com or call (800) 223-1711.

Oracle customers have access to electronic support through My Oracle Support. For information, visit

http://www.oracle.com/us/corporate/accessibility/support/index.html#info or visit http://www.oracle.com/us/corporate/accessibility/support/index.html#trs if you are hearing impaired.

Introduction

OIPA's Release Management capabilities provide a systematic method of tracking rule changes, as well as a process for packaging and migrating rules from one environment to another. Release Management is an optional tool within the Rules Palette. Using Release Management allows the configuration team to:

  • track multiple projects, such as new development initiatives as well as defect/bug remediation and the rules that are affiliated with each
  • force the tracking of any rule change into a Configuration Package
  • monitor migration status
  • bundle packages for a release to ensure that no rules critical to functionality are forgotten or missed during a migration
  • facilitate an audit trail and allow the user to view the rules that were moved to environment(s).

At each stage of the rules migration process, tight security privileges are provided to ensure a separation of duties among the configuration team.

Requirements

  • Target and source environments must share the same IVS database and it is recommended that they exist on the same track. If the environments do not share an IVS database, then a detached migration should be performed. Even though IVS versions aren't the same, the environments should start at the same OIPA baseline. Refer to the Detached Migration section for additional information.
  • Turn Release Management functionality on via the Web Application Utility. This is done by a build manager as individual users have no ability to turn release management on and off in the Rules Palette.
  • Install the Rules Palette and create security roles for users to control the access to the various stages of Release Management. Sample security roles and the corresponding privileges are outlined in the Create Security Roles section.
  • Set up the versioning tool. Steps to prepare for versioning are outlined in the Prepare for Versioning section.
  • Establish the naming conventions that will be used for the Configuration Packages. This is critical to ensure all configurors are well aware of the strategy used when creating Configuration Packages. This helps to prevent rule conflicts within multiple packages. Refer to Step 3a in the Important Considerations section on page 16 for additional information on naming conventions.
  • Create a generic Configuration Package to hold rules that are deleted from a Configuration Package. Use a descriptive naming convention such as "Orphan Rules". The Configuration Lead will need to review all orphaned rules to ensure they can safely be deleted.