清除旧的Rails迁移文件是个好主意吗？
我已经运行了大型Rails应用程序超过2年，而且我的ActiveRecord迁移文件夹日复一日地发展到150多个文件。
存在非常旧的模型，在应用程序中不再可用，仍在迁移中引用。 我想删除它们。
你怎么看？ 您是否经常从代码库中清除旧迁移？
它们相对较小，所以我会选择保留它们，仅供记录。
你应该编写你的迁移而不引用模型或应用程序的其他部分，因为它们会回到你的困扰;）
看看这些指南：
http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations
一旦我点击主要网站发布，我就会将迁移推广到一个并重新开始。 一旦迁移版本数量达到75左右，我就会觉得很脏。
Rails 4 Way第177页：塞巴斯蒂安说……
一个鲜为人知的事实是，您可以删除旧的迁移文件（同时仍保留较新的迁移文件），以使
db/migrate文件夹保持可管理的大小。 您可以将较旧的迁移移动到db/archived_migrations文件夹或类似的内容。 修改了迁移文件夹的大小后，使用rake db:reset任务从db/schema.rb（重新）创建数据库并将种子加载到当前环境中。
为什么？ 除非磁盘空间存在某种问题，否则我认为没有理由删除它们。 我想如果你绝对肯定你永远不会再回滚任何东西，那么你可以。 但是，似乎节省几KB的磁盘空间来做这件事是不值得的。 此外，如果您只想删除引用旧模型的迁移，则必须手动查看它们，以确保不删除应用中仍然使用的任何内容。 对我来说，很多努力都没什么好处。
我个人喜欢在迁移文件中保持整洁。 我认为，一旦您将所有更改推送到prod，您应该真正考虑归档迁移。 我遇到的唯一困难是当Travis运行时运行db:migrate ，所以这些是我使用的步骤：
-
将历史迁移从
/db/migrate/移至/db/archive/release-xy/ -
使用
/db/archive/release-xy目录中上次运行迁移的版本号手动创建新的迁移文件，并将描述更改为from_previous_version。 使用旧的版本号意味着它不会在您的prod机器上运行并且搞乱。 -
从
ActiveRecord::Schema.define(version: 20141010044951) do部分复制schema.rb内容并粘贴到from_previous_version更改日志的change方法中 -
检查所有内容，罗伯特应该是你父母的兄弟。
唯一的另一个考虑因素是，如果您的迁移创建任何数据（我的测试场景包含所有自己的数据，所以我没有这个问题）
我偶尔会清除已经在生产中应用的所有迁移，我至少看到两个原因：
- 更易于管理的文件夹。 如果添加了一些新的迁移，则更容易发现。
- 更清晰的文本搜索结果（项目中的全局文本搜索不会导致大量无用的匹配，因为旧的迁移，比如3年前有人创建了一些列）。
见http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you
迁移不是数据库的表示：structure.sql或schema.rb是。 迁移也不是设置/初始化数据的好地方。 db/seeds或rake任务对于这种任务更好。
那么什么是迁移？ 在我看来，它们是如何更改数据库模式的指令 – 向前或向后（通过回滚）。 除非出现问题，否则只能在以下情况下运行：
- 在我的本地开发机器上，作为一种测试迁移本身并编写模式/结构文件的方法。
- 在同事开发人员机器上，作为一种在不丢弃数据库的情况下更改架构的方法。
- 在生产计算机上作为一种在不删除数据库的情况下更改架构的方法。
一旦运行它们应该是无关紧要的。 当然会发生错误，因此您肯定希望在需要回滚的情况下保持几个月的迁移。
CI环境不需要运行迁移。 它会降低CI环境的速度并且容易出错（就像Rails指南所说的那样）。 由于您的测试环境只有临时数据，您应该使用rake db:setup ，它将从schema.rb / structure.sql加载并完全忽略您的迁移文件。
如果您正在使用源代码管理，那么保持旧迁移没有任何好处; 它们是源历史的一部分。 将它们放在存档文件夹中可能是有意义的，如果这是你的咖啡。
尽管如此，我强烈认为清除旧的迁移是有意义的，原因如下：
- 它们可能包含很旧的代码，它将不再运行（就像删除模型一样）。 这为想要运行
rake db:migrate其他开发人员创建了一个陷阱。 - 他们会放慢类似
grep的任务，并且在某个年龄段之后无关紧要。
为什么他们无关紧要？ 再次出于两个原因：历史记录存储在源代码管理中，实际的数据库结构存储在structure.sql / schema.rb中。 我的经验法则是，大约12个月以上的迁移完全无关紧要。 我删除它们。 如果有一些原因我想要回滚早于此的迁移，我确信数据库在那段时间内已经发生了足够的变化，需要编写新的迁移来执行该任务。
那么你如何摆脱迁移？ 这些是我遵循的步骤：
- 删除迁移文件
- 编写rake任务以删除数据库的schema_migrations表中的相应行。
- 运行
rake db:migrate以重新生成structure.sql / schema.rb。 - validationstructure.sql / schema.rb中唯一更改的内容是删除与您删除的每个迁移相对应的行。
- 部署，然后在生产时从步骤2运行rake任务。
- 确保其他开发人员在其计算机上运行步骤2中的rake任务。
第二项是保持模式/结构准确的必要条件，这也是唯一真正重要的事情。
是。 我想如果你已经从数据库中完全删除了任何模型和相关表，那么值得将它放在迁移中。 如果迁移中的模型引用不依赖于任何其他内容，则可以将其删除。 虽然迁移永远不会再运行，因为它已经运行，即使您没有从现有迁移中删除它，但每当您将数据库迁移时，都会导致问题。
因此，从迁移中删除该引用会更好。 在重大发布到实时数据库之前，重构/最小化迁移到一个或两个文件。
一旦你感到舒服就可以删除旧的迁移，这是不错的。 迁移的目的是拥有一个用于制作和回滚数据库更改的工具。 一旦做出改变并在生产中进行了几个月，你很可能不再需要它们。 我发现经过一段时间后，它们只会让你的回购，搜索和文件导航变得混乱。
有些人会从头开始运行迁移以重新加载他们的开发数据库，但这并不是他们的目的。 您可以使用rake db:schema:load来加载最新的模式，并使用rake db:seed来填充种子数据。 rake db:reset为你做了两rake db:reset 。 如果您有无法转储到schema.rb数据库扩展，那么您可以使用ActiveRecord的sql架构格式并运行rake db:structure:load 。
我同意，在100多次迁移中没有任何价值，历史是一团糟，没有简单的方法可以在一张桌子上跟踪历史记录，这会给你的文件发现增添一些混乱。 简单的Muda IMO 🙂
这是一个将所有迁移压缩到与生产相同的模式的三步指南：
第1步：来自生产的架构
# launch rails console in production stream = StringIO.new ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil stream.rewind puts stream.read
这可以复制粘贴到迁移，减去明显的标题
第2步：进行迁移而不在生产中运行
这个很重要。 使用上次迁移并更改其名称和内容。 ActiveRecord在其schema_migrations表中存储日期时间编号，以便它知道它运行的是什么。 重用最后一个，它会认为它已经运行了。
示例： rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb
并将架构放在那里。
第3步：validation并排除故障
在本地，rake db：drop，rake db：create，rake db：migrate
validation架构是否相同。 我们遇到的一个问题是架构中的datetime“now（）”，这是我能找到的最佳解决方案： https ： //stackoverflow.com/a/40840867/252799