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

Question

我一直在运行一个大的Rails应用程序超过2年，而且我的ActiveRecord迁移文件夹一天天的增长到150多个文件。

有很旧的模型，在应用程序中不再可用，仍在迁移中引用。我正在考虑删除它们。

您认为如何？你通常会从你的代码库中清除旧的迁移吗？

Answer 1

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

你应该写你的迁移，而不引用模型，或应用程序的其他部分，因为他们会回来给你难以忘怀;）

查阅这些准则：

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

Answer 2

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

Answer 3

一旦我点击一个主要的网站发布，我会将迁移到一个，并开始新鲜。我觉得一旦迁移版本号码变得75左右就会变脏。

Answer 4

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

所以更好地从迁移中删除该引用。重构/最小化迁移到一个或两个文件，然后再发布到实时数据库。

Answer 5

没关系一旦你感到舒适就可以移除旧的迁移，他们将不再需要。迁移的目的是为了制作和回滚数据库更改。一旦变更完成并投入生产几个月，赔率就不太可能再次需要它们。我发现，过了一段时间，他们只是一堆残酷的回忆，搜索和文件导航。

有些人会从头开始迁移以重新加载他们的开发数据库，​​但这并不是他们的目标。您可以使用rake db:schema:load加载最新架构，并使用来填充种子数据。 rake db:reset为你做。如果您的数据库扩展名不能转储到schema.rb，则可以使用sql schema format for ActiveRecord并运行​​。

Answer 6

就我个人而言，我喜欢将事情保持在迁移文件中。我认为，一旦你把所有的改变都推向了现实，你应该真正考虑归档迁移。我曾经碰到这样的唯一的困难是，特拉维斯运行，当它运行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段内并粘贴到您from_previous_version的changelog的change方法

4. 检查所有在和罗伯特应该是你父母的兄弟。

其他唯一的考虑是，如果你的迁移创建（我的测试场景包含了所有自己的数据，所以我没有这个问题）

Answer 7

The Rails 4 Way第177页的任何数据： 塞巴斯蒂安说.. 。

一个鲜为人知的事实是，你可以删除旧的迁移文件（而 仍保持较新的）到db/migrate文件夹保存到 管理的大小。您可以将旧版迁移到 db/archived_migrations文件夹或类似的东西。修改 迁移文件夹的大小后，使用rake db:reset任务到 （重新）从db/schema.rb创建数据库并将种子加载到 当前环境中。

Answer 8

我偶尔会清除所有迁移，已经被应用于生产中，我看到至少有2个方面的原因：

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

Answer 9

我同意，在100 +迁移中没有价值，历史是一团糟，没有简单的方法来跟踪单个表上的历史记录，并增加了文件查找的混乱。只要慕达IMO :)

这里有一个3个步骤指南壁球全部迁移到相同的模式作为生产：

第一步：从生产模式

# launch rails console in production 
stream = StringIO.new 
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil 
stream.rewind 
puts stream.read 

这是副本 - 可以迁移，减去明显的标题

步骤2：m在没有运行生产的情况下执行迁移

这很重要。使用上次迁移并更改其名称和内容。 ActiveRecord在其schema_migrations表中存储日期时间编号，以便它知道它运行的是什么，而不是。重用最后一个，它会认为它已经运行。

例子：rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

并把该模式存在。

步骤3：验证和故障排除

局部地，耙分贝：降，耙分贝：创建，耙分贝：迁移

确认模式是相同的。我们遇到的一个问题是，日期时间“NOW（）”的模式，这是我能找到的最好的解决办法：https://stackoverflow.com/a/40840867/252799

Answer 10

见http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

迁移是不数据库的表示：要么structure.sql或schema.rb是。迁移也是而不是是设置/初始化数据的好地方。 db/seeds或rake任务更适合那种任务。

那么什么是迁移？在我看来，他们是如何更改数据库模式的指示 - 无论是向前还是向后（通过回滚）。作为一种测试迁移本身写的模式/结构文件

1. 在我的本地开发机器：除非出现了问题，就应该只在下列情况下运行。
2. 在同事开发人员机器上作为更改模式而不丢弃数据库的方式。
3. 在生产机器上作为更改模式而不丢弃数据库的方式。

一旦运行它们应该是无关紧要的。当然，错误会发生，所以如果你需要回滚的话，你一定要保持几个月的迁移。

CI环境不会有史以来需要运行迁移。它会减慢你的CI环境，并且容易出错（就像Rails指南所说）。由于您的测试环境只有短暂的数据，因此您应该使用rake db:setup，它将从schema.rb/structure.sql加载并完全忽略您的迁移文件。

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

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

• 它们包含的代码，太旧，将不再运行（例如，如果你删除一个模型）。这为想要运行rake db:migrate的其他开发人员创建了一个陷阱。
• 他们会减缓grep类似的任务，并且在一定的年龄之前是无关紧要的。

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

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

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

第二项是保持架构/结构准确，这是唯一真正重要的东西。