SQL Server データベースのテストからライブへの展開

08-06-2019
|

質問

2 つの SQL Server、具体的には SQL Server 2005 間でのデータベースの展開をどのように管理しているのでしょうか。現在、開発とライブが行われています。これはビルドスクリプトの一部である必要があるため (標準の Windows バッチ。これらのスクリプトの現在の複雑さでは、後で PowerShell などに切り替える可能性があります)、Enterprise Manager/Management Studio Express はカウントされません。

.mdf ファイルをコピーして添付していただけますか?これは互換性の問題であると思われるため、バイナリデータを扱うときは常に少し注意しています (開発とライブでは常に同じバージョンのサーバーを実行する必要がありますが)。

それとも、T-SQL には「EXPLAIN CREATE TABLE」がないため、既存のデータベースをターゲットサーバーで実行できる SQL スクリプトにエクスポートするようなことをしますか?「はい」の場合、特定のデータベースを SQL クエリに自動的にダンプでき、コマンドラインから実行できるツールはありますか?(繰り返しますが、Enterprise Manager/Management Studio Express はカウントされません)。

最後に、ライブデータベースに既にデータが含まれているという事実を考慮すると、デプロイメントではすべてのテーブルを作成するのではなく、構造の違いをチェックし、代わりにライブテーブルを ALTER TABLE する必要があります。これにより、既存のフィールドが変更されたときにデータの検証/変換も必要になる場合があります。

今、私は素晴らしいことをたくさん聞いていますレッドゲート製品ですが、趣味のプロジェクトの場合、価格は少し高価です。

では、SQL Server データベースをテストからライブまで自動的に展開するには何を使用していますか?

解決

私はすべての DDL (creates/alter/delete) ステートメントを手作業でコーディングし、それらをテキストファイルとして .sln に追加し、通常のバージョン管理 (Subversion を使用しますが、リビジョン管理は機能するはずです) を使用することにしました。こうすることで、バージョン管理のメリットが得られるだけでなく、開発/ステージからのライブ更新がコードとデータベースの同じプロセスになり、タグやブランチなどがすべて同じように動作します。

それ以外の場合、redgate を購入してくれる会社がなければ、redgate は高価であることに同意します。ただし、会社に購入してもらうことができれば、本当に価値があります。

他のヒント

私のプロジェクトでは、RED Gate の SQL Compare と、無料でダウンロードできる Microsoft の Database Publishing Wizard を交互に使用しています。ここ.

このウィザードは SQL Compare や SQL Data Compare ほどスムーズではありませんが、十分な機能を備えています。問題の 1 つは、生成されるスクリプトを 1 回で実行するには、再配置や編集が必要になる場合があることです。

良い面としては、スキーマとデータを移動できることですが、これは無料ツールとしては悪くありません。

この問題に対する Microsoft の解決策を忘れないでください。 Visual Studio 2008 データベースエディション. 。データベースへの変更のデプロイ、スキーマおよび/またはデータ変更のデータベース間の差分作成、単体テスト、テストデータ生成のためのツールが含まれています。

かなり高価ですが、試用版をしばらく使用してみて、素晴らしいと思いました。これにより、データベースは他のコードと同じように簡単に操作できるようになります。

Rob Allen と同様に、私は Redgate の SQL Compare / Data Compare を使用しています。Microsoft のデータベース公開ウィザードも使用しています。C# で作成したコンソールアプリもあり、SQL スクリプトを受け取り、サーバー上で実行します。このようにして、「GO」コマンドを含む大きなスクリプトをコマンドラインまたはバッチスクリプトから実行できます。

コンソールアプリケーションで Microsoft.SqlServer.BatchParser.dll ライブラリと Microsoft.SqlServer.ConnectionInfo.dll ライブラリを使用します。

私も Karl と同じように作業を行っています。つまり、テーブルの作成と変更のためのすべての SQL スクリプトをテキストファイルに保存し、ソース管理に保存しています。実際、実行する ALTER を決定するためにスクリプトでライブデータベースを調べなければならないという問題を回避するために、私は通常次のように作業します。

最初のバージョンでは、テスト中のすべてを 1 つの SQL スクリプトに入れ、すべてのテーブルを CREATE として扱います。これは、テスト中にテーブルの削除と読み取りを頻繁に行うことになることを意味しますが、プロジェクトの初期段階ではそれは大したことではありません (とにかく、その時点で使用しているデータを通常はハッキングしているため)。
それ以降のすべてのバージョンでは、次の 2 つのことを行います。アップグレード SQL スクリプトを保持する新しいテキストファイルを作成します。このファイルには、そのバージョンの ALTER のみが含まれます。そして、オリジナルに変更を加え、新しいデータベーススクリプトも作成します。この方法では、アップグレードではアップグレードスクリプトを実行するだけですが、DB を再作成する必要がある場合、そこに到達するために 100 個のスクリプトを実行する必要はありません。
DB の変更をどのようにデプロイするかに応じて、通常は DB のバージョンを保持するバージョンテーブルも DB に配置します。そうすれば、どのスクリプトを実行するか人間が決定するのではなく、作成/アップグレードスクリプトを実行するコードはすべて、バージョンを使用して何を実行するかを決定します。

これが役に立たないことの 1 つは、テストから本番環境に移行するものの一部がデータである場合には役立ちますが、優れた、しかし高価な DB 管理パッケージにお金を払わずに構造を管理したい場合は、実際にはそれほど難しくありません。また、これは DB を頭の中で追跡するのに非常に良い方法であることもわかりました。

Quest Software の Toad を購入する企業がある場合、この種の管理機能が組み込まれています。基本的には 2 回のクリック操作で 2 つのスキーマを比較し、一方から他方への同期スクリプトを生成します。

もちろん SQL Server を含む、ほとんどの一般的なデータベースのエディションが用意されています。

すべてをスクリプト化することが最善の方法であるということに私は同意しており、私が職場で推奨していることです。DB とオブジェクトの作成からルックアップテーブルの設定まで、すべてをスクリプト化する必要があります。

UI のみで行うことはすべて翻訳されません (特に変更の場合)。最初の導入ではあまり必要ありません)、最終的には Redgate が提供するようなツールが必要になります。

SMO/DMO を使用すると、スキーマのスクリプトを生成するのはそれほど難しくありません。データはもう少し楽しいものですが、それでも実行可能です。

一般に、私は「Script It」アプローチを採用していますが、次の方向に沿って何かを検討することもできます。

データのサブセットを使用して開発できるように、開発とステージングを区別します。これは、実稼働データを単に取得するためのツールを作成するか、セキュリティが懸念される偽のデータを生成するためのものです。
チーム開発の場合、データベースに対する各変更をチームメンバー間で調整する必要があります。スキーマとデータの変更は混在する可能性がありますが、単一のスクリプトで特定の機能を有効にする必要があります。すべての機能の準備ができたら、これらを 1 つの SQL ファイルにバンドルし、本番環境の復元に対して実行します。
ステージングが承認されたら、実稼働マシン上で単一の SQL ファイルを再度実行します。

Red Gate ツールを使用しましたが、 素晴らしい ツールを必要としますが、それを買う余裕がない場合は、ツールを構築してこの方法で作業することは、理想からそれほど遠くありません。

私は Subsonic の移行メカニズムを使用しているので、up と down の 2 つのメソッドを持つ順番にクラスを含む dll を作成するだけです。NANT への継続的統合/ビルドスクリプトフックがあるため、データベースのアップグレードを自動化できます。

これは世界で最高の方法ではありませんが、DDL を書くよりは優れています。

RedGate SQLCompare 私の意見では、行くべき方法です。私たちは DB デプロイメントを定期的に行っており、そのツールを使い始めて以来、一度も振り返ったことはありません。非常に直感的なインターフェイスなので、最終的には時間を大幅に節約できます。

Pro バージョンでは、ソース管理統合のためのスクリプト作成も処理します。

また、すべてのオブジェクトとデータのスクリプトも管理しています。デプロイ用に、この無料ユーティリティを作成しました - http://www.sqldart.com. 。これにより、スクリプトファイルの順序を変更し、トランザクション内ですべての処理を実行できるようになります。

私は、すべてをソース管理に保持し、すべての変更を手動でスクリプト化することに同意します。単一リリースのスキーマへの変更は、そのリリース専用に作成されたスクリプトファイルに反映されます。保存されたすべてのプロシージャ、ビューなどは個別のファイルに入れられ、ソース管理に関しては .cs または .aspx と同様に扱われる必要があります。PowerShell スクリプトを使用して、プログラム機能を更新するための 1 つの大きな .sql ファイルを生成します。

私は、新しいテーブルや新しい列などのスキーマ変更の適用を自動化するのが好きではありません。実稼働リリースを実行するときは、変更スクリプトをコマンドごとに実行して、それぞれが期待どおりに動作することを確認するのが好きです。本番環境で大きな変更スクリプトを実行し、開発中に存在しなかった細かい詳細を忘れてエラーが発生することほど最悪なことはありません。

また、インデックスはコードファイルと同じように扱い、ソース管理に入れる必要があることも学びました。

そして、dev と live という 2 つ以上のデータベースが必ず必要です。誰もが毎日の開発タスクに使用する開発データベースが必要です。次に、運用環境を模倣し、統合テストを行うために使用されるステージングデータベースです。次に、可能であれば、本番環境の最新の完全なコピー (完全バックアップから復元) を使用することもあります。そのため、インストールテストの最終ラウンドは、可能な限り本物に近いものに対して行われます。

私はデータベース作成をすべて DDL として実行し、その DDL をスキーマ保守クラスにラップします。最初に DDL を作成するためにさまざまなことを行うことがありますが、基本的にはすべてのスキーマのメンテナンスをコード内で行います。これは、SQL に適切にマッピングできない非 DDL 処理を実行する必要がある場合、手続き型ロジックを作成して、DDL/DML の塊の間で実行できることも意味します。

私のデータベースには現在のバージョンを定義するテーブルがあり、比較的簡単なテストのセットをコーディングできます。

DBは存在するのでしょうか？そうでない場合は作成してください。
DBは現在のバージョンですか？そうでない場合は、スキーマを最新の状態にするメソッドを順番に実行します (この時点でユーザーに確認を求め、理想的にはバックアップを実行することをお勧めします)。

シングルユーザーアプリの場合は、これを適切な場所で実行するだけですが、Web アプリの場合は、バージョンが一致しない場合にユーザーをロックアウトし、スタンドアロンのスキーマメンテナンスアプリを実行します。マルチユーザーの場合は、特定の環境によって異なります。

利点？この方法を使用するアプリのスキーマは、それらのアプリケーションのすべてのインスタンスにわたって一貫しているという非常に高い自信があります。完璧ではなく、問題もありますが、機能します...

チーム環境で開発する場合にはいくつかの問題がありますが、それは多かれ少なかれ当然のことです。

マーフ

私は現在、あなたと同じ仕事をしています。SQL Server データベースのテストから運用までの展開だけでなく、ローカル -> 統合 -> テスト -> 運用に至るプロセス全体も含まれます。それで、私を毎日簡単にできることは、私がすることです Red-Gate SQL Compare を使用した NAnt タスク. 。私は RedGate で働いているわけではありませんが、良い選択だと言わざるを得ません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow