如何在开发团队中管理Ruby on Rails的迁移?

3
我们有一个开发团队,每个人都将使用Rails工具为我们的系统开发数据库迁移。迁移似乎是管理数据库模式变化的好方法,但随着我们的开发进展,以分布式方式管理变化变得更加困难。如果我们每个人都单独开发迁移,如何解决出现的问题呢?
具体来说,想象一下以下时间轴场景:
1. 开发人员A创建了一个新的迁移文件,时间戳为上午9:00。 2. 开发人员B在上午10:00创建了另一个新的迁移文件。 3. 开发人员B在上午11:00检入了时间戳为10:00的迁移。 4. 开发人员A在上午11:30检入了时间戳为9:00的迁移。
这里可能会出现许多问题,特别是如果两个迁移文件在其更改方面存在冲突,但最基本的问题是有些人在检入9:00迁移时已经运行了10:00迁移。与迁移相关联的时间戳当然是文件创建时的时间,而不是检入时的时间,这将混淆Rails迁移器。
这是一个可解决的问题,但解决方案可以有很多不同的选项。什么是最好的方法(或至少是一个好方法)来解决这个问题呢?

这更多是出于我的好奇心,你尝试过你所描述的场景吗?发生了什么事情? - Andy Gaskell
2个回答

6
这似乎更像是团队沟通问题或者纯粹的流程问题。迁移版本已从顺序编号更改为时间戳,以避免开发人员A和B创建具有相同版本的迁移的问题。
为了避免迁移冲突:
- 在创建迁移时始终让团队了解情况。这应该完全避免了这个问题。 - 在将代码更改提交到主共享存储库之前,始终从存储库中拉取并测试迁移(并运行测试套件)。这是一个必须遵循的安全网。
现在您的情况如下:
1. 开发人员A创建一个新的迁移文件,时间戳为上午9:00。 2. 开发人员B创建另一个新的迁移文件,时间戳为上午10:00。 3. 开发人员B从存储库中拉取。意识到没有新的更改后,在上午11:00将日期为上午10:00的迁移检入。 4. 开发人员A从存储库中拉取,运行迁移和测试套件,解决任何冲突,并在上午11:30(好吧,也可能是11:35)推送到存储库。
永远不要在确保您的更改不会引入冲突或破坏构建之前将其推送到共享存储库。

1
我认为这不是一个流程问题,而是缺乏内置检查,导致问题无法避免。使用普通文件的版本控制,在更新和存在冲突时会得到错误提示。对于有足够多开发人员和足够复杂的模式,这可能无法扩展。想象一下,你要检查的不只是一次更改,而是几十次更改。这虽然是不太可能的情景,但我仍然对此感到担忧。尽管如此,对于小团队来说,这可能是一个不错的做法,所以我支持这个观点。 - Rudd Zwolinski
1
在我看来,迁移比我见过的任何其他方法都要好。您通常如何跟踪和管理团队中的数据库更改?可能还有一些检查吗?当然可以...但那几乎就是一个插件,可以检测和处理此类冲突的SCM。 - txwikinger

0

我们总是创建一个Bootstrap Rake任务。该任务会丢弃开发数据库,依次运行所有迁移,然后用虚假测试数据填充它。

除了在您的应用程序中拥有大量可用内容外,您还必须运行所有迁移。如果在提交代码之前执行此操作,则可以确保所有迁移对其他人也有效。


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