如何管理Rails与开发人员团队的迁移？

Question

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

要具体了解这些问题，请设想以下场景时间线：

1. Developer A创建一个以上午9:00为时间戳的新迁移文件，
2. Developer B创建另一个以上午10:00为时间戳的新迁移文件。
3. Developer B在上午10:00检查迁移。上午11:00
4. Developer A检查日期为上午9:00的迁移。上午11:30

这里可能会出现一些问题，特别是当两个迁移文件的更改发生冲突时，但最基本的问题是有些人已经运行了上午10:00。早上9点的时候迁徙。迁移是签入的。当然，与迁移相关的时间戳是在创建文件时，而不是在签入时，这会使Rails migrator陷入混乱。

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

Answer 1

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

为避免移徙冲突：

当涉及到迁移的创建时，

• 总是让团队处于循环状态。这将避免alltogether.
• Always从您的存储库和测试迁移(并运行您的测试套件)中提取的问题，然后再将您的代码更改签回主共享回购中。这是一个应该永远遵循的安全网。

现在您的场景如下所示：

1. Developer A创建一个以上午9:00为时间戳的新迁移文件，
2. Developer B创建另一个带有10:00
3. B从存储库中提取的时间戳的新迁移文件。意识到没有新的变化，检查在上午10:00的迁移。11:00 a.m.
4. Developer A从存储库中提取，运行迁移和测试套件，解决任何冲突，并在上午11:30(好的，也许11:35)推到存储库。

在没有确保您的更改不会导致冲突或破坏构建之前，千万不要推送到共享回购。

Answer 2

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

除了要在应用程序中使用大量的内容之外，您还必须运行所有迁移。如果您在提交自己的东西之前就这样做了，那么您肯定所有的迁移都会对其他人起作用。