データベースの変更の管理
エンタープライズ レベルでデータベースの開発および保守を行う場合、統一されたデータベース アプリケーションを作成するために、多くの場合はデータベース開発者がソフトウェア開発チームとのスケジュールおよび変更の調整を担当します。 組織内のソフトウェア開発者が使用しているのとできるだけ類似したツールやプロセスを採用することにより、この調整に必要な作業を大幅に軽減できます。
多くのチームがより反復的で迅速に開発できるコード記述のパラダイム (アジャイル方式など) に移行するにつれ、ソフトウェア開発者とデータベース開発者の両方で、バージョン管理などのツールの必要性がますます高まっています。 これらのツールにより、チームベースの開発に関連するリスクを軽減できます。 類似したツールとプロセスを使用すると、管理対象のデータベースだけでなく、それらのデータベースと対話するソフトウェアとの間の統合ポイントに対しても大きな利点が得られます。
Visual Studio の利点
Visual Studio は、チーム メンバーがより全体的な視点を持ち、実装の詳細ではなくアプリケーションの動作に重点を置くように促すことにより、データベース開発者とソフトウェア開発者の間の調整を支援します。 このアプローチは、運用データベース (およびそのデータ) をアプリケーション領域の中心と見なすモデルとは異なります。 Visual Studio には、データとロジックの両方で完全なアプリケーションを対象とするソリューション セットが用意されています。 適切に動作し、保守が簡単で、できるだけ迅速に配布できるアプリケーションを構築するためには、エンタープライズ レベルの開発組織がアプリケーションに対してこのような包括的な視点を持っている必要があります。
Visual Studio には、今日のデータベース開発者およびデータベース管理者のロール向けの機能が用意されています。 たとえば、Visual Studio では、各データベース担当者に対して分離開発環境の概念がサポートされています。 チーム メンバーは、他のチーム メンバーや運用環境に悪影響を及ぼすことなく、スキーマ関連のアクティビティを操作できます。 長期的な視点により、データベース設計者のロール向けの機能が追加され、データベース管理者向けの機能が拡張されています。
高度な目標
Visual Studio のデータベース機能には、次の高度な目標があります。
データベース アプリケーションの統合された変更管理に基づく基本機能を提供する。
データベース プロジェクトの管理を支援するツールを提供する。
相違点の理解に役立つツールを提供する。
変更と、それが及ぼす影響の評価を支援するツールを提供する。
変更に関連するリスクを軽減するための、隔離された環境での作業を支援するツールを提供する。
更新されたソリューションのテストを支援するツールを提供する。
データベースに加えられた変更の配置を簡素化するためのツールを提供する。
複雑なデータベースの共同開発を容易にするためのツールを提供する。
高度なタスク
これらの目標をサポートするために、Visual Studio では次の高度なタスクを実行できます。
バージョン管理された新しいデータベースを作成および配置する。
データベース プロジェクトを使用して、既存のデータベース スキーマをバージョン管理する。 データベース プロジェクト スキーマは、データベースまたは既存のスクリプトからスキーマをインポートすることによって作成されます。
データベースのオフライン形式を変更し、変更を配置する。
データベース間でスキーマまたはデータを比較する。
単体テストを開発し、データベース オブジェクトに対して実行する。
実行時用の機密データを損なうことなく、予測可能で代表的なテスト データを生成する。
データベース テーブル、列、ビュー、またはその他のオブジェクトの名前を変更し、それらの変更をデータベース プロジェクトの残りの部分 (関連する単体テスト、ビュー、ストアド プロシージャ、トリガーなど) に反映する。
スクリプトとクエリを作成、編集、検証、実行、および分析する。
データベース開発ライフサイクル
Visual Studio は、新しいツールと連動するプロセスをサポートします。 このプロセスは、データベース開発ライフサイクルと考えることができます。データベース開発ライフサイクルでは、各データベース担当者に対して、変更の作業とテストを行うための分離開発環境が用意されています。 変更のテストが完了すると、チーム メンバーはバージョン管理システムを使用して変更を共有します。 データベース開発ライフサイクルには、次のフェーズがあります。
プロジェクト環境の確立
隔離された反復開発の実行
プロジェクトのビルド
プロジェクト環境からの配置
プロジェクト環境の確立
次の図に、データベース管理者 (DBA) ロールを実行するチーム メンバーがプロジェクト環境を確立する方法を示します。
.png "DBA はデータベース プロジェクト環境を設定します")
まず、DBA はデータベース プロジェクトを作成し、運用データベースからデータベース スキーマをインポートします。 次に、分離開発環境用のテスト データを作成するためのデータ生成計画を作成します。 最後に、データベース プロジェクトをバージョン管理にチェックインし、チームで使用できるようにします。
隔離された反復開発の実行
次の図に、チーム メンバーが隔離された環境で反復開発作業を実行する方法を示します。
.png "分離環境での反復開発")
各データベース担当者は、自分の開発環境をバージョン管理に同期します。 データベース担当者は、ファイルが変更されたときにそのファイルをチェックアウトし、変更を隔離された環境で開発およびテストすることができます。 データベース プロジェクトの担当者用のコピーに加えられた変更は、その担当者の分離開発環境だけに配置されます。 チーム メンバーは、現実的なテスト データを生成し、データベースのプライベート コピーに対して単体テストを実行した後で、変更をバージョン管理にチェックインします。 他のチーム メンバーは、テスト済みの変更をバージョン管理から取得します。
プロジェクトのデイリー ビルドの生成
次の図に、データベース プロジェクトのビルド サイクルを示します。
.png "データベース プロジェクトのビルド サイクル")
デイリー ビルドは、バージョン管理システムの、最後にテストされたバージョンのデータベース プロジェクトに同期することによって生成されます。 そのビルドをテスト データベースに配置でき、そこで、生成されたテスト データに対して単体テストが実行されます。
プロジェクト環境からの配置
次の図に、DBA がデータベース プロジェクトのバージョンを実稼働環境に配置する方法を示します。
.png "DBA はビルドして運用のために配置します")
データベースのバージョンを実稼働環境に配置する際、DBA は、バージョン管理システムからのラベルに同期します。 DBA は、データベース プロジェクト、関連スクリプト、およびテストについて、一致するファイルを取得します。 次に、DBA が .dbschema ファイルをビルドします。 .dbschema ファイルから、DBA が配置スクリプトを生成し、必要に応じて手動で変更を加え、ステージング サーバーにテスト配置します。 DBA は、スクリプトが運用サーバーに配置できる状態になるまでこのプロセスを繰り返します。 DBA がスキーマ、配置前スクリプト、または配置後スクリプトに変更を加えた場合、その変更はバージョン管理に再びチェックインされます。