您多长时间更新一次未发布项目的gem？

Question

我有几个副业，要么仍在开发中，要么为朋友和家人而活。异常(modulecounts.com)非常微不足道。

在工作中，在一个更大的组织中，我们似乎总是制定规则，禁止过于频繁地更新gem。它变成了一个为特定冲刺而安排的故事。它必须与运维协调，以确保他们准备好更新生产环境等。

当我是唯一的开发人员时，所有的协调开销都消失了，但更新gem仍然存在风险。也许这些新版本不能很好地工作。

所以..。一直这样做是不是更好呢？使用"gem update“启动每个开发会话，然后从那里开始？或者我应该等到我即将上线并进行一次大的更新，希望在后端损失的任何时间都能通过在整个开发过程中不再以小的增量损失时间来弥补？

你的工作是什么?什么是令人满意的折中方案？

Answer 1

更频繁地更新get的好处是您可以获得改进。例如，安全性改进或速度改进。此外，这意味着您的代码更新，通常更容易找到较新的gem版本的文档。此外，让gem保持最新意味着您使用的是较新版本的API，例如Facebook或Twitter。使用较新的API可能意味着速度的提高和领先于弃用。当然，正如您所指出的，这也有缺点，重要的是要记住这一点。下面是我喜欢遵循的几点建议：

1. 了解您正在使用的较新的gem版本。请阅读发行说明。如果您使用的是文档齐全的gem，那么您应该能够找到这个gem版本中的新特性，以及您是否需要在gem文件中处理deprecations.
2. Use gem版本。我最喜欢的操作符是~>。gem 2.1意味着>= 2.1但小于2.2，这意味着你可以确保你的gem保持最新，而不必担心被弃用，因为你可以保留在特定的gem版本中。这通常意味着您将继续接收特定gem版本的安全更新，同时保留相同的命令和函数格式。
3. 不会在关键项目上立即升级。在升级之前，最好等一下新的gem版本发布。在您的开发分支中测试新的gem版本，或者等待其他人是否发现错误。了解新gem版本的progress.
4. Write测试的最新信息。不要直接测试gem，但要确保依赖gem的代码能像您期望的那样工作。你在这里得到的覆盖范围越大，特别是对于关键功能，在你升级一个gem之后，就越容易判断一个新的gem版本是否仍然operational.
5. Test你的应用程序。创建一个新的git分支并更新该分支中的gem以确保您的代码仍然可操作，这通常很好。在测试分支或升级代码时，您甚至可以让分支在多个开发周期或冲刺中保持活动状态，只有在确信gem升级是个不错的选择时才将其合并回主分支。

我的首选是尽可能保持最新的gem，同时确保我的发展不会因为不断升级而受到很大的阻碍。我尝试按照对我的团队有效的时间表进行升级，例如每两周升级一次，同时密切关注安全升级。它还有助于以自动方式设置您的生产环境。Bundler在这方面非常有用，因为您的Gemfile.lock可以确保您的生产环境与您的开发环境运行相同的gem。

Answer 2

我不认为每次开始工作都要更新有说服力的论据，除非你喜欢用更新的gem修复不兼容的问题。

当我在开发一些东西的时候，我通常每一两周更新一次。我不想发布过时的第三方代码。然而，一旦它投入生产，审查gem更新所需的工作量使我不太可能想要更新。有时你的测试不能捕捉到一些改变的东西，然后你也不能。

因此，如果它是你的项目，并且更新相对安全，那么作为一个愉快的媒介，经常这样做，但不要强迫自己每天都这样做。如果它是一个生产应用程序，你有更高的机会破坏某些东西，或者你在团队中工作，除非你真的需要，否则在更新时要更加谨慎。

哦，我认为Rails等人在任何时候更新都是相当安全的，只要你阅读了发行说明并进行了任何必要的更改。