Subversionとの統合

ソフトウェア要件

EDQでは、Subversion 1.6、1.7および1.8との統合がサポートされます。Subversionの詳細は、http://subversion.apache.org/にあるApache SubversionのWebサイトを参照してください。

注意:

EDQでは、現在、Subversion 1.6、1.7および1.8との統合のみがサポートされます。他のバージョンと統合しようとすると、エラーが発生します。

EDQと統合するSubversionサーバーは、次の前提条件を満たしている必要があります。

Hypertext Transfer Protocol (HTTP)およびDistributed Authoring and Versioning (DAV)アクセスのサポート。
コミット時の認証が必要。
チェックアウトまたは更新時の認証は不要。

Subversionを構成情報のストアとしてEDQと統合する場合、次の制限が適用されます。Subversionを使用した統合バージョン・コントロールを構成する前に、次の点を考慮してください。

ディレクタ・インタフェースまたはSubversionサーバーで開かれているアイテムを更新したり、元に戻すことはできません。
プロジェクトが一度バージョン・コントロールの対象になると、プロジェクト名を変更することはできません。これは、プロジェクトの参照プロセッサ名の重複を避けるために非常に重要です。
プロジェクトを削除してもSubversionリポジトリからは削除されません。
名前の一致では、大/小文字の区別はありません。

統合アーキテクチャの理解

EDQサーバーは、Subversionサーバーを構成情報のストアとして認識するように構成できます。

注意:

この例での構成情報とは、プロジェクトやシステム・レベルのデータなど、ディレクタUIを使用して管理される情報を意味します。

標準のEDQインスタンスでは、プロジェクト情報などの構成情報は、ディレクタ・データベースに格納されます。

次の図は、Subversionと統合されたEDQインスタンスを示しています。

注意:

ディレクタ・データベースは、アプリケーションにより問合せできるように正規化されたファイル管理の構成から導出されるデータを格納するため、引き続き必要です。

Subversionリポジトリで管理および格納されるEDQ構成ファイルがある場合、Subversionクライアントを使用してそれをコミットするか、それにアクセスできます。EDQには埋込みSubversionクライアントが含まれるため、一度EDQとSubversionとの統合が有効になると、構成変更を制御するSubversionクライアントの操作は、ディレクタで直接実行できます。

リポジトリの設定

構成の最初の手順では、チェックアウトしたデータが格納されるワークスペース・ディレクトリを作成します。

ディスク上の適切な場所にディレクトリを作成し(C:\MyRepositoryなど)、それをSubversionに追加してコミットします。
新しく作成したディレクトリ内で、次のSubversionプロパティを設定します。
```
svn propset edq:systemversion 12.1.3:base .
```
次の変更をSubversionにコミットします。ワークスペースに次のプロパティが表示されます。
```
svn proplist -v .
Properties on '.':
  edq:systemversion
    12.1.3:base
```
新しく作成したディレクトリ内に次のサブディレクトリを作成します。
- Data Stores
- Hidden Reference Data
- Images
- Projects
- Published Processors
- Reference Data
これらのディレクトリを追加してコミットします。これで、リポジトリはEDQ用に正しく設定されました。

前述の手順は、1つのリポジトリに対して1回実行すれば済みます。残りの変更は、すべてEDQを使用して実行できます。

SubversionでのEDQの構成

Subversionは、EDQのフレッシュ・インストールと統合する必要があります。

注意:

EDQインスタンスをSubversionと統合すると、既存のものを含めすべての構成情報が失われます。この情報を保持するには、最初にそれをパッケージ化してエクスポートする必要があります。詳細は、「既存の構成情報の保持」を参照してください。

注意:

単一のEDQインスタンスのワークスペース間で移動することは困難であるため、EDQのインスタンスごとに1つのワークスペースを割り当てることをお薦めします。

新規EDQインストールの構成

新しいEDQインストールを構成するには、次の手順を実行します。

アプリケーション・サーバーを停止します。
Subversionからワークスペースをチェックアウトします。ツリー全体をチェックアウトする必要はありません(ワークスペース・ディレクトリ自体が必要です)。
ORACLE_HOME/user_projects\domains\domains\edq_domain\edq\oedq.local.homeディレクトリのdirector.propertiesファイルを編集します。
ディレクトリ・パスを、ルート・ワークスペース・ディレクトリの絶対パスに置き換える次の行を追加します。次に例を示します。
```
sccs.workspace = C\:\\MyRepository
```
注意:

この例では、バックスラッシュが含まれるパスのコロン(:)およびバックスラッシュ(\)文字をエスケープする必要があります。バックスラッシュが含まれるパスの空白文字もエスケープする必要があります。
EDQサーバーを起動し、次にディレクタを起動します。
Main0.logファイルの一番上で、追加したSCCSワークスペースの名前をリストしたINFOメッセージを確認します。次に例を示します。
```
INFO: 02-Sep-2013 10:05:21: SCCS workspace is C:\MyRepository
```
このメッセージの後にエラーがなければ、EDQはSubversionを使用するように構成されています。エラーがある場合、「エラーのトラブルシューティング」で適用可能な解決策を参照してください。

既存の構成情報の保持

前述のとおり、Subversionは、EDQのフレッシュ・インストールと統合する必要があります。そのため、EDQインストールの既存のプロジェクトや他の構成アイテムは、次のように統合を開始する前にパッケージ化し、後で新しいインストールにインポートする必要があります。

現在のEDQインスタンスに含まれるすべての構成アイテムをDXIファイルにパッケージ化します。
Subversion統合を有効にしてEDQの新しいインスタンスをインストールします。
新しいインスタンスにDXIファイルをインポートし、Subversionワークスペースにそれらのファイルをコミットします。
構成アイテムがすべて有効で、適切に動作することを確認します。

構成のインポート後に、データ・ストアのすべてのパスワードを再入力する必要があります。
前のインスタンスの使用を中止します。

統合要素の理解

Subversionが有効な状態でEDQが統合されると、ディレクタ・アプリケーション内に次のインタフェース要素が表示されます。

プロジェクト・ブラウザにSubversionのステータス・アイコンが重ねて表示されます(プロジェクト・ブラウザには、ノードの3つのSubversionステータスを示すために使用される2つのアイコンがあります)。
- アイコンなし - ノード(およびそのサブノード)はすべて最新です。
- 緑色のアイコン - このノード(およびそのサブノード)には変更があります。
- 青色のアイコン - このノード(およびそのサブノード)は、新しいものであるか、現在バージョン・コントロールの対象ではありません。
たとえば、次の図は、使用中の2つのアイコンを示しています。「参照データ」ノードは、そのサブノードの1つに変更があるため、変更されています(緑色のアイコン)。「参照データ」の新しいアイテムである「ビジネス用語」が追加され、青色のアイコンでマークされています。
「バージョン・コントロール」タブ - 「プロパティ」ダイアログ(プロジェクト・ブラウザのアイテムを右クリックして「プロパティ」を選択して表示)に、最終更新日時、Subversionのリビジョン、現在有効であるかどうかといったアイテムの状態を記述した「バージョン・コントロール」タブが含まれるようになりました。
バージョン・コントロールの新しいコンテキスト・メニュー - プロジェクト・ブラウザの右クリック・メニューに、バージョン・コントロール・オプションが含まれるようになりました。選択すると、Subversionのオプションを含んだサブメニューが表示され、そのアイテムの更新、コミット、回復、比較またはログ表示を行うことができます。これらのオプションは再帰的です。たとえば、1つのプロセスを対象にログの表示を実行すると、そのプロセスのログのみが表示されますが、「プロセス」ノードを対象にログの表示を実行すると、すべてのプロセスの変更が表示されます。
コミット時のコメントおよび資格証明のダイアログ - リポジトリに変更をコミットすると、ディレクタに「コミット・ログ」ダイアログが表示されます。

このダイアログの「コメント」フィールドに、変更を説明するコメントを入力できます。または、現在のセッションで前に入力したコメントのリストからコメントを選択して、自動的にフィールドに移入することもできます。

現在のセッションでまだ自分の資格証明を入力していない場合、「コミット・ログ」ダイアログで「OK」をクリックすると、ディレクタに「バージョン・コントロール資格証明」ダイアログが表示されます。

このダイアログで、Subversionリポジトリ用のユーザー名とパスワードを入力し、「OK」をクリックします。

デプロイメントの例の確認

次に、デプロイメントの例を示します。この図には、4つのEDQインストールに対応する構成の3つのコピーを保持する1つのSubversionサーバーがあります。

構成のコピーは次のとおりです。

trunk - すべての開発作業が実行される従来の場所。構成の新しい機能はここで開発され、保存されます。
branchesおよびUAT - このブランチは、UATテストのための構成のコピーを表します。
branchesおよびproduction - このブランチは、構成の本番コピーを表します。

構成を格納するためにSubversionサーバーを使用する4つのEDQインストールは、次のとおりです。

既存のプロジェクトの設計作業とメンテナンスが実行される2つの開発ラップトップ。
ユーザー受入れテストの変更のためのUATサーバー。
本番環境の実行のための本番サーバー。

このデプロイメントの例では、ラップトップ・ユーザーは、各自のラップトップで個々のプロジェクトの構成を開発し、"trunk"のSubversionリポジトリに変更をコミットします。開発者が連携してプロジェクトを開発する環境では、各自のローカル・インストールを定期的に更新して、他の開発者による変更を取得します。

ある時点で、開発は、テストのためにUATにリリースする必要がある段階まで到達します。リリース・マネージャは、必要なプロジェクトをSubversionサーバーの"trunk"から"UAT"にコピーします。

たとえば、次のSubversionコマンドを使用できます。

svn cp -m"Release Project X to UAT" http://svn/repos/config/trunk/ProjectX http://svn/repos/config/branches/UAT

テスト・マネージャは、UATサーバーのプロジェクトを更新して、新しい構成をEDQサーバーにロードします。一定の期間、テストが続けられます。検出された問題は、UAT環境で修正され、Subversionリポジトリにコミットして戻されます。

UAT環境が受入れ可能なテスト・レベルに到達したら、リリースに昇格されます。この実行方法は、開発からUATへのリリースとほぼ同じです。必要なプロジェクトがバージョン・コントロール・リポジトリ内でコピーされ、本番サーバーがこの構成を使用するように更新されます。

エラーのトラブルシューティング

原因と解決策がわかっている次のエラーが発生することがあります。

エラー	原因と解決策
`構成データベースがワークスペースと互換性がありません`	データベースが異なるワークスペースで使用されました。このエラーは、通常、Subversionバージョン・コントロールが有効になる前に操作がEDQで実行されると発生します。ディレクタ・データベースを削除して再作成する方法と、EDQを再インストールする方法の2つの解決策があります。
`URLに対してra_localセッションを開くことができません`	これは、無効なリポジトリにファイルをコミットしようとした場合に発生することがあります。EDQ統合は、ファイルベースのリポジトリ(`file:///`または`C:\example`で始まるリポジトリ)とは互換性がありません。リポジトリに対するhttp://の完全宣言パスを作成する必要があります。