各種シナリオと推奨される使用方法¶
Denodo では、開発環境でバージョン管理システム (VCS) を使用する際のワークフローとして次の 3 つを推奨しています。
共有データベースを使用した集中ワークフロー
Virtual DataPort サーバーが 1 つあり、各開発者はこの Virtual DataPort の Administration Tool を使用してこのサーバーに接続します。
プロジェクトごとにデータベースが 1 つあります。Denodo では、1 プロジェクトにつきデータベースを 1 つ持つことを推奨しています。
各プロジェクトの開発者は同じデータベースを使用します。
分散ワークフロー
各開発者が Virtual DataPort サーバーとその Administration Tool のローカルインストール環境を持っています。各ローカルインストール環境は、開発者が管理します。つまり、開発者はそれぞれのローカルサーバーの管理者です。
各開発者は、プロジェクトごとにデータベースを持ち、組織の中央リポジトリに対して、変更のチェックインとチェックアウトを実行します。
すべての開発者が各自の Denodo サーバーの管理者となりますが、このワークフローでは、さらに、jar 拡張機能とロケールマップの変更の調整を行う管理者が必要になります。jar 拡張機能やロケールマップの変更が他のプロジェクトに影響しないようにするためです。
詳細については、「 Best Practices to Manage Global Elements 」 (下記) のセクションを参照してください。
プライベートデータベースを使用した集中ワークフロー
Virtual DataPort サーバーが 1 つあり、各開発者はこの Virtual DataPort の Administration Tool を使用してこのサーバーに接続します。
プロジェクトごとに、プロジェクトマネージャーまたは管理者によって管理される中央のデータベースが 1 つあります。
プロジェクトごとに、管理者がそのプロジェクトの各開発者用のデータベースを作成し、そのデータベースに対する ADMIN 権限 (データベースの管理者の権限) を各開発者に付与します。
プロジェクトの作業時には、各開発者は自分のデータベースに接続します。
タスクを完了したら、開発者は変更をチェックインして、他の開発者がその変更を利用できるようにする必要があります。
VCS ワークフローの選択¶
前述のどのワークフローにも長所と短所があるため、組織の開発環境により適しているのはどのワークフローか見きわめることが重要です。
共有データベースを使用した集中ワークフロー
このワークフローでは、以下に示す、バージョン管理システムの主要な目的を達成できます。
中央リポジトリにエレメントを保存し、すべての変更の履歴を保持する。
個々の変更の作成者を特定できるようにする。
個々のリビジョンを復元する。
他のワークフローと比較したときのこのワークフローの欠点は、同じエレメントに対して複数の開発者によって実行された、競合する変更の検出および解決機能がないことです。その理由は、このワークフローの場合、1 つのプロジェクトで複数の開発者が同じデータベースを使用して作業を行うため、開発者間で同じエレメントを同時に変更しないよう調整を図る必要があるからです。
分散ワークフロー
このワークフローは、上述のような競合を開発者が検出できるようにする必要がある場合に使用します。2 人の開発者が同じエレメントに対して異なる変更を行った場合、2 番目の開発者は、自分の行った変更を VCS にチェックインする際に、そのエレメントがすでに変更されており、競合を解決する必要があることを知ることができます。このワークフローでは、各開発者が Virtual DataPort サーバーをインストールして管理する必要があります。
プライベートデータベースを使用した集中ワークフロー
このワークフローでも、分散ワークフローと同様に競合を検出して解決することができます。分散ワークフローとの違いは、分散ワークフローの場合は各開発者が独自の Virtual DataPort サーバーを持つのに対し、このワークフローの場合は開発者がそれぞれ独自のデータベースに接続しながら、全員が同じVirtual DataPort サーバーを使用して作業することです。
以降のセクションでは、推奨ワークフローのそれぞれについて詳しく説明します。
共有データベースを使用した集中ワークフロー¶
このワークフローは大多数のプロジェクトに適合します。このワークフローでは、1 つのプロジェクトのすべての開発者が同じデータベースを共有します。
次の図は、このワークフローに従った Virtual DataPort サーバーを示しています。
A と B の 2 つのプロジェクトがあります。それぞれのプロジェクトは独自のデータベースを持っています。
このワークフローの詳細は以下のとおりです。
プロジェクトの開始時に、管理者がデータベースを作成して VCS にチェックインします。また、このデータベースにアクセスする権限を開発者達に付与します。
管理者がデータベース全体ではなく、一連のビューに対する
EXECUTE権限とWRITE権限を開発者に付与する場合は、これらの派生ビューによって直接参照されているビューに対するEXECUTE権限も付与する必要があります。そうしないと、ユーザーが変更できるビューのチェックインが失敗する可能性があります。Denodo はVCS へのビューのチェックイン時にそのビューの VQL を取得する必要があり、そのためには、そのビューによって参照されているビューに対するEXECUTE権限をユーザーが持っていなければならないからです。ユーザーがビュー
V1に対するWRITE権限を持っており、このビューによって直接参照されているビューに対するEXECUTE権限は持っていない場合、以下のようになります。ユーザーは V1 を変更できません。
V1 の [Options] ダイアログの設定は変更できます。
V1 の VQL を取得できないため、V1 の [Options] ダイアログで行った変更をチェックインすることはできません。
開発者が基本ビューの変更をチェックインするには、そのビューに対する WRITE 権限を持っている必要があります。これまでは、基本ビューの所有者またはデータベースの管理者である必要がありました。
開発者は、作業を開始してタスクを完了したら、変更を VCS にチェックインします。同じエレメントを同時に変更しないよう開発者間で調整を図る必要があります。
開発者があるビューを変更することで他の派生ビューが無効になる場合 (別のビューで使用されているビューを削除した場合など)、開発者は影響を受ける派生ビューや Web サービスを修正する必要があります。その後、それらすべての変更を含む単一のチェックインを実行します。
開発者が他のビューを無効にするような変更を行ったものの、その開発者には影響を受けるビューを変更する権限がない場合は、影響を受けるすべてのビューを変更する権限を持っている開発者がそれらのビューを修正します。その後、同じ開発者が、ビューの最初の変更と、影響を受けるビューの修正を含む、単一のチェックインを実行します。
すべての変更を単一のコミットに含めることができない場合、一部のリビジョンの VQL が無効になる可能性があります。
上述の項目についてまとめると、開発者達がデータベース全体ではなく、それぞれ異なる一連のデータベースビューにのみアクセスできる場合は、変更のチェックインを階層的に行うことをお勧めします。つまり、下位レベルのエレメント (データソースおよび基本ビュー) を変更できるグループがこれらの変更のチェックインを最初に実行します。次に、中間のビューを変更できるグループが中間ビューの変更をチェックインし、その後、最終的なビューおよび Web サービスを変更できるグループが変更をチェックインします。この方法により、上述の状況を回避できます。
新たな拡張機能が必要な場合、開発者は管理者にその機能をリクエストします。管理者はその機能をインポートし、グローバルエレメントのチェックインとチェックアウト用の新たなウィザードを使用してチェックインします。管理者がその機能をサーバーに追加するとすぐに、すべての開発者がその機能を使用できるようになります。ただし、変更の履歴を保持するために、管理者はその拡張機能を VCS にチェックインする必要があります。
以下の点を考慮してください。
このワークフローの場合、開発者は変更をチェックインする必要はありません。すべての開発者が同じデータベースを使用するため、どの開発者も変更にすぐにアクセスできるからです。ただし、すべての変更の履歴を保持するために、タスクの完了後、変更をチェックインすることをお勧めします。
今後は、前のバージョンに戻すことができるのは、管理者とデータベース管理者のみになります。これは、標準ユーザーが前のバージョンに戻したときに、そのユーザーが実行を許可されていない VQL ステートメントが前のバージョンに含まれていることによって問題が発生するのを防ぐためです。この規則は、データベースのエレメントおよびグローバルエレメントに適用されます。
データベースを前のバージョンに戻す必要があり、そのデータベースバージョンで前のバージョンのグローバルエレメントが必要な場合、管理者は最初にグローバルエレメントを前のバージョンに戻してから、データベースのエレメントを前のバージョンに戻す必要があります。手順の詳細については、下記の「 グローバルエレメントの管理のベストプラクティス 」を参照してください。
このワークフローでは、ユーザーがデータベースまたはフォルダをチェックインする際、[Check in] ダイアログに、[Server Explorer] (左側のタブ) に表示されていないエレメント、または同期のマーク (
アイコン) が付いたエレメントが表示されることがあります。これは、ユーザーがデータベースを更新 ([File] > [Refresh] をクリック) した後で、チェックインしようとしているデータベースまたはフォルダで別のユーザーによってエレメントが作成または変更されていた場合に起こります。このワークフローでは、コミットの実行後に、以前は表示されていなかった新しいエレメントが表示されることがあります。コミット後に Administration Tool でデータベースの更新 ([File] メニュー > [Refresh] をクリックした場合と同じ処理) が実行されるからです。最後の更新以降に別のユーザーによってそのデータベースにエレメントが作成された場合、そのエレメントがエレメントツリーに表示されるようになります。
分散ワークフロー¶
これは、複数の開発者が同じエレメントに対して行った競合する変更を検出および解決できるようにする必要のあるプロジェクトにおける推奨ワークフローです。
このワークフローでは、すべての開発者がそれぞれ独自の Virtual DataPort サーバーを持ち、開発者は各自のサーバーの管理者となります。そのため、開発者は何の制限もなくグローバルエレメントを管理できます。
次の図は、このワークフローに従った Virtual DataPort サーバーを示しています。
プロジェクト A と プロジェクト B の 2 つのプロジェクトがあり、それぞれのプロジェクトは独自のデータベースを持っています。
開発者はそれぞれ独自の Virtual DataPort サーバーを持っているため、作業を行うプロジェクトのデータベースのみをチェックアウトする必要があります。
開発者 1 は プロジェクト B の作業のみを行うため、データベース B のみをチェックアウトします。
開発者 2 は プロジェクト A と プロジェクト B の作業を行います。また、テストのみを目的としたバージョン管理対象外のデータベースもあります。
どちらの開発者も、それぞれのデータベースのエレメントが使用するグローバルエレメントを管理します。
分散ワークフロー¶
このワークフローの詳細は以下のとおりです。
プロジェクトの開始時に、プロジェクトのコーディネーターがデータベースを作成し、すべての開発者に通知します。
各開発者は、そのデータベースをチェックアウトし、作業を開始します。
自分の行った作業を他の開発者と共有したい場合、開発者は変更を VCS にチェックインする必要があります。
新たな拡張機能が必要な場合、開発者は管理者にその機能をリクエストします。管理者はその機能をインポートし、グローバルエレメントのチェックインとチェックアウト用の新たなウィザードを使用してチェックインします。その後、管理者はプロジェクトの開発者に通知し、開発者は、グローバルエレメントのチェックインとチェックアウト専用の新たなウィザードを使用して新たなエレメントを取得します。
開発者があるビューを変更することで他の派生ビューが無効になる場合 (別のビューで使用されているビューを削除した場合など)、開発者は影響を受ける派生ビューや Web サービスを修正し、その後、すべての変更を含む単一のチェックインを実行する必要があります。開発者がビューの変更のみチェックインして、影響を受けるビューの修正をチェックインしなかった場合、VCS に保存されている VQL が有効でないと、他の開発者が VCS から変更をチェックアウトするときにエラーになる可能性があります。
また、これは、プロジェクトのあらゆるリビジョンに確実に戻せるようにする方法でもあります。すべての変更を単一のコミットに含めることができない場合は、コミットメッセージでその旨を伝え、将来誰かがそのコミットに戻そうとすることのないようにしてください。
プライベートデータベースを使用した集中ワークフロー¶
これは、利用可能な Virtual DataPort サーバーが 1 つしかなく、かつ同じエレメントに対して複数の開発者によって実行された、競合する変更を検出および解決できるようにする必要のある場合の推奨ワークフローです。
このワークフローでは、開発用の Virtual DataPort サーバーは 1 つだけです。プロジェクトごとに、プロジェクトマネージャーが管理する中央のデータベースが 1 つあり、またそのプロジェクトの各開発者用のデータベースが 1 つずつあります。これらのデータベースはすべて、VCS の同じデータベースを参照しています。
次の図は、このワークフローに従った Virtual DataPort サーバーを示しています。
プロジェクト A と プロジェクト B の 2 つのプロジェクトがあり、それぞれのプロジェクトは独自のデータベースを持っています。
- プロジェクト A の作業は 開発者 1 と 開発者 2 が行います。そのため、このプロジェクトでは、project_a 、 project_a_developer1 、 project_a_developer2 の 3 つのデータベースを使用します。
- プロジェクト B の作業は 開発者 1 だけが行います。そのため、このプロジェクトでは、project_b と project_b_developer1 の 2 つのデータベースを使用します。
プライベートデータベースを使用した集中ワークフロー¶
このワークフローの詳細は以下のとおりです。
プロジェクトの開始時に、管理者が以下のデータベースを作成します。
プロジェクトのメインデータベース (標準データベース): コーディネーターがこのデータベースの管理者となり、このデータベースのすべての変更を定期的にチェックアウトします。データベースを別の環境に昇格する必要がある場合、コーディネーターはデータベースをチェックアウトして、VQL ファイルにエクスポートします。
管理者は、このデータベースを作成し、このデータベースのバージョン管理を有効にして、変更をチェックインします。それにより、リポジトリにデータベースが作成されます。
プロジェクトの各開発者用の 1 つのデータベース: 開発者にデータベースが 1 つずつ割り当てられます。管理者は、それぞれのデータベースに割り当てられる開発者に、そのデータベースに対する「データベース管理者」権限を付与します。これは、ユーザーに割り当てることができる ADMIN 権限です。
各データベースの複製には、[VCS Management] メニューの [Import database] ウィザードを使用することをお勧めします。このウィザードではリポジトリ内の利用可能なデータベースが検出されるため、管理者は検出されたデータベースを選択して、ローカル名を指定するだけで済みます。このローカル名は以下の規則に準拠する必要があります。
<name of the project>_<username of the developer>.
プロジェクトの開発者は、それぞれ独自のデータベースに接続して作業を開始します。
自分の行った作業を他の開発者と共有したい場合、開発者は変更を VCS にチェックインする必要があります。
他の開発者が行った変更を確認するには、それらの開発者によりデータベースがチェックアウトされている必要があります。
開発者は、別のデータベースのビューの派生ビューを作成する必要がある場合、開発者用データベースではなく 標準データベース のビューを参照する必要があります。つまり、 開発者 2 が プロジェクト B の employee ビューの選択ビューを作成する必要がある場合、 開発者 2 は、project_b_developer1 データベースではなく、 project_b データベースの employee ビューの派生ビューを作成する必要があります。他の環境 (テスト環境や QA 環境など) には標準データベースしか存在しないからです。そのため、データベース間の参照は標準データベースを使用して作成する必要があります。
管理者は、作成する派生ビューの元となるビューが属する標準データベースに対する
CONNECT権限とEXECUTE権限を開発者に付与する必要があります。開発者があるビューを変更することで他の派生ビューまたは Web サービスが無効になる場合 (別のビューで使用されているビューフィールドを削除した場合など)、開発者は影響を受けるエレメントを修正する必要があります。その後、すべての変更を含む単一のチェックインを実行します。開発者がビューの変更のみチェックインして、影響を受けるエレメントの修正をチェックインしなかった場合、VCS に保存されている VQL が有効でないために、他の開発者が VCS からこれらの変更をチェックアウトするときにエラーになります。
また、これは、プロジェクトのあらゆるリビジョンに確実に戻せるようにする方法でもあります。すべての変更を単一のコミットに含めることができない場合は、コミットメッセージでその旨を伝え、将来誰かがそのコミットに戻そうとすることのないようにしてください。
新たな拡張機能が必要な場合、開発者は管理者にその機能をリクエストします。管理者はその機能を標準データベースにインポートし、グローバルエレメントのチェックインとチェックアウト用の新たなウィザードを使用して VCS にチェックインします。管理者がその機能をサーバーに追加するとすぐに、すべての開発者がその機能を使用できるようになります。ただし、変更の履歴を保持するために、管理者はその拡張機能を VCS にチェックインする必要があります。
データベースを前のバージョンに戻す必要があり、そのデータベースバージョンで前のバージョンのグローバルエレメントが必要な場合、管理者は最初にグローバルエレメントを前のバージョンに戻してから、データベースのエレメントを前のバージョンに戻す必要があります。手順の詳細については、「 グローバルエレメントの管理のベストプラクティス 」 (下記) を参照してください。
グローバルエレメントの管理のベストプラクティス¶
グローバルエレメントは、特定のデータベースに属さないエレメントです。たとえば、ユーザー、ロール、サーバー設定などです。
このセクションでのグローバルエレメントとは、Virtual DataPort が VCS に保存する 2 つのタイプのグローバルエレメントのみを意味しています。つまり、jar 拡張機能とロケールマップ (i18n マップ) です。
VCS のサポートを使用する際には、以下に示すグローバルエレメントの管理のベストプラクティスに従ってください。
Denodo サーバーの管理者は、以下のような、グローバルエレメントの管理作業を担当する必要があります。
jar 拡張機能のアップロード
ロケールマップ (i18n マップ) の管理
これは、これらのエレメントを共用している他のプロジェクトへの影響を避けるためです。jar 拡張機能と i18n マップを管理できるのは管理者だけです。これらを管理するには、データベースを右クリックして、[VCS] > [Global elements] をクリックします。このメニューから、管理者は jar 拡張機能と i18n マップに対する変更をチェックインできます。
管理者は、グローバルエレメントを作成、変更、または削除したら、その変更を VCS にチェックインする必要があります。それにより、変更の履歴が保持されます。また、分散ワークフローを使用している場合は、開発者が新しいエレメントにアクセスできるようにするためにチェックインが必要になります。
開発者は、グローバルエレメントを作成、変更、または削除する必要がある場合、管理者の 1 人にその操作を依頼する必要があります。
分散ワークフローを使用している場合は、プロジェクトでのグローバルエレメントの変更の調整を行う管理者がグローバルエレメントをチェックインしたら、開発者はそのエレメントをチェックアウトして取得する必要があります。開発者は独自のサーバーを持っているからです。分散ワークフローでは、開発者は自分が使用している Denodo サーバーの管理者でもあるため、グローバルエレメントを正常にチェックアウトできます。
集中ワークフローの場合は、これは不要です。管理者がエレメントを読み込んだ時点から、そのエレメントはすでにサーバーに存在するからです。
データベースを前のバージョンのグローバルエレメントを必要とするバージョンに戻さなければならない場合は、以下の 2 段階の手順でこのプロセスを実施します。
グローバルエレメントを復帰するための新たなウィザードを使用して、グローバルエレメントを前のバージョンに戻します (このウィザードは次の更新で提供されます)。
このウィザードは管理者のみが使用できます。
データベースに依存するエレメントを前のバージョンに戻します。この操作を行うには、すべてのエレメントをチェックインするか、または変更を破棄する必要があります (変更をローカルに維持することはできません)。変更を元に戻すダイアログでは、そのデータベースのエレメントのコミットのみが表示されます。グローバルエレメントや他のデータベースのエレメントのコミットは表示されません。
開発者は、グローバルエレメントに依存するエレメント (拡張機能に含まれているカスタム関数を使用する派生ビューなど) をチェックインできます。
フォルダを作成できるのは、管理者、またはフォルダが作成されるデータベースの管理者だけです。そのため、フォルダは作成後すぐにチェックインすることをお勧めします。
グローバルエレメントはすべてのデータベースで共有されるため、同じ拡張機能の異なるバージョンが必要な場合に問題が発生することがあります。たとえば、 プロジェクト A と プロジェクト B の 2 つのプロジェクトがあり、それぞれのプロジェクトで同じ jar 拡張機能の異なるバージョンが必要な場合があります。もう 1 つの例として、 プロジェクト A を前のバージョンの jar 拡張機能を必要とする前のバージョンに戻す必要があり、プロジェクト B では新しいバージョンの jar 拡張機能が必要な場合があります。これらのシナリオでの対処法として、以下の命名規則を使用することを検討してください。
1 つのプロジェクトでは新しいバージョンの jar 拡張機能を必要とし、もう 1 つのプロジェクトでは古いバージョンの jar 拡張機能を必要とする場合は、新しいバージョンの拡張機能を新しい名前で読み込みます。この新しい名前は、その拡張機能の元の名前の後ろに、その新しバージョンを必要とするプロジェクトの名前を付加したものとします。以後、このプロジェクトの開発者は、既存の jar 拡張機能ではなく、新しい jar 拡張機能を使用する必要があることを知っておく必要があります。
これは、同じライブラリの複数のバージョンが読み込まれないようにする必要がある場合にのみお勧めします。
あるプロジェクトで、別のプロジェクトが使用しているマップを変更する必要がある場合、管理者は新しいマップを作成し、元のマップ名に接尾辞を付加した名前を付けて、開発者が区別できるようにします。
グローバルエレメントに関するその他の情報¶
Virtual DataPort では、jar 拡張機能とロケール (i18n) マップは、すべてのデータベースに共通するグローバルエレメントとして管理されます。これらが個々のデータベースに属さない理由は以下のとおりです。
jar 拡張機能がグローバルなのは、それらが固有のデータベースではなく、Virtual DataPort サーバーの機能の拡張だからです。拡張機能が 1 つのデータベースにリンクしていたとすると、それらの機能を何度も読み込まなければなくなることが頻繁に起こります。同じ拡張機能を複製するとなると、それらの拡張機能の保存と使用に必要なリソースが増えることになります。
ロケール (i18n) マップがグローバルなのは、通常、これらのマップはすべてのデータベースで使用されるためです。したがって、マップを 1 つ作成すれば、すべてのデータベースでこのマップを使用でき、すべてのデータベースにこのマップを複製する必要はありません。
管理者は、グローバルエレメントの管理と VCS へのチェックインを担当します。
これらの問題を回避するために、Denodo では、i18n マップと jar 拡張機能の管理のための以下の機能を提供しています。
管理者のみが使用できる、グローバルエレメントのチェックインとチェックアウト専用のウィザードがあります。このウィザードを開くには、データベースを右クリックして [VCS] > [Global elements] をクリックします。
開発者は、グローバルエレメントを VCS にチェックインすることも VCS からチェックアウトすることもできません。これは以下のことを意味します。
開発者が変更を VCS にチェックインする場合、グローバルエレメントの変更はコミットに決して含まれません。グローバルエレメントが管理者によって変更されている場合も同様です。
開発者が VCS から変更をチェックアウトする場合、Virtual DataPort サーバーはこれらのエレメントの変更を無視します。
(グローバルエレメントではなく) データベースのエレメントを元に戻すウィザードでは、そのデータベースのエレメントの変更を含むコミットのみがリストに表示されます。
上記の 1 の手順で説明したウィザードが使用されるため、グローバルエレメントとデータベースのエレメントの両方を変更するコミットが実行されることはありません。コミットにより変更されるのは、どちらか一方のタイプのエレメントのみです。
開発環境からテスト環境や本番環境への変更の昇格¶
開発チームの作業が完了したら、次はテストを行います。
データベースまたは一連の変更を開発サーバーからテストサーバーに昇格するときの最善の方法は、Solution Manager を使用して リビジョンを作成する ことです。その後、そのリビジョンをテスト環境にデプロイします。新しいビューが予期したとおりに動作することをテストで確認できたら、同じリビジョンを本番環境にデプロイします。以前のバージョンの Denodo では、推奨されるエレメントの昇格方法は、Denodo のスクリプト「export」および「import」を呼び出すスクリプトを作成することでしたが、Solution Manager を使用した方法のほうが便利です。以下にその理由を示します。
Solution Manager の GUI では、開発者は昇格するエレメントの選択をより容易に行えます。
Solution Manager には、1 つの Virtual DataPort サーバーだけでなく、Virtual DataPort サーバーのクラスタにもエレメントを昇格できる機能があります。
リビジョンが永続化されるため、後でリビジョンをレビューでき、変更の履歴を保持することもできます。
...
Solution Manager ではなくスクリプトを使用したデータベースの昇格¶
Solution Manager ではなくスクリプト「export」および「import」を使用して変更を昇格する場合は、管理者が以下の手順を実行する必要があります。
プロジェクト (例では、"project A" または "project B") の中央のデータベースに接続し、VCS から変更をチェックアウトします。
[Export environment specific properties separately] オプションを指定して、データベース全体をファイルにエクスポートします。
生成されたプロパティファイルを編集して、テスト環境に合うよう値を調整します。たとえば、JDBC データソースの URL を、テストデータベースと新しい資格情報などを参照するように変更することができます。
以後に行うデータベースの昇格では、管理者は前に作成したプロパティファイルを使用できます。管理者が VQL ファイルをインポートするときに、プロパティファイルに一部のプロパティが含まれていない場合、インポートプロセスは失敗し、サーバー上での変更は一切行われません。その場合、インポートプロセスから、不足しているプロパティのリストが返されるため、管理者はそれらのプロパティをプロパティファイルに追加することができます。
VQL ファイルをプロパティファイルとともにテストサーバーにインポートします。
その後、ユーザーは作成したビューのテストを開始できます。
このプロセスに関連する推奨事項は以下のとおりです。
元の環境から別の環境へデータベースを昇格するには、Denodo Platform のスクリプト「import」および「export」を呼び出すスクリプトを作成します。
開発環境からテスト環境へのデータベースの昇格と、テスト環境から本番環境への昇格のプロセス (スクリプトなど) は同じでなければなりません。同じであれば、テスト環境への昇格時に、プロセスが正常に動作することを確認できます。
変更を環境間で (たとえば、開発環境からテスト環境に) 昇格するときには、一連のビューだけではなく、データベース全体を昇格することをお勧めします。そうすることで、一部の変更の昇格が漏れるのを回避できます。
データベースをテスト環境から本番環境に昇格するときには、VCS ではなく VQL ファイルを使用します。VCS リポジトリからのデータベースのインポートは、VQL ファイルからのインポートよりも時間がかかるためです。
上記の推奨事項に基づき、データベースを開発環境からテスト環境に昇格するときにも VQL ファイルを使用することをお勧めします。それにより、データベースを開発環境からテスト環境に移行するときに、環境間のデータベースの移行のスクリプトが正常に動作することをテストして確認することができます。
複数の VCS 環境の使用¶
複数の VCS 環境を定義することが有効なのは、次のような場合です。
開発チームが地理的に分散している。たとえば、ロンドンに Denodo 開発者チームが 1 つあり、別の Denodo 開発者チームがデンバーにある場合などです。
さらに、それぞれの場所に、開発者が使用しているデータソースのレプリカがある。たとえば、ロンドンに Oracle データベースが 1 つあり、デンバーに別の Oracle データベースがあり、それらのビューやテーブルは同じ (ただし、そのデータは異なる可能性があります) 場合などです。
また、それぞれの場所のチームは、その場所のデータソースを参照する必要がある。
組織がこれらの条件を すべて満たしているわけではない 場合、「development」という名前の環境を 1 つだけサーバーに作成することをお勧めします。