マルチユーザー開発環境の概要

MUDは、リポジトリ・モデル内の相互関係および依存性が複雑であっても、開発者のチームによる任意のサイズのプロジェクトで並列作業を実現できる機能のセットです。

次の処理を実行できます。

リポジトリ・ファイルのサブセットへの分割
- リポジトリが大規模な場合、ユーザーは管理可能なサブセットで作業できます。
- 各開発者またはチームでサブセットごとに独立にテストできます。
- ブランチ・サブセットをチェックアウトした後でマージが管理しやすくなります。
- 独立のセマンティック・モデルを開発用のセキュアなブランチに分割できます。
段階的な開発、テストおよび移行
ユーザーの変更間の競合に対処するサブセットおよびブランチのマージ
変更を終えてパッケージ化されたBIアプリケーションへのOracle更新の適用
個別に開発されたアプリケーションの単一のリポジトリへのマージ
履歴ログおよび監査情報へのアクセス
過去のリポジトリ状態へのロールバック

マルチユーザー開発機能には、その他にも次のような有用な機能があります。

マスターへのマージの調整(元のリポジトリ・ファイルの追跡など)
ロックを使用した確実な更新
変更のログへの記録
破損が発生する可能性のある各操作の前の、リポジトリの自動バックアップ

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

マルチユーザー開発環境のタスク・フローについて

開発環境での複数のユーザーによる作業の基本について学習します。

複数のユーザーでの基本的な作業フローは次のとおりです。

開発者は、「初期」物理レイヤーおよび基本ファクトおよびサブジェクト・エリアを定義します。これにより、MUDプロジェクトをアンカーするためのいくつかの基本オブジェクトを指定します。
MUD管理者はプロジェクトを定義し、RPDをメイン・ブランチのMUDディレクトリに配置します。

注意:
マスター・リポジトリが格納されるMUDディレクトリは、Oracle BIサーバー・ローカル・リポジトリ・ディレクトリと同じにすることはできません。
これで、開発者は1つ以上のプロジェクトをチェックアウトして、開発作業を実行し、変更をMUDディレクトリに公開することでマスターにマージできます。
その間に、他の開発者は、同じプロジェクトまたは別のプロジェクトをチェックアウトして開発作業を行います(プロジェクトは、サブセット用のものであり、セキュリティを適用するためのものではありません)。公開手順では3方向マージを使用するため、ユーザーは変更のチェックアウト、開発、公開を任意の順序で実行できます。複数のユーザーによる1つのオブジェクトに対するプロパティの変更もマージできます。ユーザー間で競合が発生した場合、3方向マージ機能では開発者がどのオブジェクトを保持するのかを選択できます。競合の回避および解決にはユーザー間のコミュニケーションが重要であり、そのような競合を回避するために、管理プロセスによって主要なオブジェクトの所有権が割り当てられるようにする必要があります。
開発フェーズを完了したら、MUD管理者はコンテンツをテスト・システムに移行できます。チェックアウト、不具合の修正、公開および再テストの順に何回か繰り返す場合があります。リポジトリがテスト・フェーズに合格したら、MUD管理者はそれを本番環境に移行できます。
MUD管理者は、複数の開発ブランチを大きなMUDプロジェクトとして作成および管理できます。ブランチは1つの開発チームのみで作業するように保護できます。ブランチは、独自の委任MUD管理者により、メインとして再帰的に処理することもできます。

マルチユーザー開発のプロジェクトについて

マルチユーザー開発機能は、プロジェクトというメタデータ・オブジェクトの周辺で構築されます。プロジェクトとは、マスター・リポジトリからのチェックアウト、およびその後のマージおよび公開までの単位です。

マスター・リポジトリが大規模になると、プロジェクトは開発者がチェックアウトして作業できる程度の管理可能なサイズのサブセットになります。これは、整合性チェッカ(コンパイル時のコードのチェックのようなものです)を実行して、Oracle BIサーバー上でアンサーなどのクライアントにより実行時にそれをテストできるように、自己完結型に設計されています。結果に満足であれば、それをマスター・リポジトリにマージしなおして、大きなアプリケーションの一部にすることができます。一方、履歴はログに記録され、リポジトリ・バックアップは主要な時点で自動的に作成されます。

管理ツールのMUD機能では、ファイングレイン開発者プロジェクトに対してこのフローを合理化します。同様に、スーパーセット・プロジェクトでもブランチの管理およびマージを合理化します。

プロジェクト・サブセットには、メタデータ・オブジェクトのセットが含まれます。オブジェクトの最小セットを明示的に含めるようにプロジェクトを定義しますが、その他の多数のオブジェクトは暗示的に含まれます。オブジェクトを暗示的にプロジェクトに追加することで、プロジェクト管理タスクが単純化されます。

次のオブジェクトは、MUD管理者によりプロジェクトのメンバーとして明示的に指定されます。

論理ファクト表
プレゼンテーション・レイヤーのサブジェクト・エリア
アプリケーション・ロール
ユーザー(ただし、RPDロジックでアプリケーション・ロールのみを使用することをお薦めします)
初期化ブロック
変数

その他すべてのオブジェクトはプロジェクトに暗示的に含まれており、チェックアウト処理時に管理ツールで表示されます。次に例を示します。

明示的に定義されたオブジェクトの子孫。たとえば、論理ファクト表が明示的に含まれる場合、そのすべての論理列もプロジェクトに暗示的に含まれます。
選択された論理ファクト表に結合された論理ディメンション表および結合オブジェクト自身。
含まれている論理ファクト表およびディメンション表の論理表ソース。
プロジェクトに含まれる論理表にマップされた物理表およびそれらの間の結合。
マーケティング・ターゲット・レベルおよびリスト・カタログ。

明示的に定義されたオブジェクトのリストにあるオブジェクトは、暗示的に含まれる場合もあります。たとえば、論理列の式に変数が含まれる場合、MUD管理者が明示的にそれを追加しなくても、その変数はプロジェクトに暗示的に含まれます。

プロジェクトは重複しても問題ありません。1つのプロジェクトに表示されるオブジェクトが、別のプロジェクトにも表示されても問題ありません。たとえば、独立したセマンティック・モデルごとに全体的なプロジェクトを作成するとともに、個別の開発作業ユニットをチェックアウトするために、各独立モデル内により小さいプロジェクトを作成することを好む顧客が存在します。複数のプロジェクトを同時にチェックアウトし、より大きなセットのメタデータで作業することもできます。

詳細は、プロジェクトの設定も参照してください。

ブランチの作成方法

ブランチ、サイド・ブランチおよび委任管理ブランチの作成方法について学習します。

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

メイン・ブランチの作成方法

最終的なマスター・リポジトリは、通常、メイン・ブランチでソースが管理され、すべてのブランチ、さらに最終的にはすべての開発プロジェクトは、そこからチェックアウトします。

通常、メイン・ブランチは本番でリポジトリをステージングします。つまり、コンテンツを本番に移行するには、それをメイン・ブランチに移行してから、メイン・リポジトリを本番システムに移行します。

同様に、本番の不具合を修正するには、通常、開発者はメイン・ブランチからチェックアウトします。開発者は不具合を修正すると、それをテストおよび本番への移行用のメイン・ブランチにマージしなおします。一方、サイド・ブランチの並列開発には影響しません。

MUD管理者としてメイン・ブランチを作成するには、まず共有ディレクトリを作成して、マスター・リポジトリ・ファイルをそこにコピーする必要があります。ディレクトリはWindowsまたはUNIX上のいずれに配置してもかまいませんが、UNIX共有の場合はWindowsユーザーがアクセスできるようにする必要があります。

適切な開発者のみにアクセスを許可するように共有上にセキュリティを設定します。要件に応じて、メイン・ブランチ・マスター・リポジトリではなく、サイド・ブランチ・マスター・リポジトリのみに開発者のアクセスを許可することもできます。

これが新規プロジェクトの場合、一般的には、ブランチ・プロジェクトに容易に分割できる初期コンテンツでリポジトリをシードするように開発者に指示します。

サイド・ブランチの作成方法

ブランチを使用する場合、スーパーセットMUDプロジェクトで開始して、MUDチェックアウト、マージおよび公開機能を使用することをお薦めします。そこで、個々のユーザーまたはサブブランチでファイングレイン・プロジェクトを使用してブランチ・マスターからチェックアウトします。この機能のMUDを使用すると、チェックアウト・ポイントで自動バックアップが提供され、元のリポジトリが追跡されて正しいマージが確保され、ユーザーの介入が少なくて済む、より楽観的なマージの想定を使用して、履歴およびロールバックを使用できます。

MUD管理者としてサイド・ブランチを作成する手順は次のとおりです。

メイン・マスター・リポジトリで、ブランチに必要なすべてのコンテンツを抽出するプロジェクトを作成します。次のガイドラインに従ってプロジェクトを作成します。
- リポジトリにメタデータがほとんど(またはまったく)設計されていない場合、プロジェクトをアンカーできるコンテンツでそれをシードすることをお薦めします。そうすることで、論理ファクト表のサポートに必要な物理コンテンツをプロジェクトで抽出しやすくなります。通常は、少なくともいくつかの代表列が含まれる1つ以上の論理ファクト表を作成するということになります。列はファクト表のサポートに必要な物理表および結合にマップする必要があります。最後に、プロジェクトを作成して、それに属するオブジェクトを定義します。
- コンテンツがすでに存在している場合、プロジェクトを作成し、そのブランチで必要なオブジェクトを定義します。ブランチは、必要に応じて他のプロジェクトと重複することができます。
- また、チェックアウト用に空のプロジェクトを作成することもできます。ただし、開発者がそれをチェックアウトする場合、プロジェクトに暗黙的に追加する必要があるすべての物理オブジェクトは、変更を公開する前に論理ファクト表にマップされるようにする必要があります。同様に、開発者は変更を公開する前にディメンションが結合されてそれが確実に組み込まれていることを確認し、サブジェクト・エリア、変数、初期化ブロック、アプリケーション・ロールおよびユーザーを明示的に追加する必要があります。この方法は、プロジェクトをシードしてからそれを定義する方法よりエラーが発生しやすくなります。
- 通常、本番などの環境の接続プールは、保護される必要があります。マスター・リポジトリの接続プール設定は、必ず開発者がアクセスできるようにします。通常、開発者はそのローカル・テスト・データベースに適合するように設定を変更します。変更を公開するときには、マスター・リポジトリでの設定の上書きを回避するため、接続プールおよびデータベース設定はマージされません。
  
  本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスの「テスト環境から本番環境への移行」を参照してください。
ブランチのMUDディレクトリを作成します。各ブランチには、それぞれ独自のMUDディレクトリを持つ必要があります。そのブランチで作業する開発者のみがそれにアクセスできるように権限を設定します。
開発者が他のチームに属するメタデータを参照できないように、ブランチ権限をプロジェクト・サブセットと組み合せて使用することができます。あるチームに関連するメタデータのみが抽出されるように、プロジェクトを注意深く設計します。チームで、異なるビジネス・モデル、サブジェクト・エリア、物理モデル、変数、初期化ブロックおよびアプリケーション・ロールを使用している場合、この目標は最も実現しやすくなります。

また、ブランチの命名および採番に一貫したシステムを使用することもお薦めします。
「ファイル」→「マルチユーザー」→「チェックアウト」を選択して、ブランチ・プロジェクトをチェックアウトします。これは、ローカル・リポジトリ・ディレクトリやその他のディレクトリにチェックアウトできます。
リポジトリをブランチMUDディレクトリにコピーします。これは、マスター・リポジトリとして機能します。
開発者がブランチからチェックアウトするためのファイングレインMUDプロジェクトを定義します。開発用のブランチの準備ができたことを開発者に通知します。
プロジェクト計画に基づいて、開発者が開発およびユニット・テストを完了すると、その変更の最終マージおよび公開を実行します。
フェーズで計画されたすべてのコンテンツの変更が公開されると、ブランチ・プロジェクトに統合テストを実行する準備が整います。これを実行するには、ブランチ・マスター・リポジトリ・ファイルをテスト環境に移行します。不具合が見つかると、割り当てられた開発者は適切なプロジェクトをチェックアウトして、不具合を修正してから、メタデータをテストします。変更を公開したら、ブランチ・リポジトリを再度テスト環境に移行します。このブランチ・プロジェクトは他のブランチの開発作業に影響することも影響されることもなくテストできます。
統合テストが完了すると、ブランチは本番にプロモートする準備が整います。ユーザーが変更できないように、ブランチ・マスター・リポジトリをブランチ共有ディレクトリから削除します。それをローカル・リポジトリ・ディレクトリにコピーしなおして、管理ツールを使用してそれをメインにマージします。これでメインは統合テストおよび本番に移行する準備が整います。
一般的には、MUD管理者は再度ブランチをチェックアウトして、次の開発フェーズ用のブランチ・リポジトリを共有ディレクトリに配置します。チェックアウト中は、他のブランチからの変更またはメイン・ブランチからの不具合の修正は、ブランチ・リポジトリで取得されます。

委任管理ブランチの作成方法

ブランチを使用して、メタデータ・サブセットを管理および保守する組織にそのローカル管理を委任できます。そのためには、ブランチMUD管理者をブランチに割り当てます。ブランチMUD管理者はメインMUD管理者と同じロールを実行します。

メタデータが他のグループと重複しないような独立のセマンティック・モデルでは、このアプローチが最適に機能します。

委任ブランチMUD管理者は、詳細ブランチのプロジェクトの定義や開発者用のファイングレイン・プロジェクトの作成などを含め、メイン・ブランチ管理者と同じタスクを実行します。

メインMUD管理者として委任管理ブランチを作成する手順は次のとおりです。

メインMUD管理者およびメインMUD管理者の代替要員のみがアクセス権を持つように、メインMUDディレクトリに権限を設定します。
前の項で説明されているように、ブランチMUDプロジェクト、ブランチMUDディレクトリ、およびチェックアウトされたブランチ・マスター・リポジトリを作成します。
メインMUD管理者および委任ブランチMUD管理者がアクセス権を持つようにブランチMUDディレクトリにセキュリティを設定します。
ブランチ管理者は、詳細ブランチのプロジェクト、および開発者用のファイングレイン・プロジェクトを定義します。必要に応じて、ブランチ管理者は開発イニシアティブの委任ブランチ以外の追加ブランチを、開発者がそのリポジトリにチェックアウトできるように権限を設定してデプロイします。
個々の開発者は、メイン・ブランチへのアクセスが許可されていないため、委任ブランチMUDディレクトリからチェックアウトして本番の不具合を修正します。
開発者がすべての変更を公開したら、ブランチ管理者は統合テスト用の委任ブランチにそれらのブランチをチェックインします。
統合テストが完了した後に委任ブランチを本番にプロモートするには、メインMUD管理者は次の2つの手順を実行します。
1. 委任ブランチ・リポジトリ共有ディレクトリからブランチ・マスター・リポジトリを削除して、管理ツールを使用してそれをメイン・ブランチにチェックインしなおします。
2. メイン・ブランチ・マスター・リポジトリを本番に移行します。
通常、メインMUD管理者はブランチを再度チェックアウトして、次の開発フェーズ用の委任ブランチ共有MUDディレクトリにブランチ・リポジトリを配置します。ブランチ管理者は次のレベルのブランチをチェックアウトしてブランチ共有MUDディレクトリにリポジトリを配置することで、開発者がファイングレイン・プロジェクトをチェックアウトして作業を開始できるようにします。

使用できるマージ・ユーティリティ

様々な状況や環境に対して最適化される様々なマージ・ツールがあります。

使用するマージ・アプローチおよびユーティリティを決定する場合、WindowsまたはUNIXシステムでタスクを実行する必要があるかどうかを検討する必要があります。また、セマンティック・モデルに加えた変更をマージする必要があるかどうか、様々な開発の取組みから2つのセマンティック・モデルを組み合せる必要があるかどうかなどの要件も検討する必要があります。

重要

Oracle BI EEツール(nqcmd、biserverxmlcli、comparerpdなど)を使用するときには、SQLが受け入れる形式と一致するように入力を編集する必要があります。たとえば、XMLコンテンツには一重引用符を含めないようにします。

この表は、様々な要件を満たすマージ・アプローチおよびツールを示しています。

要件	マージ・アプローチ	使用するツール	プラットフォーム
チェックアウトされたMUDプロジェクトをマスター・リポジトリにマージしなおすチェックアウトされたMUDプロジェクトをメイン・ブランチ・マスター・リポジトリにマージしなおす	3方向マージ	MUDマージ	Windows
MUD以外のブランチを組み合せて、メイン・ブランチに変更しなおす	3方向マージ	リポジトリ・マージ・ウィザードで、完全なマージを使用します。	Windows
Oracle更新XMLパッチをカスタマイズされたデプロイ済のBIアプリケーションに適用する開発で作成した更新XMLパッチをデプロイされたリポジトリに適用する	3方向マージ	パッチ・マージを選択したリポジトリ・マージ・ウィザードで、Patchrpdユーティリティを使用します。	Windows すべて
非結合の論理コンテンツと潜在的なID競合の組合せ	2方向マージ	リポジトリ・マージ・ウィザードで、ブランクのオリジナルを選択します。	Windows
開発者によってあらかじめ競合がないことが保証されている非結合のコンテンツを組み合せる(すべてで実行)	挿入-更新-削除	`biserverxmlexec -B` `biserverxmlcli`(オンライン) XMLのコピー/貼付け	すべて
開発者によってあらかじめ競合がないことが保証されている非結合のコンテンツを組み合せる(Windowsのみ)	挿入-更新-削除	管理ツールのツール・オブジェクトのコピー/貼付け管理ツールでのリポジトリからのインポート(非推奨)	Windows

マージの詳細は、リポジトリのマージを参照してください。