清除旧的Rails迁移文件是个好主意吗？

Question

我已经运行了大型Rails应用程序超过2年，而且我的ActiveRecord迁移文件夹日复一日地发展到150多个文件。

在迁移过程中仍有一些非常旧的模型，在应用程序中不再可用。我想要删除它们。

你怎么看？您是否经常从代码库中清除旧的迁移？

Answer 1

一旦我点击主要网站发布，我就会将迁移推广到一个并重新开始。一旦迁移版本数量达到75左右，我就会觉得很脏。

Answer 2

The Rails 4 Way第177页： 塞巴斯蒂安说......

  

一个鲜为人知的事实是，您可以删除旧的迁移文件（同时   仍然保留较新的）以保持db/migrate文件夹   易于管理的尺寸。您可以将旧迁移移动到   db/archived_migrations文件夹或类似的东西。一旦修剪完毕   迁移文件夹的大小，使用rake db:reset任务   （重新）从db/schema.rb创建数据库并将种子加载到   你当前的环境。

Answer 3

它们相对较小，所以我会选择保留它们，仅供记录。

你应该编写你的迁移而不引用模型或应用程序的其他部分，因为它们会回到你的困扰;）

查看以下指南：

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

Answer 4

为什么呢？除非磁盘空间存在某种问题，否则我没有理由删除它们。我想如果你绝对肯定你永远不会再回滚任何东西，那么你可以。但是，似乎节省几KB的磁盘空间来做这件事是不值得的。此外，如果您只想删除引用旧模型的迁移，则必须手动查看它们，以确保不删除应用中仍然使用的任何内容。对我来说，很多努力都没有什么好处。

Answer 5

我个人喜欢在迁移文件中保持整洁。我认为，一旦您将所有更改推送到prod，您应该真正考虑归档迁移。我遇到的唯一困难是，当Travis运行时它运行db:migrate，所以这些是我使用的步骤：

1. 将历史迁移从/db/migrate/移至/db/archive/release-x.y/

2. 使用/db/archive/release-x.y目录中上次运行迁移的版本号手动创建新的迁移文件，并将描述更改为from_previous_version。使用旧的版本号意味着它不会在您的prod机器上运行并且搞乱。

3. 复制schema.rb部分内的ActiveRecord::Schema.define(version: 20141010044951) do内容并粘贴到change更改日志

的from_previous_version方法中

4. 检查所有内容，罗伯特应该是你父母的兄弟。

唯一的另一个考虑因素是您的迁移是否会创建任何数据（我的测试方案包含所有数据，因此我没有此问题）

Answer 6

我偶尔会清除已经在生产中应用的所有迁移，我至少看到了两个原因：

1. 更易于管理的文件夹。如果添加了一些新的迁移，则更容易发现。
2. 更清晰的文本搜索结果（项目中的全局文本搜索不会导致大量无用的匹配，因为旧的迁移，比如3年前有人创建了一些专栏）。

Answer 7

请参阅http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

迁移不是数据库的表示形式：structure.sql或schema.rb是。迁移也不是设置/初始化数据的好地方。 <{1}}或rake任务更适合这种任务。

那么什么是迁移？在我看来，它们是如何更改数据库模式的指令 - 向前或向后（通过回滚）。除非出现问题，否则只能在以下情况下运行：

1. 在我的本地开发机器上，作为测试迁移本身并编写架构/结构文件的方法。
2. 在同事开发者计算机上，作为一种在不删除数据库的情况下更改架构的方法。
3. 在生产计算机上作为一种在不删除数据库的情况下更改架构的方法。

一旦运行，他们应无关紧要。当然会发生错误，因此如果您需要回滚，您肯定希望将迁移保留几个月。

CI环境永远不需要运行迁移。它会降低CI环境的速度并且容易出错（就像Rails指南所说的那样）。由于您的测试环境只有短暂的数据，您应该使用db/seeds，它将从schema.rb / structure.sql加载并完全忽略您的迁移文件。

如果您正在使用源代码管理，那么保持旧迁移没有任何好处;它们是源历史的一部分。将它们放在存档文件夹中可能是有意义的，如果这是你的咖啡。

说到这一切，我强烈认为清除旧的迁移是有意义的，原因如下：

• 它们可能包含太旧的代码，它将不再运行（就像删除模型一样）。这为想要运行rake db:setup。
的其他开发人员创建了一个陷阱
• 他们会减慢rake db:migrate - 类似的任务，并且在某个年龄段之后无关紧要。

为什么他们无关紧要？再次出于两个原因：历史记录存储在源代码管理中，实际的数据库结构存储在structure.sql / schema.rb中。我的经验法则是，大约12个月以上的迁移完全无关紧要。我删除它们。如果有一些原因我想要回滚早于此的迁移，我确信数据库在那段时间内已经发生了足够的变化，需要编写新的迁移来执行该任务。

那么你如何摆脱迁移？这些是我遵循的步骤：

1. 删除迁移文件
2. 编写rake任务以删除数据库的schema_migrations表中的相应行。
3. 运行grep以重新生成structure.sql / schema.rb。
4. 验证structure.sql / schema.rb中唯一更改的内容是删除与您删除的每个迁移相对应的行。
5. 部署，然后在生产时从步骤2运行rake任务。
6. 确保其他开发人员在其计算机上运行第2步中的rake任务。

第二项是保持架构/结构准确的必要条件，这也是唯一真正重要的事情。

Answer 8

一旦您感到舒适并且不需要他们，就可以删除旧的迁移。迁移的目的是拥有一个用于制作和回滚数据库更改的工具。一旦做出改变并在生产中进行了几个月，您很可能不再需要它们。我发现，经过一段时间后，它们只是残留在你的回购，搜索和文件导航中。

有些人会从头开始运行迁移以重新加载他们的开发数据库，​​但这并不是他们想要的。您可以使用rake db:schema:load加载最新的架构，使用rake db:seed使用种子数据填充它。 rake db:reset为你做了两件事。如果您的数据库扩展程序无法转储到schema.rb，那么您可以使用sql schema format for ActiveRecord并改为运行rake db:structure:load。

Answer 9

是。我想如果你已经从数据库中完全删除了任何模型和相关表，那么值得将它放在迁移中。如果迁移中的模型引用不依赖于任何其他内容，则可以将其删除。虽然迁移永远不会再次运行，因为它已经运行，即使您没有从现有迁移中删除它，但每当您将数据库迁移时，都会导致问题。

更好的是从迁移中删除该引用。并且在重大发布到实时数据库之前重构/最小化迁移到一个或两个文件。