EF遷移 - 如何在開發和部署期間進行管理？

Question

我們正在考慮使用EF 4.3.1基於代碼的遷移，但不清楚如何將遷移與我們目前的開發/部署方法集成在一起...

問題應用程序是桌面WPF應用程序，每個桌面都有自己的SQL Server實例（每個實例都有4個獨立的數據庫）。它被部署到「本地」環境中，並且沒有本地IT支持。任何數據庫遷移都必須使用安裝程序（可能是InstallShield）執行的SQL腳本完成。在現場位置部署/升級數據庫時，不會有任何人可以在PMC提示符下運行命令來升級數據庫。因此EF Migrations的最終「輸出」必須是一組SQL腳本，安裝程序將選擇性地應用這些腳本。

此外，我們有多個開發人員正在併發更改數據庫..沒有DBA。每個開發人員只需簡單地檢查他們對TFS的代碼（模型）更改，並在下一次獲取最新時間時，對模型的更改會自動在其開發系統上創建新數據庫。那麼我們現在應該如何讓每個開發人員執行他們自己的本地遷移（而不是刪除/重新創建其本地數據庫），然後管理/合併/合併這些遷移？那碰撞怎麼辦？

在開發和單元測試期間，每個開發人員可能會在單次簽出/簽入迭代期間多次刪除其（整個）本地數據庫。這對Code First非常有用，因爲數據庫在應用程序重新啓動時會自動重建。但這意味着數據庫中的_MigrationHistory表也被刪除。我們如何處理這個問題？我們不需要每個開發系統的遷移歷史嗎？如果不是，那麼我們在何處/如何檢測需要應用於交付系統的總體更改？

我可以看到使用遷移來處理遷移數據庫的機制的價值，但不清楚的是如何利用它而不會將集中式數據庫「變更控制」瓶頸引入開發週期，並且從而失去了Code First的主要優勢之一。

任何有識之士/建議將不勝感激！

DadCat

Answer 1

我知道這是一個老問題，但我想我會發布一些我與EF遷移（V6.1）的經驗。

每個開發者都可以。遷移被放入名稱中帶有時間戳的類中，因此不會發生衝突。開發人員的機器上的數據庫將在獲取最新版本並運行應用程序（或update-database命令）後進行更新。

刪除本地數據庫並重新創建是好的。只要確保開發人員在添加其他遷移之前運行update-database，或者事情就會失去同步。我有點困惑，爲什麼他們需要刪除本地數據庫，但這是超出範圍。您可能會發現您的流程需要更改以適應EF遷移。

我無法幫助您解決安裝程序的問題，因爲類似的問題將我帶到了這裏。 update-database命令確實有一個-script選項，它將生成適當的更改腳本，但我不清楚如何在構建服務器上自動執行該腳本。