2014-02-23 61 views
4

在我們的應用程序中,我們使用了一個實體模型和數據庫優先方法,並且在服務器上有一個數據庫模式。我們也使用git進行源代碼管理。使用單個實體模型管理大型項目

問題發生時,我們中的一些開發者在需要數據庫更改而這經常發生所以我們目前的解決方案的新功能的工作如下:

  1. 創建從主分支一個新的分支。
  2. 爲測試創建一個新的數據庫,它與我們現場使用的數據庫相同。
  3. 當完成將新功能轉移到主分支並從新創建的分支中提取新分支時,請使用新分貝更改獲取新的實體模型,並在發佈時在我們的實時分貝上應用sql。

如果我們在某個新分支上停留太久,會發生問題,因爲我們正在切換分支。

那時候我們的主分支改變了很多,並且還有它的活動分貝,所以我們的測試數據庫結構與我們創建新分支的時間有很大不同,然後我們在合併新分支和掌握一個。

我們每次都成功,但很難管理它。我想知道是否有人知道更好的管理體系和工作流程。

+0

您是否使用EF遷移? – trailmax

+0

不,我們不這樣做,我認爲EF遷移只能在代碼優先方法中使用。 – Aleks

+2

我的不好,錯過了「數據庫第一」。 Code First方法通過遷移修復了這個問題。我會考慮遷移到Code First來解決這個問題。 – trailmax

回答

1

是的,這個叮咬。 .edmx文件經常遇到合併衝突,因爲它存儲了域配置數據和設計器對象佈局。 (前者應該是源代碼控制的,後者應該在.user文件中。)侮辱傷害:文件被設計爲不可讀(僅由工具管理),因此在合併時很容易失敗。正是由於這個原因,我們才拋棄了.edmx(「數據庫優先」)方法,並走向了Code First。一些精心設計的單元測試驗證實體類與表模式匹配,並且我們有一個更簡單得多的工作流程。