1

私の現在のプロジェクトでは、Visual Studio Team System for Database Professionals GDR2 (別名 DataDude) を使用しています。私たちは、DataDude を使用してモデル化したデータベースを使用する唯一のアプリケーションです。

私の会社は、すべてのプロジェクトで全面的に DataDude を使用することを検討したいと考えています。ただし、これがデータベースを共有するプロジェクト (アプリケーションの大部分) でうまく機能するかどうかはわかりません。

例: ApplicationA、ApplicationB、および ApplicationC はすべて Server1 上の Database1 を共有します。(ソース コードは共有せず、データベースのみを共有します。) 3 つのアプリケーションはすべて現在開発中です (必要に応じてスクラムを使用します)。

問題は、ApplicationB をテスト環境にリリースする必要があるときに発生します。DataDude の自動展開/スクリプト機能は、ApplicationA と ApplicationC の現在の開発変更をキャッチします。(現在、アプリケーションごとにデータベースを変更するのは手動のプロセスです)。

では、同じデータベースを共有しながら、各アプリケーションを他のアプリケーションから隔離するにはどうすればよいでしょうか?

注: この質問に対する競合する変更については心配していません (つまり、ApplicationA が ApplicationC を壊すような DB 変更を行った場合)。それらはテストで見つけることができます。現在リリースしているアプリケーションの一部ではないデータベースの変更をテスト/本番環境に移動しないようにする必要があります。

これに役立つベスト プラクティスや機能はありますか?

4

1 に答える 1

3

私たちは同じような状況にあります。同じデータベースにアクセスするアプリケーションが多数あり、データベースはDBProソース管理下にあります。これを処理するには、さまざまなアプリケーションをデータベースソースコードの独自のブランチで動作させます。各アプリケーションは定期的にメインブランチからマージされるため、そのブランチは他のアプリケーションによって行われた変更を認識します。次に、アプリケーションの1つをテストにデプロイする必要がある場合、メインブランチへのマージが実行されてから、テストサーバーへのデプロイメントが実行されます。

于 2010-02-02T19:22:57.840 に答える