チーム環境でのデータベースの作成と配置の概要
Team Edition for Database Professionals を使用すると、バージョン管理されたデータベース プロジェクトを使用して、データベースの変更を開発チームが管理できます。チームのデータベース管理者 (DBA: database administrator) ロールを務める場合、そのプロジェクトを作成し、実稼働サーバーからスキーマをインポートし、データベース設定を構成し、テスト データ生成用の計画を設定します。プロジェクトおよびその設定をチームの他のメンバと共有できるようになったら、プロジェクトに関連付けられたファイルをバージョン管理します。
データベースで作業する開発者またはテスト担当者の場合、現在のバージョンのデータベース スキーマをバージョン管理システムからチェックアウトし、分離開発環境、つまりサンドボックスで変更を行います。次に、チームの他のメンバに影響を及ぼさずに、隔離された開発環境で変更をテストできます。変更が完了したら、ファイルをビルドし、テスト サーバーに配置できるように、ファイルをバージョン管理システムにチェックインして戻します。チームの他のメンバは、バージョン管理にチェックインされたバージョンに同期化することによって、その変更を取り込むことができます。
データベース プロジェクトのセットアップ
チーム環境では、DBA ロールを務める場合、チームのプロジェクトをセットアップし、各チーム メンバが同じプロジェクトを使用しながら、自分の分離開発環境で作業できるようにします。プロジェクトをセットアップするには、通常、次の一連のアクションを実行します。
データベース プロジェクトを作成します。通常、この手順は次の手順と連携して実行します。
データベース プロジェクトのスキーマを確立します。ほとんどの開発作業は、既存データベースから取りかかります。その場合、そのデータベースからデータベース プロジェクトにスキーマをインポートできます。この手順では、ソース データベース (運用データベースのことが多い) へのアクセス権が必要です。データベースを作成する場合、データベース設計者と協力して初期データベース スキーマを開発することが必要な場合があります。
データベース プロジェクトの、ビルドおよび配置を制御するプロパティを設定します。この手順には、既定の照合順序の設定、ビルド出力パスの設定、接続オプションの指定、およびターゲット データベース名の設定が含まれます。
チームがアクセスできるように、データベース プロジェクトおよびその内容をバージョン管理にチェックインします。
データ生成計画を定義して、機密情報は含まないが現実的なテスト データをチームの各メンバが扱うことができるようにします。計画をデータベース プロジェクトに追加し、それをバージョン管理にチェックインします。
既存のデータベースの機能に対するデータベース単体テストも定義します。通常、単体テストはデータベース プロジェクトと同じソリューションの別個のプロジェクトに含め、ソリューション全体をバージョン管理にチェックインします。
これで、チームは開発作業を開始できます。
分離開発環境における反復開発の実施
開発者の場合、ローカル分離開発環境をバージョン管理システムと同期化します。データベース プロジェクトの [ターゲット接続] プロパティをカスタマイズして、データベースの自分のコピーをホストするサーバーをポイントするようにします。以降の作業には、次の処理があります。
実行するタスクを特定します。この手順には、Team Foundation 作業項目トラッキングで自分に割り当てられている作業項目を特定することなどが含まれます。
データベース プロジェクト、その内容、および関連するソース コードを変更します。自分のコードとデータベース プロジェクトとを同期状態に維持できるバージョン管理から、ファイルをチェックアウトします。
必要に応じて、単体テストを作成および変更し、データ生成計画を更新します。
データベース プロジェクトおよび関連するアプリケーションをビルドし、データベースの個人用コピーを置いているサーバーに配置します。
単体テストを実行します。テスト データの作成に、データ ジェネレータを使用することもできます。
すべてのテストが合格し、結果に満足できるまで、手順 2. ～ 5. を繰り返します。
単体テストが合格し、作業の品質に満足できたら、データベース プロジェクト、アプリケーション、および単体テストに対するすべての変更をチェックインします。
次のタスクに進みます。
この処理に沿って作業することにより、変更が一貫した品質レベルに到達するまで、他の開発者に影響を及ぼさない、隔離された環境で変更を開発およびテストすることができます。その後、作業をバージョン管理にチェックインして、行った改善に他の開発者がアクセスできるようにします。
実稼働への変更の配置
チームが必要なすべての変更を加えたら、次の手順は実稼働サーバーを更新することです。そのタスクを実行する担当者の場合、最新バージョンのデータベース プロジェクトをバージョン管理から取得し、配置スクリプトをビルドし、必要に応じてスクリプトを手動で更新し、スクリプトを実行してスキーマの変更を実稼働に配置することができます。
一部のバージョン管理ソフトウェアは、特定の時間に存在する一連のファイルにラベルを付ける機能をサポートしています。たとえば、データベース プロジェクト、アプリケーション ソース コード、単体テスト、およびその他のファイルが特定のリリース用に存在する場合に、それらにラベルを付けることができます。その時点以降、開発が続いても、そのリリースを構成する特定のバージョンのファイルを常に取得することができます。ラベルが付けられている以前のバージョンのデータベース プロジェクトを配置する方法の詳細については、「方法 ： バージョン管理されたデータベースの古いバージョンを配置する」を参照してください。
データベースの形式
この処理方法でデータベースを開発すると、最大 3 つのデータベース形式を保持することができます。
データベースとデータが含まれるデータベース サーバーの形式。データベース開発者の場合、主に開発データベースまたはテスト データベースを扱います。多くの組織では、運用データベースへのアクセス権を持つ、データベース管理者ロールを別個に設けています。
データベース スキーマのオフライン形式であるデータベース プロジェクト。データベース プロジェクトには、テスト データ生成に使用するデータ生成計画およびデータベースの配置と管理に使用するスクリプトも含まれています。詳細については、「データベース プロジェクトの概要」を参照してください。
自分およびチームのメンバがデータベース プロジェクトに加えたすべての変更を追跡するバージョン管理リポジトリ。
データベース サーバーはデータベース プロジェクトとデータを交換します。データベース プロジェクトは、バージョン管理リポジトリともデータを交換しています。バージョン管理、スキーマのインポート、および配置にあたって、これらの形式がデータを交換する方法を理解すると、より効果的にデータベースを管理することができます。