首先使用数据库时如何管理不同分支中的数据库模式更改?

How to manage db schema changes in different branches when using db first?

我有一个 Entity Framework 5 DB-First 项目,我们刚刚将其从 TFS 迁移到 Git。在 TFS 中,我们使用 RedGate 的 SQL 源代码控制使数据库保持最新,这是一种不错的做事方式,假设每个人都在开发主干,因为分支是如此困难,所以几乎每个人都在致力于最新版本的数据库模式。

现在我们在 Git,但是,我希望数据库更改成为功能分支的一部分。由于 Git 允许如此轻松地从一个分支跳到另一个分支,我希望开发人员可以从包括数据库更改在内的功能跳转到没有这些更改的功能。代码更新得很好——但是数据库呢?我怀疑 RedGate 的产品能否在如此短的时间内处理上下迁移——或者我错了吗?如果 RedGate 无法处理这些上下迁移,那么在我的代码中执行此操作的正确方法是什么?

顺便说一句,我确实搜索了其他类似的问题,并找到了 this one,尽管那里的答案是在功能分支中包含迁移脚本。对于 "up" 迁移来说这一切都很好,但是如果我在一个分支中编写一个功能,然后我切换到另一个分支对其他人的拉取请求进行代码审查,然后我所做的更改到我分支机构中的本地数据库应该以某种方式恢复。但是怎么办?

更新: RedGate 通过将我转介给 this article 来回应支持电话。基本上,如果你想切换分支,你必须从源代码管理 unlink/re-link 你的数据库。而且您不能创建或合并分支。简而言之,呃。有更好的建议吗?

迄今为止我发现的最佳解决方案来自 RedGate - 他们的 Migrations V2 Beta。您可以在每个分支中进行提交,当您在分支之间切换时,您 "Get Latest" 在数据库选项卡上将本地数据库更新为适用于该分支的数据库模式。

它在 80% 的情况下工作正常,但它(还)不是一个完美的解决方案

  • 如果您在迁移之前将分支切换到以前版本的架构,则无法运行 "down" 脚本。
  • 启用 FILESTREAM 后,系统会出现一些问题。我已将此报告给他们的技术支持,他们已经承认了这个错误,所以希望这会很快得到解决。

基本上,它被称为 "Beta" 是有原因的。

无论如何,我暂时将其标记为解决方案,但如果有人提出更好的想法,让我们听听吧。

确实是一个乏味的问题。我目前为每个主要分支(开发、发布和增强)使用单独的文件夹,这迫使我执行以下操作

  • 每个主要分支机构的数据库
  • 每个主要分支都配置为连接到相应的数据库。一般用于单元测试和开发
  • 还为每个分支配置了 Web 服务器。例如。 http://localhost/develop

由于配置文件的原因,合并有点乏味,但到目前为止,这种技术已经奏效了几年。