ste*_*ter 10 sql sql-server entity-framework ef-migrations
我一直在一个全新的项目上使用Entity Framework代码进行一段时间的迁移,到目前为止他们在应用程序的主干版本上工作得很好.
但是,由于我们正在进行多个工作流,因此我们现在正处于创建分支机构的项目中.作为最后一部分工作的一部分,我们意识到跨分支机构使用迁移可能会有问题 - 所以我的问题是人们找到了最好的管理方式？
例如(为了讨论,我显然简化了这些):
分支A:开发人员1添加"Add-UserDateCreated"迁移,该迁移向User实体添加字段.迁移文件包含添加字段的代码,并且当时具有模型状态.
分支B:开发人员2添加"Add-UserMiddleName"迁移,该迁移向User实体添加另一个字段.迁移文件包含添加字段的代码,并且当时具有模型状态(但显然没有在其他迁移中添加字段).
这些迁移在其分支上工作正常,但是当您将它们合并回主干时,您会遇到困难:
这意味着真正避免这些问题的唯一方法是为每个分支处理数据库的不同副本,在合并到主干时忽略迁移,并在合并完成时添加一次主迁移(on数据库的主干版本 - 但是在一次迁移中你可能最终会有很多变化,这绝不是一个好主意(并且还会丢失你在迁移类中编写的任何自定义代码).
那么其他人如何管理这种情况呢？我很想知道别人的意见.
*我很好奇这会在现实世界中造成什么问题,如果有人知道的话？
当您在分支机构上工作并需要迁移时,您始终需要考虑其他(活动)分支的状态.例如,如果主干上存在您在分支上没有的迁移,则应在创建新迁移之前将它们合并到分支.在分支上创建迁移后,将其合并回主干可能是个好主意.
因此,在您的示例中,开发人员A和B需要相互通信.开发人员B,意识到需要迁移,应该检查是否已完成其他迁移,并在创建"中间用户名"迁移之前将它们合并到她的分支.
我发现将迁移视为整个团队的死锁是有用的(如果这对你有意义的话.)新的迁移或创建它们的计划应该在日常站立中提到.有时,当事情繁忙时,将所有迁移列表保存在白板上供所有团队成员查看可能是有用的.
我还发现,迁移是小型提交至关重要,这使得它们可以在分支之间轻松移植.
还应该注意的是,例如,使用适合分支,合并和挑选的版本控制系统是有帮助的,例如Git.
| 归档时间： |
|
| 查看次数： |
1052 次 |
| 最近记录： |