git の下に ASP.NET プロジェクトがあり、機能にブランチを使用するという規則に従います。スキーマの変更を管理するために SQL Server Data Tools を使い始めたばかりです (これはかなり新しいので、必要な機能を備えているのではないかと思います)。
異なるDBスキーマを持つブランチ間の切り替えを管理し、ブランチをうまくマージする他のチームで機能したいくつかの戦略を探しています. 理想的には、すべての機能をマージした後、本番環境へのリリース用に展開する変更スクリプトを暗黙的に作成します。
注: SQL Server 2008 R2 を使用しています
この戦略には複数の部分があります。1 つの側面は、さまざまなブランチのストレージの処理です。私のチームでうまく機能したのは、ブランチごとに異なる SQL Server インスタンスを使用することでした (MyDatabase_FeatureBranchX など、ブランチ固有のプレフィックスまたはサフィックスを使用して個々のデータベースに名前を付けるのではなく)。手に負えなくなる可能性があります）。これにより、各ブランチ内の対応するデータベースに同じ名前を付けることができますが (わかりやすくするため)、特定のブランチの SQL リソース (データ ファイル、アクセス許可など) を物理的および論理的に分離することもできます。
2番目のより興味深い側面（これがあなたの質問の主な意図だと思います）については、コードベースの「移行」アプローチの利用を検討するかもしれません-たとえば、FluentMigratorなどを使用します。各ブランチが最初に作成された標準のベースライン スキーマがある場合は、各ブランチの機能開発の一環としてコードで適切な移行を作成できます (そして、それらをそのブランチの SQL インスタンスに適用します)。ブランチをトランクにマージするときが来たら、そのブランチの移行もマージしてから適用します。
せいぜい、これは、マージ後にトランク インスタンスに対して移行ツールを実行するだけで、すべてのブランチの移行を適用できることを意味します。このようなツールは、どの移行が適用されたかを (カスタム データベース テーブルを介して) 自動的に追跡するためです。再適用しないでください。また、開発中にトランク コード (移行を含む) を機能ブランチに定期的にマージし、それらの移行を適用している場合、機能ブランチのスキーマが最新の状態に保たれていることも確認できます。 、マージ時の厄介な驚きを最小限に抑えます。
トランクを本番環境に展開するときになると、これらの同じ移行がもう一度適用されます。FluentMigrator は、コンソール アプリケーション、NAnt、MSBuild、Rake などのさまざまなランナーを提供します。
単純な連続した整数 (1、2、...) ではなく、タイムスタンプ ベース (201210241033 など) の移行 ID 戦略を使用して、競合や変更が意図したシーケンスから適用される可能性を最小限に抑えることを強くお勧めします。