您如何与开发团队一起管理 Ruby on Rails 迁移？
我们有一个开发团队，每个人都将使用 Rails 工具为我们的系统开发数据库迁移。起初，迁移似乎是管理数据库模式更改的好方法，但随着我们的继续，以分布式方式管理更改变得越来越困难。如果我们各自开发迁移，如何解决出现的问题？
为了具体说明问题，请想象以下场景时间线：
- 开发人员 A 创建一个时间戳为上午 9:00 的新迁移文件
- 开发人员 B 创建另一个时间戳为上午 10:00 的新迁移文件
- 开发人员 B 检查日期为上午 10:00 的迁移上午 11:00
- 开发人员 A 在上午 11:30 检查日期为上午 9:00 的迁移
这里可能会出现许多问题，特别是如果两个迁移文件在其更改中发生冲突，但最基本的问题是有些人在上午 9:00 迁移签入时运行了上午 10:00 迁移。与迁移关联的时间戳当然是创建文件时的时间戳，而不是签入时的时间戳，这会弄乱 Rails 迁移器。
这是一个可以解决的问题，但解决方案可能有很多不同的选择。解决这个问题的最佳方法（或至少是好方法）是什么？
We have a team of developers who are each going to be developing database migrations for our system using the Rails tools. Migrations seems at first like a great way to manage changes to the database schema, but as we go on it has become harder to manage changes in a distributed way. If we each develop migrations on our own, how can we reconcile the problems that occur?
To be specific about the problems, imagine the following scenario timeline:
- Developer A creates a new migration file timestamped with 9:00 a.m.
- Developer B creates another new migration file timestamped with 10:00 a.m.
- Developer B checks in the migration dated 10:00 a.m. at 11:00 a.m.
- Developer A checks in the migration dated 9:00 a.m. at 11:30 a.m.
There are a number of problems that can occur here, especially if the two migration files conflict in their changes, but the most basic problem is that some people have run the 10:00 a.m. migration when the 9:00 a.m. migration is checked in. The timestamps associated with the migrations are of course when the file was created, not when it was checked in, which will mess up the Rails migrator.
This is a fixable problem, but the solution could be plenty of different options. What is the best way (or at least a good way) to solve this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这看起来更像是一个团队沟通问题，或者是一个简单的流程问题。迁移版本从顺序编号更改为时间戳，以避免开发人员 A 和 B 创建具有相同版本的迁移的问题。
为了避免迁移冲突：
现在您的场景如下所示：
在确保您的更改不会引入冲突或破坏构建的情况下，切勿推送到共享存储库。
This seems more like a team communication problem, or a plain process problem. The migration versions where changed from sequential numbers to timestamps to avoid the problem where developers A and B create a migration with the same version.
In order to avoid migration conflicts:
Now your scenario looks like this:
Never push to a shared repo without making sure your changes won't introduce a conflict or break the build.
我们总是创建一个 bootstrap rake 任务。此任务删除开发数据库，依次运行所有迁移，然后用虚假的测试数据填充它。
除了应用程序中有大量内容可供使用之外，您还必须运行所有迁移。如果您在提交内容之前执行此操作，那么您确信所有迁移也适用于其他人。
We always create a bootstrap rake task. This task drops the development db, runs all migrations in turn and then fills it with bogus testing data.
Besides having tons of content in your app to use, you also have to run all migrations. If you do this before you commit your stuff, you're sure all migrations will work for others as well.