|
| |
| Sun[TM] Identitiy Manager 8.0 Upgrade | |
Chapter 1
Overview of the Upgrade ProcessThis chapter provides an overview of the Identity Manager upgrade process, which includes the following topics:
Why Upgrade?Upgrading your release of Identity Manager provides several advantages, including:
Upgrade Paths and Support PoliciesThis section provides the following information:
Identity Manager Upgrade Paths
To determine the upgrade path you must follow when upgrading to a newer version of Identity Manager, see “Upgrade Paths and Support Policies” in the Sun Java™ System Identity Manager 8.0 Release Notes. Generally, use the latest available patch or service pack for the version to which you are upgrading.
Using non-standard upgrade techniques is strongly discouraged because serious, non-obvious consequences can result.
Identity Manager's standard upgrade process performs steps that are necessary to convert existing repository objects into the format that the newer version of Identity Manager expects. In particular, the updater programs that are shipped with each version of Identity Manager contain special logic that preserves the original meaning and behavior of these objects. Each updater program updates a specific type of configuration object, and each updater is invoked by an ImportCommand within update.xml or within a file that update.xml includes. Updated versions of pre-existing objects often use slightly different mechanisms than those used in the sample objects that ship with the new Identity Manager version.
End of Service Life for Software Support
During the End of Service Life (EOSL) period, Identity Manager software support is offered in two phases:
The following table provides information about the EOSL and EOL dates for older versions of Identity Manager.
Full Support Phase
During the Full Support Phase, Sun Microsystems, Inc. provides software support in accordance with the customer's support contract with Sun (including the applicable Service Listing) as set forth at:
http://www.sun.com/service/servicelist/
As of the software product’s announced EOL date, customers will no longer have access to software updates and upgrades for that product.
Limited Support Phase
During the Limited Support Phase, Sun Microsystems, Inc. provides software support in accordance with the customer's support contract with Sun (including the applicable Service Listing) as set forth at:
http://www.sun.com/service/servicelist/
However, customers are not entitled to submit bugs or to receive new patches from Sun Microsystems, Inc. As with Full Support Phase, after the software product’s announced EOL date, customers will no longer have access to software updates and upgrades for that software product.
Identity Manager’s Deprecation Policy
Generally, Identity Manager Engineering does not remove interfaces, public classes, or public methods without first announcing the change and then waiting at least one full year before removing the interface, class, or method.
For example, if Identity Manager Engineering decides to remove a public Java class from the product or change the signature or behavior of public methods in a public class, Engineering deprecates that class or method, and then waits at least one year. Additionally, when method signatures or behaviors must be changed, the standard policy is to add a new method and deprecate the old method.
Java classes and methods are deprecated programmatically using the @deprecated Javadoc tag. This @deprecated tag causes the Java compiler to emit a warning message when customers recompile code that refers to a deprecated class or method. Both the @deprecated tag and the deprecation warning message provide
The @deprecated tag does not work for other types of interfaces and behavior. For instance, there is no way to use the @deprecated tag for JSPs, Views, or configuration objects. You must check the Release Notes for this information because Engineering cannot deprecate these interfaces programmatically.
Identity Manager Engineering generally removes deprecated interfaces or behavior no sooner than one full year after the release in which the class or method was first deprecated. Engineering generally removes deprecated interfaces or behavior only in a full release of Identity Manager. A full release is a major or a minor release (for example, 8.0 or 8.1).
Exceptions to this policy might be necessary in unusual circumstances, but Identity Manager Engineering is committed to providing backward-compatibility for its customers to the extent that it is feasible to do so.
How Easy is Upgrading?Basically, how easy or how difficult it is to upgrade Identity Manager depends on how much you customize Identity Manager and what kind of customizations you make. Some customizations are highly backward-compatible. For example, older workflows, forms, and rules tend to work without modification on newer versions of Identity Manager. Other customizations are more volatile, and require additional work to integrate them with new versions of Identity Manager. For example, you might have to recompile or rewrite integration code that invokes Java classes that are part of the Identity Manager product.
The most significant effect of customization, however, is that customization changes how you must approach upgrading Identity Manager. Note that the following discussion uses terminology and concepts discussed on (more...) .
Upgrading Identity Manager can be relatively simple if you use the product as shipped — that is, if you configure Identity Manager but do not customize it. If you are unfamiliar with these terms, see Configurations and Customizations. The upgrade process that is part of each version of the Identity Manager product was originally designed to be run in each environment. The product upgrade process automatically preserves your configuration settings as it updates Identity Manager's configuration objects and other repository objects to work with the newer version of code. However, the upgrade process does not know how to update your customizations. In fact, the upgrade process simply ignores most customizations. The upgrade process does save off the customized version of any file that the upgrade process intends to replace, but this is the most that the upgrade process can do automatically.
If you customize Identity Manager, as the vast majority of customers do, then you cannot simply run the standard Identity Manager product upgrade in each environment. You must maintain and must re-test your customizations after you upgrade the Identity Manager product, and you want to be certain that exactly what you tested goes into each environment. Because Identity Manager is often customized extensively, those who deploy Identity Manager have developed sophisticated practices for managing their customizations. For more information, see Source-Control and CBE.
If you customize Identity Manager, the most common approach is to manage your customizations by maintaining a baseline and then to generate and promote an image of your Identity Manager application into each target environment. See Baseline and Image. You apply the standard Identity Manager product upgrade process only in your Development environment. You then apply to your application baseline most of the changes that the upgrade makes. See Identity Manager Product Versus Identity Manager Application. However, your upgrade procedure also must include some pieces of the Identity Manager product upgrade. For example, your upgrade procedure will include some subset of update.xml to update repository objects that are not managed as part of your baseline. Your upgrade procedure might also include database table scripts to update Identity Manager's repository table definitions.
Because the vast majority of customers do customize Identity Manager, and because many customize Identity Manager extensively, this document assumes that you have customizations and that you manage your customizations with this approach.
Terminology and ConceptsThis section describes some specialized terminology that relates to upgrading Identity Manager.
Identity Manager Product Versus Identity Manager Application
In some sections, this document distinguishes between the Identity Manager product and your Identity Manager application.
- Identity Manager product means the product as shipped, with standard samples, JSPs, JARs, and configuration objects.
- Identity Manager application means the customer's deployment of Identity Manager, which will be uniquely configured and might be customized, might include custom code and modified JARs, might be re-labeled, and so forth.
Development, Test, QA and Production Environments
This document assumes that you are using the following, different types of environments:
- A Development environment is where you configure, customize, and use source-control to build an image of the Identity Manager application to be promoted to another environment. You also write an upgrade procedure in this environment that you follow in each target environment.
- A Test environment is where you test your upgrade procedure against controlled data and perform controlled testing of the resulting Identity Manager application.
- A QA environment is where you test your upgrade procedure against data, hardware, and software that closely simulate the Production environment and where you allow intended users to test the resulting Identity Manager application.
- A Production environment is where the Identity Manager application is actually available for business use.
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 NetBeans 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, 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 may 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, 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 a 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
Appendix A, "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 using Identity Manager’s 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 Java Server Pages (JSP) files, and writing your own XPRESS code such as workflow, forms, and rules. Creating your own configuration objects or message catalogs also counts as customization.
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 contains 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 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 says 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 re-test your configurations and customizations after executing Identity Manager's upgrade process in your Development environment. An upgrade project also includes your efforts to maintain and re-test the upgrade procedure that you will follow in each target environment.
Phases of the Upgrade ProjectThe following figure shows the major phases of the upgrade project, summarizing the tasks and steps that you must perform to complete each phase. The rest of this document guides you through each phase.
Figure 1-1 Upgrade Phases
