什么时候应该更新依赖项？

Question

我们有两个不同的代码库(Android和Node.js web应用程序)与依赖相关的两大危机。Android回购系统需要从four迁移到Firebase，这需要更新Google服务库的四个主要版本。类似的事情发生在我们的Heroku托管的Node应用程序中，我们的生产堆栈(雪松)被废弃，需要升级到雪松-14。我们的PostgreSQL数据库也需要从9.2更新到9.6。

这些应用程序的依赖几乎都已经过时了近两年，当一些应用被废弃时，当我们进入“日落”阶段时，更新或替换它们一直是一个令人头疼的问题。在过去的一两个月里，我花了30多个小时慢慢地解决了所有的冲突和被破坏的代码。

显然，让事情持续两年太长了。技术进步很快，特别是当你使用像Heroku这样的平台提供商时。让我们假设我们有一个成熟的测试套件，以及一个像Travis这样的CI过程，这就排除了很多关于更新的猜测。例如，如果一个函数在升级后被删除，并且您正在使用它，那么您的测试就会失败。

依赖项应该多久更新一次，或者何时更新依赖项？我们更新是因为我们是被迫的，但似乎某种先发制人的方法会更好。我们是否应该在发布次要版本时进行更新？主要版本？如果每个月都有更新的话？我想要避免像我刚刚经历的那种情况，不惜一切代价。

PS -对于我的一个个人Rails项目，我使用一个名为绞股蓝的服务来跟踪您的依赖关系，这样您就可以被告知例如安全漏洞。这是一个很好的服务，但是我们必须手动检查我提到的项目的依赖关系。

Answer 1

在以下情况下，通常应该升级依赖项：

1. 这是必需的
2. 这样做有好处
3. 不这样做是不利的。

(这些并不是相互排斥的。)

动机1(“当你必须”)是最紧急的司机。您所依赖的某些组件或平台(例如Heroku)需要它，您必须排队。所需的升级通常从其他选择中层出不穷；您决定升级到类似的PostgreSQL版本。现在您必须更新您的驱动程序，您的ORM版本，等等。

升级是因为您或您的团队认为这样做的优势是软的和更可选的。更多的是一种判断力的呼唤：“新的特征、能力、表现.值得付出努力和错位才能带来它吗？”在“奥尔登时报”中，人们对可选升级有强烈的偏见。它们既手工又难，没有好的方法在沙盒或虚拟环境中试用它们，或者如果它不起作用就回滚更新，也没有快速的自动化测试来确认更新并没有“扰乱苹果车”。现在的偏见是更快，更积极的更新周期。敏捷方法喜欢尝试；自动化安装程序、依赖关系管理器和repos使安装过程快速且几乎不可见；虚拟环境和无处不在的版本控制使分支、分叉和回滚变得容易；自动化测试让我们可以轻松地尝试更新，并进行大量的评估：“它工作了吗?它有什么问题吗？”偏见已经从“如果它没有坏了，就不要修复它”转变为连续积分，甚至连续交付的“更新早，经常更新”的模式。

动机3是最温和的。用户故事不关心“管道”，也从不提及“基础设施不超过当前版本的N个版本”。版本漂移的缺点(粗略地说，与落后曲线相关的技术债务)悄无声息地侵入，然后经常通过破坏来宣布自己。“对不起，这个API已经不受支持了！”即使在敏捷团队中，也很难激发渐进主义和“掌握”组件的新鲜度，因为这并不是完成给定的sprint或版本的关键。如果没有人提倡更新，他们可能会被忽视。那个轮子可能不会发出吱吱声，直到它准备好断裂，甚至直到它已经坏了。

从实际角度来看，您的团队需要更多地关注版本漂移问题。两年太长了。没有魔法。这只是一个“现在付我还是以后付我”的问题。要么逐步解决版本漂移问题，要么遭受痛苦，然后每隔几年克服更大的震动。我更喜欢渐进主义，因为一些平台震动是巨大的。您所依赖的关键API或平台不再工作，实际上会毁了您的一天、一周或一个月。我喜欢每年至少对成分新鲜度进行1-2次评估.您可以显式地安排评审，或者让它们由主要组件(如Python、PostgreSQL和node.js )的相对节拍(通常是每年更新)周期有机地触发。如果组件更新不会很强地触发您的团队，那么在自然项目平台上，或者每一个k版本都可以对主要版本进行新鲜度检查。不管是什么，都把注意力放在更有规律的节奏上来纠正版本漂移。

Answer 2

当需要更新库时，应该更新它们。这意味着，如果更新没有带来任何价值，则不应该。

在您的特定情况下，您将从一个旧的技术堆栈迁移到一个新的技术栈，为了做到这一点，您不得不更新您的依赖项。这正是更新依赖关系的正确时间。

如果您一直在跨时间更新您的依赖项，为了“现在不头痛”，您将不得不投入大量的工作时间(编码)来获得无返回值。当您要进行最后一次更新(您现在正在做的更新，但是更新了一个主要版本而不是4个版本)时，您可能仍然会在某个地方感到头疼(毕竟，主要版本意味着破坏更改)。所以我觉得你走的路是对的。

但是，如果您发现迁移太难，并且需要进行大量的重构，那么问题就在代码库中。Android项目在代码结构方面不具备整体架构是很常见的。良好的依赖注入框架(如匕首2 )和一些软件工程原则(如实心 )可以使更改代码实现变得更容易，同时保持相同的行为/需求。

此外，由于我们正在进行重构，请阅读一些有关单元测试的内容，因为这将在进行此类工作时提供很大帮助。

Answer 3

如果您正在使用包管理工具(例如npm、NuGet)，并且有一个全面的自动化测试套件，那么升级依赖项应该是一个低工作量的活动，只需升级包，运行您的测试套件，看看是否有任何问题。如果然后回滚并引发一个工作项来调查和修复该问题。

只要升级依赖项的成本较低，就非常值得更新：

• 如果升级存在问题，您希望尽早了解，以防需要进行上游更改。
• 将依赖关系升级保留到最后一分钟通常意味着您在关键时刻进行这些升级(例如，为了响应安全关键缺陷)。保持对依赖关系的控制意味着您可以控制何时进行这些工作，并且可以在不太忙的时候执行这些升级。
• 较新的版本可能会提高生产率，例如更好的文档、更容易使用的API、错误修复(尽管也有可能相反)。

如果升级依赖关系不是很容易(例如，因为您需要手动测试升级，或者因为存在已知的问题/中断更改)，那么您必须权衡一下其他任务的优缺点。旧的依赖关系是一种低息的技术债，因此应予以相应的处理.