实体框架迁移 - 分支管理

11
我已经在一个全新的项目上使用了Entity Framework代码优先迁移一段时间了,并且它们在应用程序的主干版本上一直运行良好。
然而,现在我们处于项目的分支创建阶段,因为我们有多个工作流。作为最后一次工作的一部分,我们意识到在分支之间使用迁移可能会有问题 - 所以我的问题是人们发现管理这种情况的最佳方式是什么?
例如(我显然简化了这些内容以供讨论):
A分支:Developer 1添加了“Add-UserDateCreated”迁移,该迁移向User实体添加字段。迁移文件包含添加字段的代码,并具有当时的模型状态。
B分支:Developer 2添加了“Add-UserMiddleName”迁移,该迁移向User实体添加另一个字段。迁移文件包含添加字段的代码,并具有当时的模型状态(但它显然没有在其他迁移中添加的字段)。
这些迁移在它们的分支上正常工作,但是当您将它们合并回主干时,您就被卡住了:
您不能只保留单个迁移文件,因为存储的模型状态将不正确。例如,“Add-UserMiddleName”迁移应具有添加“Add-UserDateCreated”字段的模型状态-但它不会。
您不能将迁移合并为一个文件,因为您会遇到同样的问题*
这意味着真正避免这些问题的唯一方法是为每个分支使用不同的数据库副本,在将其合并回主干时忽略迁移,并在完成合并时(在数据库的主干版本上)添加一次性主迁移-但是这可能会导致一个迁移中有很多更改,这从来不是一个好主意(并且还会失去您在迁移类中编写的任何自定义代码)。
那么其他人如何管理这种情况?我很想知道其他人的意见。
*如果有人知道实际世界中会引起什么问题,请告诉我。
1个回答

6
当你在一个分支上工作并需要进行迁移时,你总是需要考虑其他(活动的)分支的状态。例如,如果主干上有你没有的迁移,你应该在创建新的迁移之前将它们合并到分支中。一旦你在分支上创建了迁移,最好将其合并回主干。
所以在你的例子中,A和B开发者需要相互沟通。B开发者意识到需要迁移,应该检查是否已经完成了其他迁移,并将它们合并到她的分支中,然后再创建“中间用户名称”迁移。
我发现将迁移视为整个团队的死锁很有用(如果你能理解的话)。新的迁移或计划创建它们应该在每日站立会议上提及。有时候,在忙碌的时候,将所有迁移记录在白板上让所有团队成员看到可能会很有用。
我还发现,迁移必须是小的提交,这样它们就可以轻松地在分支之间移植。
还应该注意,使用像Git这样擅长分支、合并和挑选的版本控制系统会有所帮助。

谢谢Martin - 这是另一种有用的方法。我想我以前从来没有考虑过像这样在进行更改时合并它们,通常选择在所有更改合并回主干后重新构建所有迁移。我想问题是哪种方式更好? :) - stevehayter

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接