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

Question

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

要具体说明问题，请考虑以下方案时间表：

1. 开发人员A创建一个新的迁移文件，时间戳为上午9:00
2. 开发人员B创建另一个新的迁移文件，时间戳为上午10:00
3. 开发人员B检查日期上午10:00（上午11:00）的迁移
4. 开发人员A检查上午9:00（上午11:30）的迁移

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

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

Answer 1

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

为了避免迁移冲突：

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

现在你的场景看起来像这样：

1. 开发人员A创建一个新的迁移文件，时间戳为上午9:00
2. 开发人员B创建另一个新的迁移文件，时间戳为上午10:00
3. 开发人员B从存储库中提取。 意识到没有新的变化，在早上10点到凌晨11点进行迁移检查
4. 开发人员A从存储库中提取，运行迁移和测试套件，解决任何冲突并在上午11:30推送到存储库（好的，也许是11:35）。

永远不要推送到共享仓库而不确保您的更改不会引入冲突或破坏构建。

Answer 2

我们总是创建一个bootstrap rake任务。 此任务将删除开发数据库，​​依次运行所有迁移，然后使用虚假测试数据填充它。

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