アップグレードの難易度

基本的に、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 のカスタマイズの多くは広範囲に渡るため、本書では、カスタマイズが実施され、カスタマイズをこの方法で管理していると想定しています。