Sun Identity Manager 8.1 Upgrade

Terminology and Concepts

This section describes some specialized terminology that relates to upgrading Identity Manager.

Identity Manager Product Compared With Identity Manager Application

In some sections, this document distinguishes between the Identity Manager product and your Identity Manager application.

Development, Test, QA, and Production Environments

This document assumes that you are using the following, different types of environments:

Promotion

In this document, promotion refers to the process of generating a particular version of your Identity Manager application and moving that version from Development to Test, from Test to QA, and finally from QA to Production.

Source Control and CBE

You should use source-control tools to manage your configuration settings, any custom configuration objects, any custom code, any test plans, and any automated tests. Any source-control tool, such as CVS or Subversion, should allow you to track changes to any number of individual, text, or binary files and to reproduce a particular version of the Identity Manager application. This document refers to these tools generically as source control.

Some of these source-controlled files must be tailored for each environment. In particular, configuration objects contain values that often change for each environment. A particular Identity Manager resource object might point to one host machine in your Development environment, to another host machine in your Test environment, and to a third host machine in your Production environment.

Many customers use the Identity Manager IDE plug-ins for NetBeansTM and Eclipse to generate a tailored version of the Identity Manager application for each environment. The Identity Manager IDE plug-ins include a Configuration Build Environment (CBE). Some customers use older versions of the CBE that predate the Identity Manager IDE plug-in. A few customers use other tools and approaches, including proprietary or home-grown mechanisms. This document refers to these tools generically, and to the Identity Manager IDE specifically, as CBE.

The Identity Manager IDE plug-in and older CBE versions parameterize configuration objects (and can parameterize code) by replacing environment-specific values with placeholder values. To generate an image of the Identity Manager application that is appropriate to each environment, these tools replace the placeholder values with configured values that are appropriate to each environment. If you manage the parameterized objects in source control, you can “build out” the same version of the Identity Manager application for each target environment using a process that is predictable and repeatable.

Baseline and Image

In this document baseline refers to a tagged level of artifacts, which includes configuration objects, libraries, and custom code in source control, that corresponds to a particular version of your Identity Manager application. Your CBE can generate from this baseline an image of the Identity Manager application that is appropriate to each target environment. An image is a complete, working copy of the application that has been tailored for a specific environment.

At a minimum, your source control must contain a baseline for the version of your Identity Manager application that is currently deployed in your Production environment. Your source control can also contain baselines for previous versions of your Identity Manager application and baselines for versions of your Identity Manager application that you are still developing in preparation to roll out new functionality (such as modified configurations, modified workflows, modified forms, and new custom code for integrations).

Any baseline should be complete enough that you can use it to rebuild the corresponding version of your Identity Manager application. Some customers include the Identity Manager product itself within that baseline. Other customers save the Identity Manager product image separately and use the baseline artifacts to overlay that product image with their own configurations and customizations.

Skip-Level Upgrade

A skip-level, or multi-hop, upgrade updates your Production environment to an Identity Manager product version that is beyond the next major release from its current version. A skip-level upgrade typically requires a series of upgrades, but it is technically possible, and some customers find it feasible, to develop a single upgrade procedure that updates a target environment directly to the target Identity Manager version.


Note –

Chapter 6, Skip-Level Upgrade Considerations describes special considerations for a multi-hop upgrade. If you are uncertain about how to proceed, or if these considerations seem unclear to you, contact Sun Professional Services for assistance with planning and executing your upgrade.


Configurations and Customizations

In this document, the term configuration means editing configuration objects in the Identity Manager product. You can edit configuration objects by using the Identity Manager Administrator Interface or by editing repository objects in accordance with published documentation. For example, configuration includes specifying values in System Configuration or in a Reconciliation Policy. Configuration also includes defining Resource objects that represent the target systems and applications that Identity Manager will manage.

For the purposes of this document, the term customization refers to any code, file, or repository object that you write. Customizations include adding your own Java code, adding or modifying JSP files, and writing your own XPRESS code such as workflow, forms, and rules. Creating your own configuration objects or message catalogs is also considered customization.

Note that Sun Professional Services defines these terms somewhat differently. For example, Sun Professional Services might consider customer-specific workflows to be configurations.

In this document, however, the key distinction is that the Identity Manager product upgrade automatically preserves and updates customer-specified values within certain well-known objects and within instances of certain well-known types of objects. These are configurations. The Identity Manager product upgrade does not attempt to modify customer-written code or objects. These are customizations.

Upgrade Process and Upgrade Procedure

In this document, upgrade process refers to the upgrade mechanisms that are part of every version of the Identity Manager product. Each new version of Identity Manager contains not only updated code, but also an update.xml script. This update.xml script carefully preserves your configuration settings as it updates existing repository objects to work with the updated code. Any full release of Identity Manager might also contain sample database table scripts. These sample database table scripts carefully migrate existing data and update your database table definitions to work with the updated code.

This document uses the term upgrade procedure to refer to a document that you develop and maintain. An upgrade procedure often takes the form of a checklist. Your upgrade procedure states exactly what you plan to do in each target environment to upgrade your Identity Manager application. See Task 4: Prepare Your Upgrade Procedure.

Upgrade Project

This document describes phases in an upgrade project. An upgrade project is your effort to upgrade your Identity Manager application to work with a new version of the Identity Manager product on which your application is based. An upgrade project includes your efforts to maintain and retest your configurations and customizations after executing the Identity Manager upgrade process in your Development environment. An upgrade project also includes your efforts to maintain and retest the upgrade procedure that you will follow in each target environment.