不过,现在我们正在创建一个分支机构,因为我们有多个工作流.作为最后一批工作的一部分,我们意识到在分支机构中使用迁移可能是有问题的 – 所以我的问题是人们发现管理这个的最佳方法是什么？
例如(为了讨论,我已经明确地简化了这些)：
分行A：
Developer 1添加了一个“Add-UserDateCreated”迁移,它向User实体添加一个字段.迁移文件包含添加该字段的代码,并且具有当时的模型状态.
分行B：
开发人员2添加了一个“Add-UserMiddleName”迁移,它向User实体添加了另一个字段.迁移文件包含添加字段的代码,并且具有当前的模型状态(但是显然没有在其他迁移中添加该字段).
这些迁移在他们的分支上工作正常,但是当您将它们合并到主干中时,您会卡住：
>您不能只保留各个迁移文件,因为存储的模型状态将不正确.例如,“Add-UserMiddleName”迁移应该具有添加了“Add-UserDateCreated”字段的模型的状态,但不会.
>您遇到同样的问题时,无法将迁移合并到一个文件中*
这意味着真正避免这些问题的唯一方法是在每个分支的数据库的不同副本上工作,当您将合并到中继线时忽略迁移,并且在合并完成时添加一次性主机迁移(on数据库的中继版本) – 但是您可能在一次迁移中可能会遇到很多变化,这绝不是一个好主意(也会丢失您在迁移类中编写的任何自定义代码).
那么其他人如何管理这种情况呢？我很想知道别人的意见.
*我很好奇,如果有人知道,这真的会在现实世界中造成什么问题？
解决方法
所以在你的例子中,开发人员A和B需要相互沟通.开发人员B意识到需要进行迁移,应该在创建“中间用户名”迁移之前检查其他迁移是否已经完成并将其合并到她的分支.
我发现将迁移视为整个团队的死锁(如果这样对你有意义)是有用的.)在日常架构中应该提到新的迁移或创建计划的计划.有时,当事情忙碌时,将所有迁移列表保存在白板上可供所有团队成员查看.
我也发现迁移很小,至关重要,使得他们在分支机构之间轻松便携.
还应该注意的是,它有助于使用一个良好的分支,合并和樱桃采集的版本控制系统,例如Git.
