EF 4.3.1 コードベースの移行の使用を検討していますが、移行を現在の開発/展開方法論と統合する方法が明確ではありません...
問題のアプリはデスクトップ WPF アプリで、各デスクトップには独自の SQL Server インスタンスがあります (それぞれに 4 つの個別のデータベースがあります)。ローカル IT サポートなしで「フィールド」環境に展開されます。データベースの移行は、インストーラー (おそらく InstallShield) によって実行される SQL スクリプトを使用して行う必要があります。PMC プロンプトでコマンドを実行してデータベースをフィールドの場所で展開/アップグレードするときに、データベースをアップグレードできる人は誰もいません。したがって、EF 移行からの最終的な「出力」は、インストーラーが選択的に適用する一連の SQL スクリプトでなければなりません。
また、複数の開発者が同時にデータベースの変更を行っています。DBA はいません。各開発者は、コード (モデル) の変更を TFS にチェックインするだけで、次に get-latest を実行したときに、モデルへの変更によって新しいデータベースが開発システムに自動的に作成されます。では、各開発者が (ローカル データベースを削除/再作成するのではなく) 独自のローカル マイグレーションを実行し、それらのマイグレーションを管理/統合/結合するにはどうすればよいでしょうか? そして、衝突はどうですか？
開発および単体テスト中、各開発者は、1 回のチェックアウト/チェックインの反復中に (全体の) ローカル データベースを複数回削除する場合があります。アプリの再起動時にデータベースが自動的に再構築されるため、これは Code First でうまく機能します。ただし、これは、データベースの _MigrationHistory テーブルも削除されることを意味します。これをどのように処理しますか？各開発システムの移行履歴は必要ありませんか? そうでない場合、提供されたシステムに適用する必要がある集約的な変更をどこでどのように検出しますか?
データベースを移行するメカニズムに対処するために移行を使用することの価値は理解できますが、集中型データベースの「変更管理」のボトルネックを開発サイクルに導入せずに移行を利用する方法は明らかではありません。 Code First の主なメリット。
どんな洞察/アドバイスも大歓迎です!
お父さん猫