test

Sun Identity Manager 8.1 アップグレード

第 1 章 アップグレードプロセスの概要

この章では、SunTM Identity Manager のアップグレードプロセスの概要と、次のトピックについて説明します。

アップグレードを実施する理由

Sun Identity Manager ソフトウェア (Identity Manager) のリリースをアップグレードすることには、次のような利点があります。

アップグレードパスとサポートポリシー

ここでは、次の内容を説明します。

Identity Manager のアップグレードパス

新しいバージョンの Identity Manager にアップグレードする際のアップグレードパスを決定するには、『Sun Identity Manager 8.1 リリースノート』の「アップグレードパスとサポートポリシー」を参照してください。一般的には、アップグレードするバージョンの最新のパッチまたはサービスパックを使用します。

標準以外のアップグレード方法は、予測できない重大な結果を招く恐れがあるため、このような方法は「絶対に」実行しないでください。

Identity Manager の標準アップグレードプロセスでは、既存のリポジトリオブジェクトを新しいバージョンの Identity Manager 形式に変換するために必要な手順が実行されます。特に、Identity Manager の各バージョンに用意されている「アップデータ」プログラムには、これらのオブジェクトの本来の意味と動作を保存する特別なロジックが含まれています。各アップデータプログラムは、特定のタイプの設定オブジェクトを更新します。各アップデータは、update.xml 内または update.xml に含まれるファイル内の、ImportCommand によって呼び出されます。既存のバージョンから更新されたオブジェクトは、新しいバージョンの Identity Manager に用意されているサンプルオブジェクトと、少し異なるメカニズムを使用する場合があります。

注意 – 注意 –

Identity Manager をアップグレードする場合、『Sun Identity Manager 8.1 リリースノート』の「アップグレードパスとサポートポリシー」で説明されている、必要なアップグレードパスに従う必要があります。

Identity Manager をクリーンインストールして、新しいバージョンの Identity Manager にカスタマイズを移行する場合でも、Identity Manager の各バージョンの標準アップグレードプロセスを適用して、既存のリポジトリオブジェクトを適切に更新する必要があります。Identity Manager の各バージョンに用意されているアップデータプログラムは、そのプログラムが提供されているバージョンでしか動作しません。

新しい init.xml ファイルのインポートによって生成されるオブジェクトを、古い init.xml ファイルのインポートで生成されるオブジェクトと比較するだけでは、既存のリポジトリオブジェクトをアップグレードするために必要な変更を完全に検出することはできません。これらの 2 つのオブジェクトセットを比較することで、アップグレードに関する作業量を簡単に予測することはできますが、安全で完全なアップグレードを実施するには、標準アップグレードパスが最適な方法です。

ソフトウェアサポートのサービス終了

Identity Manager ソフトウェアのサービス終了 (EOSL) ポリシーについては、『Sun Identity Manager 8.1 リリースノート』の「ソフトウェアサポートのサービス終了」を参照してください。

Identity Manager 非推奨ポリシー

Identity Manager ソフトウェアの非推奨ポリシーについては、『Sun Identity Manager 8.1 リリースノート』の「Identity Manager 非推奨ポリシー」を参照してください。

注 –

非推奨の項目は、『Sun Identity Manager 8.1 リリースノート』の第 6 章「非推奨の API」で説明されています。

アップグレードを行うときは、必ず新しいバージョンの Identity Manager に関するリリースノートを確認して、非推奨の機能についての最新情報を入手してください。

アップグレードの難易度

基本的に、Identity Manager のアップグレードの難易度は、Identity Manager に対して行なっているカスタマイズの量と種類によって決まります。一部のカスタマイズは、十分な下位互換性を保ちます。たとえば、ワークフロー、フォーム、および規則は、多くの場合、新しいバージョンの Identity Manager でも変更を必要とせずに動作します。その他のカスタマイズは流動的で、新しいバージョンの Identity Manager に統合するために追加作業が必要です。たとえば、Identity Manager 製品の一部である Java クラスを呼び出す統合コードは、再コンパイルまたは書き換えが必要です。

カスタマイズのもっとも重大な影響は、Identity Manager のアップグレードに必要な方法がカスタマイズによって変化することです。このあとの説明では、「用語と概念」で説明する用語と概念を使用しています。

Identity Manager を標準の状態で使用している場合、つまり、Identity Manager を「設定」していても「カスタマイズ」していない場合、Identity Manager のアップグレードは比較的簡単に実施できます。これらの用語については、「設定とカスタマイズ」を参照してください。Identity Manager 製品の各バージョンに含まれているアップグレードプロセスは、本来、それぞれの環境で実行されるように設計されています。製品のアップグレードプロセスは、Identity Manager の設定オブジェクトとその他のリポジトリオブジェクトを新しいバージョンのコードでも動作するように更新するときに、設定の内容を自動的に保存します。ただし、アップグレードプロセスは、カスタマイズの更新方法については認識しません。実際に、アップグレードプロセスは大部分のカスタマイズを無視します。アップグレードプロセスでは、アップグレードプロセスで置き換えられるファイルのカスタマイズされたバージョンが保存されますが、アップグレードプロセスで自動的に行われるのはこれだけです。

Identity Manager を (ほとんどのお客様が行なっているように) カスタマイズしている場合は、標準の Identity Manager 製品アップグレードを各環境で実行することができません。Identity Manager 製品をアップグレードしたあとに、カスタマイズを保守および再テストする必要があり、テストした内容が各環境に間違いなく届いていることを確認することも重要です。多くの場合、Identity Manager は広範囲にわたってカスタマイズされるため、Identity Manager の配備担当者はカスタマイズを管理するための複雑な方法を作成しています。詳細は、「ソース管理と CBE」を参照してください。

Identity Manager をカスタマイズする場合、もっとも一般的な手法は、ベースラインを保守してカスタマイズを管理し、Identity Manager アプリケーションのイメージを各ターゲット環境に生成およびプロモートする方法です。「ベースラインとイメージ」を参照してください。標準の Identity Manager 製品アップグレードプロセスを、開発環境のみで適用します。次に、アプリケーションベースラインに、アップグレードによって行われる変更の大部分を適用します。「Identity Manager 製品と Identity Manager アプリケーション」を参照してください。ただし、アップグレード手順には、Identity Manager 製品アップグレードの一部も含める必要があります。たとえば、アップグレード手順には、ベースラインの一部として管理されないリポジトリオブジェクトを更新するために、update.xml のサブセットが含まれます。また、Identity Manager リポジトリテーブルの定義を更新するための、データベーステーブルスクリプトが含まれる場合もあります。

ほとんどのお客様は Identity Manager をカスタマイズし、Identity Manager のカスタマイズの多くは広範囲に渡るため、本書では、カスタマイズが実施され、カスタマイズをこの方法で管理していると想定しています。

用語と概念

ここでは、Identity Manager のアップグレードに関する用語について説明します。

Identity Manager 製品と Identity Manager アプリケーション

一部の節では、Identity Manager 「製品」と Identity Manager 「アプリケーション」を区別して説明しています。

開発環境、テスト環境、品質管理環境、および本稼働環境

本書では、次に示す異なるタイプの環境が使用されていることを想定しています。

プロモート

本書では、特定のバージョンの Identity Manager アプリケーションを生成し、そのバージョンを開発環境からテスト環境、テスト環境から品質管理環境、品質管理環境から本稼働環境に移動するプロセスを、「プロモート」と呼びます。

ソース管理と CBE

設定、カスタム設定オブジェクト、カスタムコード、テスト計画、および自動化されたテストはすべて、ソース管理ツールを使用して管理するようにしてください。CVS や Subversion などのソース管理ツールはいずれも、任意の数のテキストファイルまたはバイナリファイルに対する個々の変更を追跡し、特定のバージョンの Identity Manager アプリケーションを再生成することができます。本書では、これらのツールを総称して「ソース管理」と呼びます。

これらのソース管理されたファイルの一部は、各環境に応じて作成する必要があります。特に、設定オブジェクトには各環境で異なる値が格納されます。特定の Identity Manager リソースオブジェクトは、開発環境、テスト環境、および本稼働環境のそれぞれで、異なるホストマシンをポイントする場合があります。

多くのお客様は、NetBeansTM 用および Eclipse 用の Identity Manager IDE プラグインを使用して、各環境に応じた Identity Manager アプリケーションを生成しています。Identity Manager IDE プラグインには、設定ビルド環境 (Configuration Build Environment、CBE) が含まれます。一部のお客様は、Identity Manager IDE プラグインよりも前の、古いバージョンの CBE を使用しています。少数のお客様は、専用のメカニズムや自社製のメカニズムなどの、その他のツールや方法を使用しています。本書では、これらのツールを総称して CBE と呼び、また Identity Manager IDE もその本質として CBE と表します。

Identity Manager IDE プラグインや古いバージョンの CBE は、環境に固有の値をプレースホルダの値で置き換えることにより、設定オブジェクトをパラメータ化し、コードをパラメータ化できます。各環境に適切な Identity Manager アプリケーションのイメージを生成するために、これらのツールはプレースホルダを各環境に適切な設定値で置き換えます。パラメータ化されたオブジェクトをソース管理で管理すると、予測および反復可能なプロセスを使用して、同じバージョンの Identity Manager アプリケーションを各ターゲット環境用に構築することができます。

ベースラインとイメージ

本書では、タグが付けられたレベルのアーティファクトを「ベースライン」と呼び、ソース管理された設定オブジェクト、ライブラリ、およびカスタムコードを含み、特定のバージョンの Identity Manager アプリケーションに対応します。CBE はこのベースラインから、各ターゲット環境に適切な Identity Manager アプリケーションの「イメージ」を生成できます。イメージは、特定の環境に合わせて作成されたアプリケーションの完全な作業コピーです。

ソース管理には少なくとも、Identity Manager アプリケーションの、現在本稼働環境に配備しているバージョンのベースラインが含まれている必要があります。ソース管理には、以前のバージョンの Identity Manager アプリケーションのベースラインや、新しい機能 (変更された設定、変更されたワークフロー、変更されたフォーム、統合用の新しいカスタムコードなど) をロールアウトするために開発しているバージョンのベースラインを含めることもできます

ベースラインはいずれも、対応するバージョンの Identity Manager アプリケーションを完全に再構築できるようにしてください。一部のお客様は、Identity Manager 製品自体をベースラインに含めています。また、Identity Manager 製品のイメージを別に保存して、ベースラインのアーティファクトを使用して製品イメージに独自の設定やカスタマイズを追加している場合もあります。

スキップレベルアップグレード

「スキップレベル (「マルチホップ」) アップグレード は、本稼働環境を現在の Identity Manager 製品のバージョンから、次のメジャーリリースよりも新しいバージョンに直接更新します。一般的に、スキップレベルアップグレードでは連続したアップグレードが必要ですが、ターゲット環境を 1 回でターゲットの Identity Manager バージョンに直接更新するアップグレード手順を作成することは、技術的に可能であり、一部のお客様でも可能であることが確認されています。

注 –

マルチホップアップグレードに関する特別な注意事項については、第 6 章スキップレベルアップグレードに関する注意事項で説明します。アップグレードの進め方を判断できない場合や、これらの注意事項に不明な点がある場合は、アップグレードの計画と実行について Sun のプロフェッショナルサービスにご相談ください。

設定とカスタマイズ

本書では、Identity Manager 製品の設定オブジェクトを編集することを、「設定」と呼びます。設定オブジェクトを編集するには、Identity Manager 管理者インタフェースを使用するか、公開されているドキュメントに従ってリポジトリオブジェクトを編集します。たとえば、設定には System Configuration や Reconciliation Policy の値の指定が含まれます。また、ターゲットシステムを表すリソースオブジェクトの定義や、Identity Manager が管理するアプリケーションの定義なども、設定に含まれます。

本書の趣旨として、「カスタマイズ」はユーザーが作成したコード、ファイル、またはリポジトリオブジェクトを表します。カスタマイズには、独自の Java コードの追加、JSP ファイルの追加または変更、およびワークフロー、フォーム、規則などの独自の XPRESS コードの作成が含まれます。独自の設定オブジェクトやメッセージカタログの作成も、カスタマイズと見なされます。

Sun のプロフェッショナルサービスでは、これらの用語の定義が多少異なります。たとえば、Sun のプロフェッショナルサービスでは、お客様に固有のワークフローが「設定」と見なされる場合があります。

本書での基本的な区別は、お客様が既知のオブジェクトや既知のタイプのオブジェクトのインスタンス内で指定した値を、Identity Manager 製品アップグレードが自動的に保存および更新することです。これらは「設定」です。Identity Manager 製品アップグレードは、お客様が作成したコードまたはオブジェクトを変更しようとしません。これらは「カスタマイズ」です。

アップグレードプロセスとアップグレード手順

本書では、Identity Manager 製品のすべてのバージョンの一部であるアップグレードメカニズムを、「アップグレードプロセス」と呼びます。新しいバージョンの Identity Manager にはそれぞれ、更新されたコードだけでなく、update.xml スクリプトも含まれます。この update.xml スクリプトは、既存のリポジトリオブジェクトを更新後のコードで動作するように更新するときに、ユーザーの設定を慎重に保存します。Identity Manager のフルリリースには、サンプルのデータベーステーブルスクリプトが含まれる場合もあります。これらのサンプルデータベーステーブルスクリプトは、既存のデータを慎重に移行して、データベースの定義を更新されたコードで動作するように更新します。

本書では、作成および保守するドキュメントを表すために、「アップグレード手順」という用語を使用します。多くの場合、アップグレード手順はチェックリストの形式をとります。アップグレード手順には、Identity Manager アプリケーションをアップグレードするために各ターゲット環境で実行する計画を正確に記述します。「タスク 4: アップグレード手順の準備」を参照してください。

アップグレードプロジェクト

本書では、「アップグレードプロジェクト」の段階について説明します。アップグレードプロジェクトは、ベースとしている Identity Manager 製品の新しいバージョンで動作するように、Identity Manager アプリケーションをアップグレードするための作業です。アップグレードプロジェクトには、開発環境で Identity Manager のアップグレードプロセスを実行したあとに、設定とカスタマイズを保守および再テストする作業が含まれます。アップグレードプロジェクトには、各ターゲット環境で実行するアップグレード手順を保守および再テストする作業も含まれます。

アップグレードプロジェクトの段階

次の図に、アップグレードプロジェクトの主な段階を示し、各段階を完了するために必要なタスクの概要を示します。以降の章では、各段階について説明します。

図 1–1 アップグレードの段階

4 つのアップグレードの段階を示すフローチャート。