卷起移民？

Question

据我所知，迁移的关键在于您可以在开发的最后阶段将数据库恢复到已知状态。

现在我仍在“充实”我的第一个Rails应用程序，我想知道是否可以将我的迁移扩展到更大的迁移而不是几十个更改。

Answer 1

迁移的关键在于您基本上有一个数据库更改日志，因此其他开发人员可以知道已经进行了哪些更改，或者确保您的生产环境获得了在开发过程中所做的相同更改。

关于你的问题：当然。如果您创建新模型，然后在几分钟后决定“此列可能只是字符串而不是文本”，请回滚迁移，更改列，然后再次迁移。无需创建新的迁移。

除非，您已经提交了之前可能已被其他开发人员提取的源代码管理迁移，或者您已经在生产服务器上应用了迁移。然后你应该使用新的迁移。

Answer 2

作为rspeicher的附录，我限制了迁移是否已经发布的约束，而不是它是否已被其他开发人员使用。如果它仍然是预发布的，那么可以通过使用正在使用的SCM的取指钩来通知开发团队是否需要为主代码存储库的任何更新运行迁移。任何配置管理更改都是如此，而不仅仅是迁移。例如，更改initializers文件夹中某些内容的实现可能对开发模式下正在运行的脚本/服务器实例没有影响。对于大多数技术中的大多数团队以及持续集成的某些配置而言，这最终是必要的机制。或者，您需要团队中出色的沟通渠道，以确保每个人都知道配置更改和重新启动是必要的。