データベースのビルドとステージング環境または稼動環境への配置
データベース開発者は、個々の開発タスクを行うときに、それぞれ別の分離開発環境 (サンドボックスとも呼ばれます) で作業を行います。 データベース プロジェクトのテスト済みバージョンをステージング環境または稼動環境に配置する処理は、この状況と似ていますが、重要な点がいくつか異なります。
通常、ステージング サーバーや運用サーバーへのアクセスは制限されています。 これらのサーバーには、保持する必要がある他のデータベースが格納されている可能性があるためです。 また、多くの場合、ターゲット データベースは既に存在しており、これにも保持する必要があるデータが含まれている場合があります。 サーバーにデータベースを配置するときは、開発環境にデータベースを配置するときと異なり、サーバーの設定を変更しない場合が多いと考えられます。 さらに、データベースを配置するためのアクセス許可は保持していても、サーバーの設定を更新するためのアクセス許可を保持していない場合もあります。
データベース プロジェクトをステージング環境または稼動環境に配置するための構成
データベース プロジェクトの配置プロパティの設定を、ステージング サーバーの環境および運用サーバーの環境に合わせて構成することができます。 これらの設定は、他の開発者の分離開発環境の設定とは区別する必要があります。 この区別を維持することで、他の開発者が変更できないステージング環境および稼動環境用のプロジェクト構成を設定できます。 各構成では、ターゲット データベースからステージング サーバーまたは運用サーバーへの接続、専用の .sqldeployment ファイル、および専用の .sqlcmdvars ファイルを指定します。
また、ステージング環境や稼動環境用の設定を構成して、配置スクリプトを準備したうえで、実際の配置はスキップするようにしておくこともできます。 このような方法を取ることで、配置スクリプトを見直して、必要に応じて変更を加えてから、対象の環境に手動でデータベース プロジェクトを配置できます。
配置構成の詳細
プロジェクトをステージング環境または稼動環境に配置する前に、次の事項を検討しておく必要があります。
ステージング環境または稼動環境は既に設定されているため、ターゲット データベースの照合順序を使用するかどうか。
データ損失の可能性があるため、毎回データベースを再作成しないようにするかどうか。
新しいデータベースを配置する場合は、データベースのプロパティを配置するかどうか。 既存のデータベースに対する更新を配置する場合は、データベースのプロパティが既に正しく設定されていると考えられるため、プロパティの配置を行わないようにするかどうか。
配置処理とは別の手順でオブジェクトやデータを既にバックアップしている場合を除き、配置処理の一環としてデータベースを自動的にバックアップするかどうか。
更新対象のデータベースには本番データが含まれていることが多いため、データ損失が発生した場合に配置を中止するかどうか。
データベースにあってデータベース プロジェクトにないオブジェクトに対して DROP ステートメントを生成するかどうか。 データベース プロジェクトには、正しいバージョンのステージングおよび稼動スキーマが含まれていると考えられます。 ただし、データベースの更新を配置した後に、データを手動で移動する必要がある場合は、これに当てはまりません。 このような場合は、データの移行が完了するまで、オブジェクトを無効にしない方がよいと考えられます。
SQL コマンドの変数
ステージング環境または稼動環境にデータベースを配置するときは、その環境に応じた値を変数に割り当てる必要があります。 たとえば、ステージング環境または稼動環境では、開発環境とは異なる Service Broker やサービス証明書の値を割り当てる必要があります。 対象となる環境ごとに異なる .sqlcmdvars ファイルを指定することで、配置先が変わってもこれらの変数の値を変更する必要がなくなります。 また、この方法を使用すると、.sqlcmdvars ファイルで、構成ごとに異なる値を MSBuild の変数に割り当てるよう定義する必要もなくなります。 これは、配置する構成ごとに異なる .sqlcmdvars ファイルを指定できるためです。
サーバー プロジェクトの配置
データベース プロジェクトには、データベース オブジェクトの定義、サーバー オブジェクトの定義、またはその両方が含まれている場合があります。 ほとんどの環境では、開発者がデータベース オブジェクトを変更できますが、サーバー オブジェクトを変更できるのはデータベース管理者だけです。 このような制限は、サーバー オブジェクトを別のプロジェクト (サーバー プロジェクト) に格納することで実現できます。 これにより、バージョン コントロールを制限して、管理者だけがサーバー プロジェクトを変更できるように設定できます。 ステージング環境または稼動環境では、通常、サーバー プロジェクトとそのオブジェクトは、データベース オブジェクトを含むプロジェクトとは別に配置されます。
サーバー プロジェクトの配置は、スキーマ プロジェクトの配置と同じ手順で実行できます。
ロールの配置
データベースで使用するロールを、データベースの配置先となるすべてのサーバーに配置する必要があります。 データベースをステージング サーバーまたは運用サーバーに配置するときは、必要なユーザーをすべて定義し、そのユーザーを適切なロールに関連付ける必要があります。
コマンド ライン配置
Visual Studio Premium がインストールされていないコンピューターで、コマンド プロンプトからデータベース プロジェクトを配置するには、次の必要条件がインストールされている必要があります。
Microsoft .NET Framework Version 3.5 Service Pack 1
SQL Server 管理オブジェクト (SMO: SQL Server Management Objects)
これらの必要条件を、SQL Server がインストールされたコンピューターにインストールしておく必要があります。
これらの必要条件のほかに、コンピューターに次のファイルを転送する必要があります。場合によっては、最初にユニバーサル シリアル バス (USB: Universal Serial Bus) ドライブにこれらをコピーする必要があります。
データベース プロジェクトのビルド出力 (デバッグまたはリテール)
Visual Studio Premium の Deploy フォルダーの内容
通常は [Program Files]\VSTSDB\Deploy にあります。
SQL Server Compact Edition のアセンブリ
必要条件をインストールしてファイルを転送したら、データベース プロジェクトを (.dbschema ファイルの形で) ターゲット データベースに配置できます。
一般的なタスク
次の表に、このシナリオをサポートする一般的なタスクの説明と、それらのタスクを正常に完了する方法の詳細へのリンクを示します。
タスク |
関連する参照先 |
|---|---|
ビルドおよび配置を開始する: 初めてのデータベース プロジェクトを構成、ビルド、および配置する前に、チーム環境でデータベース プロジェクトを使用する方法を理解しておく必要があります。 また、ビルドや配置処理についても、より詳しく理解できます。 さらに、プロジェクトのビルド方法や配置方法を制御するすべてのプロパティと設定についても学習します。 |
|
完成したオブジェクトのみを配置する: 配置またはテストできる状態ではないデータベース オブジェクトの定義を含むファイルを除外できます。 |
|
データベース プロジェクトをビルド作業用に構成する: データベース プロジェクトのビルド方法を制御する設定を構成できます。 たとえば、出力パスなどを指定できます。 |
|
データベース プロジェクトを配置用に構成する:
|
|
参照またはルックアップ テーブルを設定する: データベース プロジェクトを配置するときに、参照データをテーブルに追加できます。 この方法は、あまり変更されないデータ (配送業者に関する情報など) を含むテーブルに適用すると便利です。 |
|
データベース プロジェクトをビルドする: Visual Studio、またはコマンド プロンプトで MSBuild を使用してデータベース プロジェクトをビルドし、配置に備えることができます。 |
|
データベース プロジェクトを配置する: Visual Studio で、データベース単体テストの実行の一部として MSBuild を使用するか、コマンド プロンプトで VSDBCMD を使用することによって、データベース プロジェクトを配置し、ターゲット データベースまたはサーバーを更新できます。 また、カスタム ワークフローを定義した場合は、Team Foundation ビルドを使用して配置することもできます。 |
|
問題のトラブルシューティング: データベース プロジェクトをビルドして配置するときに発生する可能性がある一般的な問題をトラブルシューティングする方法の詳細について学習できます。 |
関連するシナリオ
データベースのチーム開発の開始
データベース プロジェクトでデータベース スキーマのオフライン形式を作成し、それをバージョン コントロールに追加する方法について説明します。他のデータベースを参照するデータベースのチーム開発の開始
データベース スキーマのオフライン形式を作成し、他のデータベースへの 1 つ以上の参照を定義し、対象となる配置環境用に変数の値を定義して、プロジェクトをバージョン コントロールに追加する方法について説明します。SQLCLR オブジェクトを参照するデータベースのチーム開発の開始
データベース スキーマのオフライン形式を作成し、SQL 共通言語ランタイム (CLR: Common Language Runtime) オブジェクトを含むアセンブリへの参照を定義し、それらの SQLCLR オブジェクトを参照するデータベース オブジェクトを定義して、プロジェクトをバージョン コントロールに追加する方法について説明します。XML スキーマ コレクションを使用するデータベースのチーム開発の開始
データベース スキーマのオフライン形式を作成し、XML スキーマ定義 (XSD: XML Schema Definition) ファイルへの参照を定義し、そのファイルを使用する XML スキーマ コレクションを定義し、その XML スキーマ コレクションを使用する列を定義して、プロジェクトをバージョン コントロールに追加する方法について説明します。共有サーバー オブジェクトを参照するデータベースのチーム開発の開始
データベース スキーマのオフライン形式を作成し、共有サーバー プロジェクトへの参照を定義し、サーバー プロジェクトで定義されているオブジェクトへの参照を追加して、データベース プロジェクトをバージョン コントロールに追加する方法について説明します。データベースのビルドおよび分離開発環境への配置
データベースをビルドし、分離開発環境に配置する方法について説明します。 データベースをバージョン コントロールにチェックインしてチームと共有する前に、分離開発環境で変更をテストできます。 変更をビルドしてステージング環境または稼動環境に配置する前に、分離開発環境で変更をテストする必要があります。