您如何与开发人员团队一起管理 Ruby on Rails 迁移？答案

【问题标题】：How do you manage Ruby on Rails migrations with a team of developers?您如何与开发人员团队一起管理 Ruby on Rails 迁移？
【发布时间】：2009-09-03 20:27:14
【问题描述】：

我们有一个开发团队，每个人都将使用 Rails 工具为我们的系统开发数据库迁移。迁移起初似乎是管理数据库模式更改的好方法，但随着我们的继续，以分布式方式管理更改变得更加困难。如果我们每个人都自己开发迁移，我们如何解决出现的问题？

要具体说明问题，请想象以下场景时间线：

开发人员 A 创建一个新的迁移文件，时间戳为上午 9:00。
开发人员 B 创建另一个新的迁移文件，时间戳为上午 10:00。
开发人员 B 签入日期为上午 10:00 至上午 11:00 的迁移
开发人员 A 在上午 9:00 到上午 11:30 检查迁移

这里可能会出现很多问题，特别是如果两个迁移文件的更改发生冲突，但最基本的问题是有些人在上午 9:00 迁移时运行了上午 10:00 迁移签入。与迁移相关的时间戳当然是创建文件的时间，而不是签入的时间，这会弄乱 Rails 迁移器。

这是一个可以解决的问题，但解决方案可能有很多不同的选择。解决此问题的最佳方法（或至少是好方法）是什么？

【问题讨论】：

这更多是出于我的好奇心，但是您是否尝试过您描述的场景？发生了什么？

标签： ruby-on-rails version-control migration

【解决方案1】：

这似乎更像是一个团队沟通问题，或者一个简单的流程问题。迁移版本从序号更改为时间戳，以避免开发人员 A 和 B 创建具有相同版本的迁移的问题。

为了避免迁移冲突：

在创建迁移时始终让团队保持在循环中。这应该可以完全避免这个问题。
在将代码更改检查回主共享存储库之前，始终从存储库中提取并测试迁移（并运行测试套件）。这是一个应始终遵守的安全网。

现在您的场景如下所示：

开发人员 A 创建一个新的迁移文件，时间戳为上午 9:00。
开发人员 B 创建另一个新的迁移文件，时间戳为上午 10:00。
开发人员 B 从存储库中提取。意识到没有新的变化，请检查日期为上午 10:00 至上午 11:00 的迁移。
开发人员 A 从存储库中拉取数据，运行迁移和测试套件，解决所有冲突并在上午 11:30（好吧，也许是 11:35）推送到存储库。

永远不要在不确保您的更改不会引入冲突或破坏构建的情况下推送到共享存储库。

【讨论】：

我认为这不是流程问题，而是缺少内置检查以确保问题不会发生。使用普通文件的版本控制，更新时会出现错误并存在冲突。如果有足够多的开发人员和足够复杂的模式，这可能无法扩展。想象一下，您必须检查的不是一个签入更改，而是几十个更改。这是一个不太可能发生的情况，但这是我关心的事情。不过，对于小型团队来说，这可能是一个很好的方法，所以我投票赞成。
恕我直言，迁移比我见过的其他任何东西都要好。您通常如何跟踪和管理团队中的数据库更改？能不能多做些检查？当然......但这几乎是一个可以检测和处理此类冲突的 SCM 插件。

【解决方案2】：

我们总是创建一个引导 rake 任务。此任务删除开发数据库，依次运行所有迁移，然后用伪造的测试数据填充它。

除了在您的应用中使用大量内容之外，您还必须运行所有迁移。如果您在提交内容之前执行此操作，那么您确定所有迁移也适用于其他人。

【讨论】：