SQL Serverデータベースの変更をテストサーバーから運用サーバーに展開する
SQL Serverを実行する高可用性productionサーバーがあります。何百人ものユーザーが常に読み取り/書き込みを行っています。
私はtestingサーバーにデータベースの正確なコピーを持っており、その環境ですべての開発を行っています。数週間ごとに、フロントエンドアプリケーションとデータベース自体に大きな変更（たとえば、新しいストアドプロシージャ、新しい列、新しいテーブル）が行われます。
productionサーバー上のデータは常に最新であるため、データベーススキーマを変更するときにそのデータを失いたくありません。変更を展開するための現在のプロセスは次のとおりです。
productionサーバーをバックアップして一時停止するtestingサーバーに復元しますtestingサーバーですべてのデータベース変更を行うtestingサーバーをバックアップする- 新しいバージョンを
productionサーバーに復元し、一時停止を解除します
手順は複雑で、本番サーバーで不要なダウンタイムが発生しています。私がやりたいのは、バックグラウンドでproductionサーバーデータベースを更新しながら、ユーザーがデータベースの読み取り/書き込みを続行できるようにすることです。
これまでのところ、データベースコピーウィザードまたはスクリプトを使用して変更を加えることができますが、productionサーバーにデータベースをドロップ/作成して変更を加えたいようです。 productionサーバーのデータベースを更新する、それほど深刻ではない方法を実現するにはどうすればよいですか？
スキーマの変更だけの場合、データベース全体をバックアップする間（1つのテーブルのみが変更されている場合でも）、本番環境を中断して待機させ、別の環境で変更を復元およびテストしてから、再度バックアップおよび復元するのは非常に無駄です。余分な手間をかけずに、また実際に変更されたオブジェクトのみを変更することで、2つの環境を同期させてスキーマをリアルタイムで比較/展開するツールを入手してください。私が選択したのはRed Gate SQL Compareですが、他にもさまざまな機能と価格で多くの選択肢があります。
スキーマの変更に下位互換性を持たせたり、段階的に展開したりすることにより、実行する必要がある徹底的なテストの量を最小限に抑えることができます。私は数年前にこれについていくつかのヒントを与えました：
優れたツールであるAdept SQL Diffは非常に高速でしたが、もはやサポートされておらず、Windows 2008以降では機能しません。したがって、Redgateが選択されます。
たぶん、継続的インテグレーション（CI）とアジャイル方法論を検討するのに良い時かもしれません。 SSDT（SQL Serverデータツール）とビルドソフトウェア（Team Foundation Server、Bamboo、Teamcityなど）が必要です。TeamCityを使用しており、最大20のプロジェクトを無料で作成できます。そしてもちろん、Git、SVN、TFSなどのソース管理ソフトウェアが必要になります。
この種の環境をセットアップするのは少し難しいですが、完了してすべてがテストされて機能するようになると、デプロイメントは完全になり、文字通り「ワンクリック」で実行されます。
まず、リバースエンジニアリングを実行し、本番データベースをSSDTプロジェクトに変換する必要があります。多くのデータベースがある場合は、それぞれを個別に変換する必要があります。その後、選択したビルドソフトウェアを使用してCIプロジェクトを作成します。
3つまたは4つの個別の環境が必要です。
統合またはテスト。単体テストを実行したくない場合は、必要ありません。しかし、現代世界のほとんどの人々は、回帰テストを減らすためにそれを持っています。したがって、ここでは、ビルドごとに新鮮なスパークリングデータベースが作成され、予測可能な結果で自動テストが実行されます。そのため、データベースにテストデータを入力する必要があります。通常、SQLスクリプトまたはSSISパッケージを使用します。小さなプロジェクトの場合、通勤（変更）があれば、1時間ごとにビルドできます。または、実行する20Kの単体テストがある場合は、夜間に実行します。
UATまたはステージング。ここで、ライブデータで展開をテストします。配置を行う前に、本番環境のバックアップをUATデータベースに復元し、そこで配置を実行します。機密性の高い顧客データを何らかの方法で歪めたい場合があります。デプロイメントのすべてのエラーが記録され、修正されます。 QAチームは、必要に応じてそこでユーザー受け入れテストを行います。実行結果に対して緑色のチェックマークが表示されるまで、デプロイメントを実行します。
製造。すべての受け入れとテストが完了したら、変更を本番環境にロールアウトできます。すべてをテストしたので、すべてがスムーズに進むはずです。展開時にWebサイトまたはデータベースへのアクセスを切断しますが、通常、展開のスキーマと小さなデータの変更には数秒かかります。
典型的な導入プロジェクトは多くのステップで構成されているため、Webサイトとデータベースを完全に導入でき、集中セットアップ用のプロジェクトテンプレートが最善です。
「開発」である4番目のタイプの環境については触れませんでした。すべての開発者はすべて（実際には統合環境です）の独自のコピーを持っているので、コードを中央リポジトリにコミットする前に、ローカルワークステーションでデプロイメントおよびユニットテストを実行/チェックできます。
上記すべてを実現するのに3台の物理サーバーは必要ありません。仮想マシン、SQLサーバーインスタンスを使用するか、プロジェクトパラメータを使用して環境ごとにデータベースに異なる名前を付けることができます。
本番データベースの特定のテーブルを、テスト環境で変更したテーブルと同期するスクリプトを作成するツールが必要になります。
Visual Studio 2013のPro、Premium、およびUltimateエディションには、スキーマとデータの比較機能があります。
私は個人的にRed Gate SQL比較を使用しています。
データベースの継続的な統合は、バージョン管理とマージを通じて埋め込むことができます。開発チームの構成と使用する変更管理プロセスに応じて、継続的な統合を実装する方法はいくつかあります。とにかく、 DBmaestro （私が働いている）は、データベースの変更を自動化して生成または実行する機能を備えているため、データベース指向の継続的インテグレーションソリューションの不可欠な部分になります。
ビルドプロセスは、バージョン管理からの更新を要求し、ターゲットデータベースの変更を更新するマージスクリプトを自動的に作成してマージし、データベースの変更をデプロイして、データベースに対して直接定義されたテストを実行するか、プロセスの一部としてアプリケーションコードを含めることができます。完全な統合テスト。
問題は、単純な比較と同期では、比較を実行してDDLスクリプトを生成するときにバージョン管理リポジトリを利用しないことです。そのため、バージョン管理リポジトリは、唯一の真の情報源として機能しません。
単純な比較と同期が実行されるもう1つの問題は、情報が比較＆同期ツールの外部にあるALM、CMS、またはバージョン管理リポジトリに格納されているため、データベース全体を比較して違いを示し、関連するおよび無関係な展開スクリプト。
最も重要なのは、単純な比較と同期では、展開スクリプトが競合を処理してマージすることを保証しないことです。
一方、データベースによる変更管理では、バージョン管理リポジトリとそのときの環境の構造に基づいて、データベースオブジェクトに対するバージョン管理プロセスの適用と、必要に応じてデプロイメントスクリプトの生成を組み合わせます。
詳細については このホワイトペーパー をお勧めします