0

在開發過程中,我喜歡像Entity Framework 4.3 Migrations這樣的框架(儘管我需要它使用sql腳本而不是Migration類),使所有開發人員數據庫保持最新狀態。有人進行更新以獲取最新源代碼,他們嘗試運行應用程序並獲取他們需要將其數據庫更新到最新遷移(或自動發生遷移)的錯誤。遷移文件具有時間戳,因此開發人員不必擔心命名兩個文件相同或文件需要執行的順序。設計完整的數據庫遷移堆棧

當我準備構建WebDeploy部署包時,我希望包中包含將生產數據庫移至最新的db版本所需的腳本。所以不知何故,MSBuild或WebDeploy需要決定哪些腳本必須打包。對於部署,我不希望應用程序嘗試像EF提供的那樣嘗試自我更新。我想要將軟件包交給IT部門,或者通過部署服務器進行自動部署。

我的一些問題是:

  1. 能EF 4.3使用SQL腳本,而不是DBMigration班我的發展需要的工作(我已經使用它爲我的ORM所以它如果能夠很好)?

  2. MSBuild或WebDeploy是否理解數據庫遷移的概念(例如它是否識別EF 4.3遷移歷史表),還是必須確保僅爲其提供運行所需的腳本,以便將我的prod db到最新的遷移?手動確定應該包含哪些腳本不是我想要做的,因此是否存在理解遷移的MS WebDeploy擴展?

  3. 我的擔憂和想法是否有效?我只是在研究這個東西,所以我不知道。

回答

2

我認爲你的顧慮是有效的。在開發過程中,任何使開發者機器保持同步的東西都可以。部署時需要更多的控制。

在我的項目中,我們決定只使用基於代碼的遷移,以確保所有數據庫以相同的步驟以相同的順序遷移。自動遷移和數據庫創建被自定義初始化策略禁用,該策略僅檢查數據庫是否存在並且是有效的。

我在Prevent EF Migrations from Creating or Changing the Database中寫了更多關於細節的內容。我也看了一下merge conflicts這將最終發生在多個開發人員。

0
  1. 可以通過調用SQL方法運行中的類SQL,或通過使用與更新的數據庫命令的參數-script生成從遷移SQL。

  2. 不。他們正在考慮增加對webdeploy的支持,但在rtm之前顯然決定不支持它。然而,他們確實發佈了一個命令行應用程序(顯然是powershell腳本),您可以從中調用。

我在我的項目做的是建立在我的應用程序的啓動模塊和運行沒有被自動部署任何遷移 - Triggering EF migration at application startup by code。這並不完美,開發人員必須在更改db之前獲取最新版本才能運行應用程序,但它適用於最新和部署。