4

私のチームは、Martin Fowler、Pramod Sadalage などによって説明されているように、データベース移行/データベース リファクタリングを管理するためのツールとプロセスを評価しています。アル。自動化された反復可能でテスト可能なプロセスに関心があるため、展開するたびに SQL Compare を手動で実行するような手法には関心がありません。現在、継続的インテグレーションのために CruiseControl.NET を使用しています。

私たちの実稼働環境には複数の SQL Server 2000 データベース サーバーがあり、それらの間でレプリケーションが行われています。したがって、移行により、ソース データベース サーバーとターゲット データベース サーバーの両方でスキーマが変更されます。

このような移行を dbdeploy などのツールで実行するには、サーバーの 1 つに対して移行を実行する必要があり、他のサーバーをリンク サーバーとして追加する必要があるようです。したがって、メイン サーバーに対して実行される 1 つのスクリプトは、任意のリンク サーバーに対して DDL を実行できます。

私の質問はこれです: このアプローチはベスト プラクティスと見なされますか、それとも複数のデータベース サーバーに触れる移行を適用するためのより良い手法はありますか?

4

4 に答える 4

1

Visual Studio 2008 (Team Edition、具体的には GDR) は、サーバーに展開できる定義済みのスキーマ/メタデータ ファイルに対するスキーマの自動展開を処理できます。これは、ビルド / デプロイ プロセスに含めることができます。ただし、レプリケーションとスキーマの変更にはまだ問題があると思います。レプリケーションの設定を理解したり認識したりするパッケージはありません。

たとえば、サブスクライバーでカスタム レプリケーション プロシージャを使用します。スキーマの変更はパブリッシャーから伝達されますが、配置しているカスタム レプリケーションによっては、変更を手動でスクリプト化する必要がある場合があります。カスタム レプリケーション プロシージャを使用しない場合は、これが最適な方法でした。

于 2009-04-21T12:30:34.850 に答える
0

ChinchillinとWizardbyの組み合わせを試すことができます。ChinchillinエージェントをDBサーバーにインストールし、展開プロセス中にWizardby移行スクリプトを実行させます。

ただし、この統合は現在進行中です:)

于 2010-03-11T13:37:04.473 に答える
0

このアプローチに本質的に問題があるとは思いませんが、セットアップするときは、リンクされたサーバーの 1 つがダウンしたときに何が起こるかを必ずテストしてください。1 つのサーバーがダウンした場合に他のすべてのサーバーをロールバックするのではなく、変更がそのサーバーに適用されなかったことを知りたい場合。

もちろん、どのような移行においても最初の最も重要なベスト プラクティスは、変更の移行を開始する前に確実なバックアップ プロセスを実施することです。

于 2009-04-20T13:25:07.100 に答える
0

Red Gate では、SQL Compare と SQL Source Control を使用する反復可能な移行ソリューションを手に入れました。したがって、SQL Compare コマンド ラインを使用して、継続的な統合プロセスをサポートできます。

http://www.red-gate.com/MessageBoard/viewtopic.php?t=14107

現在はアーリー アクセス ビルドであるため、できるだけ多くのフィードバックをお待ちしております。

于 2011-10-17T22:04:06.453 に答える