MUDのヒントおよびテスト・プラクティス

マルチユーザー開発環境で作業する上でのヒントおよびベスト・プラクティスについて説明します。

この項では、次の項目について説明します。

ブランチに関するベスト・プラクティス

次のガイドラインを使用して、サイド・ブランチを作成します。

マスター・リポジトリが格納されるMUDディレクトリは、Oracle BIサーバー・ローカル・リポジトリ・ディレクトリと同じにすることはできません。
ブランチはチェックアウトされたMUDプロジェクトにします。そうすることで、正しい元のリポジトリの使用などの、ブランチをメイン・ブランチにマージしなおすタスクの多くが自動化および合理化されます。
チェックアウトされたブランチ・マスター・リポジトリは、必ず独自のMUDディレクトリに配置します。開発者には、そのブランチ・マスター・リポジトリからファイングレイン・プロジェクトをチェックアウトするように指示します。ブランチの開発、公開およびテストが完了したら、ブランチ・リポジトリ・ディレクトリからマスターを削除し、管理ツールを使用してそれをメイン・ブランチ・マスター・リポジトリに公開しなおします。そこで、それを再度チェックアウトして次のフェーズの開発用にブランチMUDディレクトリに新しいバージョンを配置します。
ブランチMUDディレクトリのWindows権限を使用して、それにアクセスできる開発者を制御します。
ブランチMUDディレクトリに.optファイルを作成して、マルチユーザー開発オプションを設定します。特定の管理者を定義して、整合性チェックを必須にするおよび「マージ中に等化」を「はい」に設定することをお薦めします。「マルチユーザー開発オプションの設定」を参照してください。
本番に配信する機能の増加分に応じて、ブランチを計画します。各ブランチには、ユニットとして移行する増加分を含めるようにします。
誤ってブランチを正しくない順序でマージした場合、MUD履歴を使用してロール・バックできます。「マルチユーザー開発の履歴の表示と削除」を参照してください。

プロジェクトの設定に関するベスト・プラクティス

次のガイドラインを使用して、プロジェクトを設定します。

リポジトリの構築は、パフォーマンスの向上と管理の容易さに役立つ状態を維持しながら可能なかぎり小さくするファイングレイン・プロジェクトに分割してください。
論理ファクト表を小さなパーティーションに分割して、小さな個別のプロジェクトを使用できるようにします。
各サイド・ブランチでは、ブランチのコンテンツを抽出する大きなプロジェクトをオーバーレイします。そうすることで、プロジェクトで、元のリポジトリの追跡を含め、ブランチのチェックアウトおよびマージの管理が可能になります。個々の開発者は、チェックアウトしたブランチ・プロジェクトから開発プロジェクトをチェックアウトできます。すべての開発プロジェクトは、それをメイン・ブランチにマージしなおす前にサイド・ブランチに公開しなおす必要があります。
新しいコンテンツをリポジトリに追加する場合、必ずそれがプロジェクトの一部であることを確認してからチェックインしてください。プロジェクトの一部でないオブジェクトを作成および公開すると、次にそのプロジェクトをチェックアウトするときに、抽出対象に含まれなくなります。その場合、管理者またはMUD管理者はリポジトリ全体、または新しいコンテンツがたまたま含まれていた別のプロジェクトを最低でもいくつかは編集し、オブジェクトをそのときのプロジェクトに追加する必要があります。
複数のプロジェクトを同時に抽出して、必要なすべてのコンテンツを取得する必要がある場合があります。

注意:

サブジェクト・エリア、プレゼンテーション表、プレゼンテーション階層などのプレゼンテーション・レイヤー・オブジェクトが、ここでプロジェクトに明示的に含めるオブジェクトになります。以前のリリースと異なり、管理ツール・ユーザーのセキュリティ設定は、チェックアウトするときにプロジェクトに含まれるサブジェクト領域、プレゼンテーション表またはプレゼンテーション列には影響しません。そのかわり、プレゼンテーション・レイヤー・オブジェクトのセットで、プロジェクトの有効範囲が決定されます。

「プロジェクトの設定」を参照してください。

3方向マージに関するベスト・プラクティス

3方向マージを実行する場合は、次のガイドラインを使用します。

変更されたリポジトリと現在のリポジトリの両方の構築元のリポジトリがあることを確認します。
一般的には、現行用としてに開発リポジトリを開き、変更済としてメイン・リポジトリを使用し、オリジナルとしてブランチの開始点を使用します。
マージする前にユニット・テストを実行します。
リポジトリ・マージ・ウィザードでは、「マージ中に等化」と「マージされたRPDの整合性のチェック」を選択することをお薦めします。「オブジェクトの等化」を参照してください。

MUDマージに関するベスト・プラクティス

MUDマージを実行する場合は、次のガイドラインを使用します。

マージする前にユニット・テストを実行します。
マージ後(ただし公開前)にユニット・テストを実行します。マスター・リポジトリ上でロックを保持することになるので、簡潔に実行してください。
「ツール」→「オプション」→「マルチユーザー」タブで、自分のフルネームが正しいことを確認します。そうすることで、誰がロックを保持しているかログに記録されチェックできるようになります。
変更を公開するときは、「ロック情報」画面に、役に立つコメントを必ず書き込んでください。後で自分自身または他の管理者がロールバックまたは他のタスクを実行する必要がでてきた場合、そのコメントを使用してリポジトリの履歴を特定しやすくなります。
MUD管理者がマスター・リポジトリ(RPD)を編集しているときは、チェックアウト・ユーザーがそれにアクセスできないようにする必要があります。このようにするために、共有ディレクトリからそれを一時的に削除してから別のディレクトリに配置したり、編集前にその名前を変更できます。編集が完了したら、必ずそれを元に戻してください。

リポジトリをオフライン・モードで開くと、Windowsファイル・システムによるユーザーのロックアウトを回避できます。この方法は、すべての作業を1つのセッションで完了できる場合にのみ使用してください。
頻繁にマージします。小さなマージでは競合リストや必要な決定は、わかりやすいものです。マージが大きすぎると、変更数はわかりにくくなり、ヒューマン・エラーが回避しにくくなります。ロールバックする必要がある場合、廃棄される変更数も大きくなります。パフォーマンスも小さいマージの方が向上します。
マージのパフォーマンスに問題がある場合、プロジェクトをいくつかのより詳細なファイングレイン・プロジェクトに分割することを検討してください。各マージの変更数が少なくなり高速になるように頻繁にマージしてください。
ローカル接続プールの変更は、変更を公開するたびにマスター・リポジトリの接続プール設定で上書きされるので、それがマスターと異なる場合は、チェックアウトするたびにローカルテスト設定を再度適用する必要があります。これに最適な方法は、Oracle BIサーバーXML APIを使用して、ローカル接続プール設定の適用を自動化することです。『Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンス』の「テスト環境から本番環境への移行」を参照してください。
成功を収める多くの大規模なチームには、リポジトリ開発者とMUD管理者と間のコミュニケーションおよびタスクに関する正式なプロセスの要件および想定が存在します。たとえば、MUD管理者にプロジェクトを作成するよう要求するフォームが用意されています。多くのチームには、サービス・レベルの合意およびリード・タイムを持ちます(プロジェクトを作成するために24時間必要など)。
MUDマージ中に整合性チェックを強制するオプションを設定します。クリーン整合性チェックでは、コードが正しく生成されるかどうかを調べるコンパイラによるチェックと同様の方法で、Oracle BIサーバーでモデルを正しくロードできることが確認されます。マージが成功したと思われる場合でも、一貫性のないリポジトリによって、Oracle BIサーバーの起動、オンラインのリポジトリの編集チェックイン、それに続くマージに問題が生じることがあります。「マルチユーザー開発オプションの設定」を参照してください。
マージする前に等化を強制するオプションを設定します。開発者は同じ物理表をインポートすることなどが多いので、この設定を行うことで重複するオブジェクト数が削減されます。「マルチユーザー開発オプションの設定」を参照してください。

オブジェクトの等化の重要性の詳細は、「オブジェクトの等化」を参照してください。
他のユーザーが必要なコンテンツは、そのコンテンツの所有者である場合や他の開発者と連携している場合を除いて、削除または変更しないでください。プロジェクトで不要になる列を削除すると、他のユーザーがそれに依存していても、マージしたときに通常はそれがマスターから削除されます。

注意:

プレゼンテーション・オブジェクトの別名は、マージの際に特別な扱いを受けます。その目的は、名前が変更されたときに古いレポートが破損しないように、オブジェクトの従来の名前を保持することです。開発中にどのように名前を変更しても、新しい別名が追加されます。マージ時には、いずれの新しく作成した別名も保持するかしないかを選択できます。また、従来のレポートが存在する場合もあるので、過去の別名のいずれかまたはすべてを保持するオプションもあります。

「マルチユーザー開発のマージ・プロセスについて」を参照してください。

2方向マージに関するベスト・プラクティス

個別に開発された2つのリポジトリを単一のリポジトリに結合する必要がある場合、2方向マージを使用します。

単一のリポジトリに2つのセマンティック・モデルをホストする必要がある場合、このような状況が多く発生します。

2方向マージを実行する場合は、次のガイドラインに従います。

意図せず名前の変更やオブジェクトのマージが行われないように、各リポジトリのトップレベル・オブジェクトには異なる名前があることを確認してください。次のオブジェクトをチェックします。
- ビジネス・モデル
- サブジェクト領域
- 物理データベース
- 変数
- 初期化ブロック
- アプリケーション・ロール
- ユーザー
- マーケティング・オブジェクト
マージする前に等化を行います。そうすることで、管理対象のすべての完全修飾名が考慮され、2つのリポジトリ間で競合が発生しないようにアップグレードIDが割り当てられます。「オブジェクトの等化」を参照してください。
管理ツールで、元のファイルとしてのブランク・リポジトリと完全マージを実行します。

ブランク・リポジトリを作成するには、新規リポジトリを開いて、ソースのインポートやオブジェクトの作成を行わずにそれを保存します。このリポジトリにはデフォルトのセキュリティ・オブジェクトが含まれていますが、これらがマージに影響することはありません。

注意:

管理ツールの「リポジトリからのインポート」やコピー/貼付けなどの機能を使用してメタデータを段階的に移動しないでください。このようなアプローチでは、変更が正しくマージされません。

これらの機能を使用すると、多くの場合に期待どおりの結果が得られますが、それは単なる幸運です。それ以外のときは、メタデータ・オブジェクトのアップグレードIDの値が競合し、事実上オブジェクトがランダムに上書きされます。しかし、その問題は、かなり後のリグレッション・テストを実行するときまで発見されない場合があります。アップグレードIDは連続して割り当てられており、1つのリポジトリ内で一意であるため、競合が起こりやすくなります。

また、biserverxmlcliおよびbiserverxmlexec -Bユーティリティを使用する場合も注意が必要です。Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスで説明されているID管理に関する情報について、十分に理解してください。

「共通の親を使用しない完全なリポジトリ・マージの実行」を参照してください。

本番移行に関するベスト・プラクティス

テストから本番に移行する場合は、次のガイドラインを使用します。

本番クラスタ上でメタデータを更新する場合、変更のロード中に停止時間が発生しないように、ローリング再起動を実行して一度に1つのOracle BIサーバーを再起動します。BI Systems Management APIを使用してOracle BIサーバーをプログラムで起動および停止したり、Fusion Middleware Controlで各Oracle BIサーバーを手動で再起動できます。
Oracle BI管理ツールを使用してオンライン・モードで本番のメタデータを変更することはお薦めしません。
biserverxmlcliユーティリティを使用してオンライン・モードで本番のメタデータを更新しないでください。

アプリケーション・ロールおよびユーザーに関するベスト・プラクティス

アプリケーション・ロールおよびユーザーを使用して作業をする場合は、次のガイドラインを使用します。

リポジトリ内のユーザー・オブジェクトの周辺では、データ・アクセス・セキュリティを構築しないでください。かわりに、アプリケーション・ロールに基づいて、リポジトリ権限、フィルタおよびガバナーを定義します。
アプリケーション・ロールのセットは、管理委員会で定義する必要があります。ビジネス・チームは、どのようなビジネス・ロールがあり、どのユーザーがどのデータを参照できるように割り当てられ、あるアプリケーションから次のアプリケーションまででどのロールが同じになるかを習熟しています。そのため、管理委員会はアプリケーション・ロールを定義および指名し、どのロールをアプリケーション間で共有するかを決定するする立場にあります。
新しいアプリケーション・ロールを作成する場合、マージ後にそれを再度チェックアウトできるように、それをプロジェクトに追加してください。また、オフライン・モードで、管理ツールでプレースホルダ・アプリケーション・ロールを作成する場合、後でそれをポリシー・ストアに追加してください。
オンライン・モードで管理ツールからリポジトリを開いて整合性チェッカを実行することで、リポジトリで使用されるアプリケーション・ロールがシステムでプロビジョニングされているかを確認できます。リポジトリおよびアプリケーション・ロールを新しいシステムに移行するたびにこのチェックを実行することをお薦めします。
環境間で少数のアプリケーション・ロールのみを移行する必要がある場合、Oracle WebLogic Serverで組込みポリシー・ストアを使用していれば、ターゲット・システム上のFusion Middleware Controlでそれを手動で入力できます。