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

Question

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 でライブテーブルをチェックする必要があります。これには、既存のフィールドが変更されたときにデータの検証/変換も必要になる場合があります。

現在、 Red Gate製品について多くのすばらしい話を耳にしますが、趣味のプロジェクトの場合、価格は少し急です。

では、SQL Server データベースを Test から Live に自動的に展開するために何を使用していますか?

score 19 · Accepted Answer

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

そうでなければ、レッドゲートを購入してくれる会社がない場合、レッドゲートは高価であることに同意します。とはいえ、会社に購入してもらうことができれば、本当に価値があります。

score 13 · Accepted Answer

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

このウィザードは、SQL Compare や SQL Data Compare ほど巧妙ではありませんが、うまく機能します。1 つの問題は、それが生成するスクリプトを一度に流すには、再配置や編集が必要になる場合があることです。

良い面としては、無料のツールとしては悪くないスキーマとデータを移動できます。

score 7 · Accepted Answer

この問題に対する Microsoft のソリューション、 Visual Studio 2008 Database Editionを忘れないでください。データベースへの変更の展開、スキーマおよび/またはデータ変更のデータベース間の差分の生成、単体テスト、テストデータ生成のためのツールが含まれています。

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

score 5 · Accepted Answer

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

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

score 3 · Accepted Answer

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

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

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

score 2 · Accepted Answer

また、すべてのオブジェクトとデータのスクリプトを維持しています。展開のために、私はこの無料のユーティリティを作成しました - http://www.sqldart.com。これにより、スクリプトファイルを並べ替えることができ、トランザクション内ですべてを実行できます。

score 2 · Accepted Answer

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

もちろん、Sql Serverを含む、ほとんどの一般的なデータベースのエディションがあります.

score 2 · Accepted Answer

すべてをスクリプト化することが最善の方法であり、私が仕事で提唱していることに同意します。DB とオブジェクトの作成からルックアップテーブルの作成まで、すべてをスクリプト化する必要があります。

UI で行うことはすべて変換されず (特に変更の場合... 最初の展開ではそれほどではありません)、最終的には Redgate が提供するようなツールが必要になります。

score 2 · Accepted Answer

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

一般に、私は「スクリプトを作成する」アプローチを採用していますが、次の点に沿って何かを検討することをお勧めします。

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

私は Red Gate ツールを使用してきましたが、それらは優れたツールですが、それを購入する余裕がない場合は、ツールを構築してこの方法で作業することは、理想からほど遠いものではありません。

score 2 · Accepted Answer

RedGate SqlCompareは、私の意見では進むべき道です。私たちは定期的に DB のデプロイを行っており、そのツールを使い始めて以来、過去を振り返ることはありません。非常に直感的なインターフェースで、最終的に多くの時間を節約できます。

Pro バージョンでは、ソース管理統合のスクリプトも処理されます。

score 2 · Accepted Answer

私は Subsonic の移行メカニズムを使用しているので、上と下の 2 つのメソッドを持つ順番に並べられたクラスを持つ dll があります。nant への継続的インテグレーション/ビルドスクリプトフックがあるため、データベースのアップグレードを自動化できます。

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

score 1 · Accepted Answer

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

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

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

単一のユーザーアプリの場合は、これをその場で実行するだけです。Web アプリの場合、現在、バージョンが一致しない場合にユーザーをロックアウトし、実行するスタンドアロンのスキーマ管理アプリを持っています。マルチユーザーの場合、特定の環境によって異なります。

利点？私は、この方法論を使用するアプリのスキーマが、それらのアプリケーションのすべてのインスタンスで一貫しているという非常に高いレベルの確信を持っています。完璧ではありません。問題はありますが、機能します...

チーム環境で開発する場合、いくつかの問題がありますが、とにかくそれは多かれ少なかれ与えられたものです!

マーフ

score 1 · Accepted Answer

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

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

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

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

score 1 · Accepted Answer

私は現在、あなたと同じことをしています。SQL Server データベースをテストからライブにデプロイするだけでなく、ローカル -> 統合 -> テスト -> 本番までのプロセス全体が含まれます。したがって、毎日簡単にできるのは、 Red-Gate SQL Compare で NAnt タスクを実行することです。私は RedGate で働いているわけではありませんが、良い選択だと言わざるを得ません。

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

14 に答える 14

Related

Reference