DOP 287: Automating Dependency Updates with Renovate
45:17 Share

#287: 在软件开发领域，更新依赖项仍然是一项至关重要但经常被忽视的任务。许多开发人员害怕手动操作带来的繁琐工作，尤其考虑到潜在的兼容性问题以及破坏现有功能的风险。在本集中，我们与 Renovate 的创建者 Rhys Arkins 进行了交谈，讨论了该项目的起源以及依赖项更新自动化如何提高软件开发效率和安全性。Rhys 的联系方式：X（前身为 Twitter）：https://x.com/rarkins LinkedIn：https://www.linkedin.com/in/rhys-arkins-5a643a/ YouTube 频道：https://youtube.com/devopsparadox Apple Podcasts 上查看播客：https://www.devopsparadox.com/review-podcast/ Slack：https://www.devopsparadox.com/slack/ 联系我们：https://www.devopsparadox.com/contact/</context> <raw_text>0 人们从不知道自己面临什么风险，到公司能够相当准确地告诉他们风险有多大，他们面临着很多风险。最后，当有了自动化之后，他们才能够真正开始降低风险。这是 DevOps Paradox，第 287 集，使用 Renovate 自动化依赖项更新。欢迎收听 DevOps Paradox。这是一个关于各种随机话题的播客，在其中，Darren 和 Victor 假装自己知道自己在说什么。

大多数时候，我们通过在任何可能的地方都加上“DevOps”这个词，并将其与 Kubernetes、无服务器、CICD、团队生产力、快乐岛屿以及其他让我们听起来像知道自己在做什么的花哨表达混合在一起，来掩盖我们的无知。偶尔，我们会邀请一些确实懂行的人做客，但我们不会经常这样做，因为他们可能会让我们显得无能。

真相就在那里，我们不可能找到它。附注：这是 Darren 正在阅读这段文字，并为 Victor 让我这样做而感到尴尬。以下是您的主持人 Darren Pope 和 Victor Farsal。Victor，你多久会坐下来手动更新所有产品的依赖项？我的意思是，你使用 Go 语言工作。对我来说，这是处理依赖项最痛苦的方式。

作为一名来自 Java 的人，对吧？我们讨论的不仅仅是 Go 依赖项，在我的情况下，我们讨论的是图像，例如，对吧？有 Helm 图表，有自定义的，还有一堆 Kubernetes 东西，甚至不总是 Go，对吧？为了回答你的问题，我多久手动更新一次依赖项？100% 的时间。我 100% 的时间手动批准更新我依赖项的拉取请求。

所以你有一些机制来帮助你进行依赖项管理，或者可能很多。所以在今天的节目中，我们邀请到了 Rhys Arkansan。Rhys 在 Mend 公司负责 Renovate 项目。Rhys，你好吗？嘿，很好，谢谢 Darren。感谢你邀请我。Victor 的回答让你感到惊讶吗？

我的意思是，他正在使用机制。他应该使用机制还是应该完全手动操作？毕竟现在是 2024 年了。我的意思是，我显然对 Victor 的设置有所了解，所以我想问一个澄清的问题。Victor，你说你手动批准了拉取请求，但你的意思是说你已经自动化了拉取请求以完成一半的工作，还是说你正在自己创建拉取请求？不，不，不。拉取请求实际上是由 Renovate 创建的，但我手动批准了它们，对吧？

嗯哼。是的。这几乎就像，我的意思是，基本上，在我的情况下，答案是它是否自动化是肯定的，但我只是在胡闹。这是一个手动操作来批准它。自动化，但不是完全自动化，这是一个非常有效的用例。

实际上，我把它设置成直接进入主线，没有任何拉取请求或其他任何东西。我改用拉取请求的原因并不是因为我不信任我自己的自动化。当我提到自动化时，我指的不是依赖项，而是测试以及我要求合并的其他所有内容。但因为我想知道有什么新东西，这样我就能看到……

我应该改进我的代码。也许有一些新功能。我想知道即将发生的事情。我认为关键点在于有很多不同的方法。没有一种方法适合所有人。但我确实有一些建议。所以一个建议是让人们现实一点。如果你获得了自动化的拉取请求，更新你的依赖项，而你总是点击它们，

它们。如果实际上你不会深入研究源代码和发行说明，你最好诚实地面对自己，并说，实际上，我最好把它设置为自动合并。如果它是补丁更新或你发现自己使用的任何类型的更新，

总是只是点击，你最好自动批准这些。另一个手动批准不受欢迎的用例是他们有自己的内部包。因此，更新依赖项并不总是外部或第三方依赖项。有时它可能是内部的。你构建基础镜像，然后你就有这个链

Victor 提到了 Helm 图表之类的东西。所以是的，尤其是在 DevOps 世界中，你可能有一个 Docker 文件，其中包含你更新的依赖项，这些依赖项会构建，被推送到注册表，然后向下游进入 Kubernetes 清单，你知道，Helm 图表，自定义模板。所以可能有时一旦你完成了初始工作，比如更新基础镜像，

你可能希望它只是流过而不需要你批准它们。因此，在内部情况下，可以说这些情况是相当安全的。在第三方补丁的情况下，你可能会说，好吧，这是务实的。我想回到你设置它的方式。如果你没有查看升级说明或补丁，你应该只自动合并，即 YOLO，对吧？对我来说，这，我的意思是，是的，这就是我们所有人都在做的。

但我们应该这样做吗？这是一个好问题。所以其中一个挑战是，很大一部分更新，特别是补丁，包括大多数非主要更新，很大一部分

是完全兼容的，不会中断的。理论上，在我们讨论的大多数生态系统中，例如 Go，人们在非主要版本中进行重大更改（无论是意外的还是其他的）的情况相当罕见。我们从统计数据中看到了这一点。

但是人们担心黑天鹅事件，无论是什么，都会破坏一切的那个事件。也许它会破坏你的注册表单，你可能会在一个高流量的应用程序中损失几个小时的注册等等。Renovate 的一个额外功能（也是 Renovate 的免费功能）是我们所谓的合并置信度。所以我们所做的是大规模地观察可能性。

通过和失败以及版本的合并。所以 Victor 可能会批准一个拉取请求，该请求实际上说这已经有一周了。它有 17% 的采用率，并且通过了我们观察到的 Renovate 用户 98% 的管道。这与 YOLO 大不相同。这有点像使用众包数据来提供我所说的群体信心。当我们

找到一种收集这些数据并以这种方式公开它们的方法时，这是一个相当重要的里程碑，因为人们从可能有一种 YOLO 的感觉转变为像我说的那样，一种务实的信心。你提到管道成功率很有趣，对吧？我想对许多人来说，仍然根本没有任何对其源代码或应用程序的自动验证，对吧？所以这是

我解释你刚才所说内容的方式有点像，嘿，其他知道自己在做什么的人，他们验证了这件事。

所以也许你也可以这样做。这有点像那样。是的，每个人都在跳崖。当然，这不是我们的意图。但这里有一些细微之处。我们很幸运的一点是，我认为依赖项自动化用户 Renovate，我们仍然处于早期阶段。仍然有很多甚至没有听说过这个概念的人。

也许有一些人正在这里收听，并且在听完这个播客后可能会感兴趣。所以我们仍然处于早期阶段，而使这项工作有效的一些不错的特性是

采用依赖项自动化和将 Renovate 集成到其项目的团队通常是那些拥有良好管道、高质量测试并进行持续集成、持续交付的团队。所以我们有点依赖那些对自己的测试有信心的用户的支持，这不仅仅是为了自动化，而且是持续的。

对于他们的开发人员推送更改时。也许甚至开发人员手动更改依赖项。因此，我们很幸运拥有许多这种类型的早期采用者，即高速度、高质量的团队。我认为这就是使数据相当准确的原因。另一件事，它并不那么简单。例如，我们也有能力追踪回滚。

所以即使人们更新了，回滚也是一个最重要的标志，对吧？显然是负面标志。所以这不仅仅是一种单向的信心。我们也可以知道人们是否后悔了。这是另一个方面。但是回滚可能有许多原因，其中两个是：我更新了我的依赖项，将其投入生产，但它没有按预期工作。我正在回滚。

没错。这就是我谈论的原因。没错。但是回滚可能是，至少从统计学的角度来看，可能是：我更新了我的依赖项，我测试了它，它没有按预期工作，它没有进入生产环境并回滚。

但这两种情况都是非常强烈的负面信号，表明该更新的某些方面存在问题。然后你会看到，其他人都会从这些早期采用者和回滚者那里受益，对吧？因为这意味着我们不会对该更新有很高的信心。基本上，任何其他正在考虑该更新的人都会知道要谨慎一些，或者至少，嘿，不要因为我们这么说就跳下悬崖，你知道的。事实上，我们在悬崖顶上说要小心。

那么为什么有人会尽早更新依赖项呢？以此判断，这符合每个人的利益。嘿，等一个月，让其他人验证这件事，然后成为一个迟来的采用者。而且……

我的意思是，我知道一个月不算迟来的采用者。人们往往会等待数年。是的，没错。是的，我的意思是，我认为这就像经典的曲线，对吧？你有非常早期的采用者、早期多数、后期多数。是的，你是对的。我的意思是，在某种程度上，选择这样做的人正在为我们其他人开辟道路。就我个人而言，我选择，这几乎就像一个无线电延迟按钮。我选择延迟七天。所以我等待更新七天。

然后提升它们。然后他们经常，我们确实有自动合并设置很多。但是也有一些人很乐意让他们的项目始终保持最新状态，并且可能无意中为其他人提供了很大的帮助，这些人要么等待一周，要么等待一个月。Renovate 的起源故事是什么？

为什么这是一个需要解决的问题？所以第一个声明是，在依赖项自动化领域有一些先前的技术，显然处于非常早期的阶段，采用率相当低。我当时正在自己创业，我们在生产中遇到了一个问题。我们的 Sentry 监控报告了与我们的身份验证相关的错误，非常模糊，奇怪的错误。我们真的

绞尽脑汁近一周的时间试图找出发生了什么。然后最终，一个为我工作的开发人员找到了它。他说，哦，一周前，他说，他升级了 Firebase SDK，因为他们有一个我们需要的新的功能。事实证明，他们在那个版本中意外地破坏了一些东西。可悲的是，他们几乎立即修复了它。我们只是运气不好。我们在它基本上是一个损坏的最新版本时升级了，并且

而且因为我们没有更新流程，你知道，我们只是临时更新。就像我说的，我们需要那个特定功能。在这种情况下，我们被抓住了，我们花费了，你知道，如果你考虑时间、金钱和用户影响，那真的很糟糕。在那时，我基本上说，好吧，永不再犯。

幸运的是，不幸的是，对于其他人来说，我当时知道的两种工具都不支持单体仓库，也不支持日志文件。所以我基本上编写了一个脚本来为 NPM 自动化它，只为 GitHub.com。

我开源它部分是为了搜索引擎策略。我过去常常用房地产术语（如公寓和翻新）来命名我的开源项目。我会将它们分享到技术博客和新闻通讯中，以获取指向我的技术博客的反向链接。当 Google 看到反向链接上写着公寓，

公寓和翻新而不是依赖项更新器和软件时，它会有点欺骗它，让它稍微提升你的主要内容。所以我做了那样的事情，不像之前的那个，它被称为公寓翻新实际上让一些人非常感兴趣，人们出现在仓库中，你知道，发现错误，要求添加功能。我感到有点兴奋和内疚。

然后我结合起来想，好吧，我不能对这件事不真诚。所以修复了错误，你知道，有人想要添加 GitLab，并做了一些工作来研究它并添加了 GitLab。基本上，它就是这样发展起来的。我最终实际上将我的创业公司从房地产技术转向了 Renovate。这就是它的由来。

创业公司的成功通常就是这样发生的。它不是第一个项目或产品。它是第二个或第三个。是的，挠痒痒。例如，Slack，当他们构建其他东西时，Slack 不就是一个内部沟通工具吗？然后他们被一个名叫 Salesforce 的巨头吸收了。是的，这不是我们今天来这里的原因。但是，那将是很好的。

听起来 Renovate 的过程是你挠了自己的痒。你为自己解决了问题。人们开始喜欢它。是的。然后突然之间，

Renovate 被收购了，“被收购”了吗？有点，是的。所以我只是，我发现让开发人员使用它非常令人兴奋。我实际上一直在构建房地产技术。你知道，你会做一些事情，比如查看热图，进行用户会话审查，你知道，经典的创意产品经理，你看着人们点击错误的地方，然后说，不，不，你为什么要这样做？你知道，你调整事情，并且

使事情更容易点击，诸如此类的事情。然后突然之间它就像一个偷窥狂，对吧？你知道，你真的不知道这些人是谁。然后突然之间这些人像在你面前说，嗨，我正在使用它。这真的很好。如果你这样做，那就更好了，诸如此类的事情。我真的很喜欢这种刺激。这就是让我开始的原因。转折点是有人在某个时候出现并说，

我认为实际上是有人需要单体仓库或锁定文件等等。对。他说，这绝对完美，但我不想运行我自己的软件。我很小。我喜欢运行，拥有服务。他说，我想付钱给你。

如果你把它作为一个服务运行，即使它是免费的，它是开源的。那实际上是一个真正的转折点。我开始考虑这个问题，我意识到，是的，我的意思是，很多人不想运行他们自己的管道等等。而且，你知道，将 Renovate 作为一个服务运行将是一个可行的业务，希望如此。所以我并没有真正转向，而是将其转换为一个开源优先，但托管服务第二的服务。

在一年半后，这个话题突然变得非常流行。当我在 GitHub 活动的观众席上时，我感到非常超现实，他们在活动上宣布收购 Dependabot，之前对此有一些

想法，但看到 GitHub 的首席执行官等等谈论依赖项自动化有多重要，是的，我意识到这将是一个很大的领域，那时我不想承担很大的风险，承担资金风险，别人的钱或任何类似的事情，我已经和 Mend 团队合作了一段时间，他们对这个软件很感兴趣，所以我们想出了，你知道，Mend 有那个

有我感兴趣的规模和共同的利益，对我来说，加入他们比独自在一个竞争激烈的领域中尝试更好。我一直对开源项目发展壮大感到好奇。如果它们成功了，它们就会发展壮大，对吧？并且需要更多的时间和精力。如果完全基于……

贡献，Renovate 存在的可能性有多大？这是一个好问题，因为我将它变成软件即服务的个人财务动机实际上出现得相当晚。在此之前，它就已经在使用中积累起来了。所以，你知道，在有任何之前，它确实作为一个相当流行的开源工具存在，你知道，激励在那里。我认为这是绝对可能的。这很有挑战性。你知道，有很多正确的时间和地点。事实上，你知道，

你知道，当我考虑是否要将其变成或尝试将其变成一个业务时，

我的怀疑有一半是，但是如果这是一个如此好的主意，为什么还没有人这样做呢？就像，你知道，我必须真正经历所有这些，为什么，为什么每个人都错过了这个？这似乎是显而易见的，这应该就像持续集成一样，说，你知道，那种自动化，这应该只是软件的一部分。为什么没有人这样做呢？很难判断，但我确实这么认为。我认为像 Renovate 这样的项目可以存在，但是如果我们没有能力让人们有薪水来参与其中，我们就不会那么成功。

那么 Dependabot 几乎就像是对这件事的验证吗？是的，是的。这是一种奇怪的感觉，因为当我开始 Renovate 时，我不知道 Dependabot。我的意思是，我实际上只是挠了挠痒。所以首先，是的，我几乎写了一个脚本。当我决定将其商业化时，我也不知道 Dependabot。

当我发现他们时，实际上是他们的创始人联系我说嗨，我有点想，如果我知道还有其他人像我一样有能力和才华，并且有相同的愿景，我认为我不会走这条路。你知道，我并没有打算竞争。我开始构建一些需要的东西。然后我继续这样做，因为它似乎有一个开放的空间。所以这是对……

我并没有疯，或者走错了路，如果其他人认为它很棒的话。然后 GitHub 收购 Dependabot 显然是对这作为一个重要软件概念的充分验证。我要回到你创建它的原因。我假设你尝试过竞争对手。

不，不。在我创建的时候，顺便说一句，我认为 Dependabot 那时可能甚至不支持 JavaScript。他们是从 Ruby 领域开始的。我使用过两种现有服务中的一种。它们以前都是服务，而不是开源的，但是当我

而且，你知道，我意识到单体仓库，好吧，我采用了单体仓库，但是当我使用锁定文件时，你知道，一个更新的服务，如果它更新你的 package.json 而没有你的锁定文件，它实际上就像坏了。所以我不能使用它们。所以最后，这就像我没有选择一样。我理解锁定文件没有更新。没关系。让我们在这里开始一场圣战吧。你为什么想要一个单体仓库？

是的，所以我正在构建一个具有数据库、后端、前端的服务，非常简单，三个组件。我发现即使是小规模的，我自己和几个为我工作的承包商，更新后端并将其发布或构建到镜像中，然后更新前端，例如，这只是有点痛苦。很有趣的是，我会说像 Renovate 这样的依赖项自动化现在可能是人们可以使用的一种工具，而不需要

你知道，单体仓库，你知道，因为当你在一个区域发布一件东西时，你几乎可以立即在其他地方更新它并对其进行测试等等。所以这种自动化也可能使非单体仓库更可行。我正要说到，这有点像，你为什么需要单体仓库，伙计？如果你有

依赖项解决方案。这难道不是你一开始就那样做的主要原因之一吗？有点，是的。这有点像，这样我所有的依赖项在某种程度上都不是依赖项。它们都在一个地方。我想我实际上从那以后就没有使用过单体仓库了。好的，很好。我们将远离单体仓库。我不想进入 Google 级别的单体仓库，但是很多人直接使用单体仓库是因为 Google 使用它，这是一个不好的理由。这并不是一个无效的理由，但这是一个不好的理由。

是的，我想你不想走这条路，如果你说的是 Google 做的事情，但你可能没有足够大到需要它，那么你开始谈论像 Kubernetes 本身这样的事情。是的，构建你自己的 Borg。是的，我们之前讨论过这个。大多数时候人们不需要 Kubernetes。是的，我一遍又一遍地说。不，我会纠正你。大多数时候，人们不需要管理他们自己的 Kubernetes 集群。好的，足够了。是的。

你知道，你可以使用 Azure Container Apps，它非常漂亮和简单。并且后面有 Kubernetes，你甚至看不到它。我认为我们今天都可以同意，然后我们将从这一点继续，容器镜像很好。容器镜像如何变成容器，不要自己做。除非你没有选择。世界上可能只有 10 个人没有选择。我们正在谈论 Renovate。你因为你遇到的痛苦而构建了它。

你们有多少人，你的意思是依赖项管理工具，有 Dependabot，因为你提到了他们的名字，Renovate。在这个领域中还有其他人吗？是的，我之前提到了竞争，所以我很高兴你又提到了它。我不想——好吧，这很难回答，因为我不想轻视它。这个领域还有其他工具，但是没有一个看起来有——

你说，背后的动力。我不会说这是故意的，但我认为 Renovate 和 Dependabot 的结合已经从房间里吸走了一些氧气，因为你看着它，你会想，好吧，你知道，GitHub 基本上免费地以大规模的方式提供依赖项自动化

另一方面，Renovate 是开源的。通过开源项目的正常指标来看，这是一个非常开放的项目。它具有良好的速度，并且具有非常广泛的支持。人们一直在向其中添加新的包管理器和注册表类型。我认为如果有人要开始，例如，如果有人要开始一个新的

我不应该在这里自找麻烦，但是他们应该开始一个新的开源依赖项自动化工具。每个人都会说，但是你为什么要这样做？我的意思是，Renovate 在那里。就像我说的，它是开源的。它非常模块化。你可以向其中添加任何你需要的东西。所以我认为这两种情况的结合，你有一个非常大的商业提供商将其作为免费服务提供，然后你有一个相当健康的开源项目，顺便说一句，两者

两者都是免费的，对吧？我的意思是，无论是开源的，还是我在 Mend 帮助运行的托管服务，还是 GitHub 最终谈论的免费服务。所以你会想，我要来努力与几个健康的免费项目竞争。

我认为结果是，当我这样说时，氧气被吸出了房间，这并不是说人们会说，哦，这是我真正想做的事情。在他们选择看起来相当健康并且并不像摇钱树的东西之前，他们会寻找软件中收费过高或性能不足的领域。我看到一些项目同时使用 Dependabot 和 Renovate。这就是你刚才暗示的内容。他们为什么需要两者？

比较和对比，或者这个维恩图是什么，才能得到整体？所以同时使用两者并不常见，因为我认为开发人员最终想要，我不会说单一事实来源，而是单一拉取请求来源，并且他们只配置一次。

你可能会看到这种情况发生在一个企业的客户，特别是 GitHub 的客户，他们可能会说他们为安全修复启用了 Dependabot。你知道，这是他们的公司政策。但与此同时，该公司内部的团队出于各种原因，你知道，想要使用 Renovate 及其某些 Dependabot 可能没有的功能。所以这就是人们可能会说，好吧，我的意思是，我们……

让公司满意，是的，我们勾选了一个框，我们有 Dependabot，但我们自己也使用 Renovate，也许是为了非安全更新。现在，当然，

有时是相同的更新，对吧？我的意思是，他们最终可能会更新……比方说，如果明天 Lodash 发布了一个安全修复程序，因为有人最终发现了一个新的 CVE，他们可能会收到来自 Renovate 和 Dependabot 的拉取请求，并且必须决定选择哪个，然后另一个将被关闭。你提到了安全性，在我看来，这是我保持依赖项更新的主要原因之一，对吧？因为大多数时候，更新并没有真正给我带来任何新功能，对吧？或者更好的……

通常情况下，是安全性，对吧？尤其是补丁。与安全工具之间是否存在某种关系或协作，以便，嘿，无论如何都检测到高水平的漏洞。现在让我们确认此更新或使其以某种方式发生。

是的，当然。当然。我的意思是，一个简单的描述方法是，你的安全更新，比如漏洞修复或CVE修复，如果你愿意的话，基本上这是你能做的最重要的高优先级依赖项更新。所以这是更新的类别，但它是高优先级的。对某些人来说，这是他们做的唯一一种更新。对某些人来说，他们认为尽管有自动化，依赖项更新仍然很痛苦。他们认为这没有足够的价值。

所以他们往往会有点不负责任。你知道，他们让他们的依赖项过时，然后等待警报响起，对吧？他们等待那个警报说：“嘿，嘿，大问题，大问题。你需要立即更新到至少这个版本。”理想情况下，他们希望有一个自动拉取请求，无论是来自Renovate还是商业提供商。不同之处在于，就像维克多，在你试图保持更新的场景中

当你收到安全更新时，它可能就像一个补丁，或者最多两个功能版本，或者类似的东西。如果你一直保持更新，你就能查看发布说明。而且，如果该软件包的创建者遵循最佳实践的话。

这个安全修复程序不会捆绑一堆其他高风险的稳定性问题。他们不会说：“哦，我们重写了我们的整个后端，也修复了这个严重的漏洞”，因为他们可能会破坏东西，对吧？所以希望你看一下，他们会说一行SQL注入修复之类的东西。也许你甚至会点击源代码。是的。我看到了差异。

你就可以更新它。所以你将在你喝完早上的第一杯咖啡之前更新并修复了那个安全问题。想象一下另一个不更新依赖项的团队。他们会收到更新，它会是这样的：“好吧，你和修复之间有27个功能版本。”他们处于非常艰难的境地，因为他们必须在基本上不进行验证的情况下匆忙更新，你知道，没有进行他们真正应该进行的足够测试之间做出选择。

27个功能版本。所以他们可以为了安全而匆忙更新，或者他们可以延迟更新并说：“我们不可能今天测试所有这些。我们必须保持漏洞状态直到至少明天。”所以，你知道，正如你所说，这是一个进退两难的局面，对吧？所以，如果你使用的是过时的依赖项，你通常做的工作最少，但你确实引入了高风险

这种情况，你必须快速进行高压更新。这就是主动更新和被动修复在安全方面之间的区别。我想在使用Renovate或Dependabot或类似工具的用户和他们发布内容的频率之间也一定存在某种关系。DoraMetrics高绩效团队……

你每天发布一次或每周几次，你更有可能使用它。你每年发布一次，而那些公司仍然存在，有点像，“我们17年来没有更新任何东西。”是的，在高绩效团队和依赖项更新之间存在高度相关性。在另一端，你有一些团队，他们会在需要时添加一个开源依赖项，你知道，“添加这个新功能，我必须为此获取一个库。”然后他们可能会永远保留它。是的。

他们可能也在不知不觉中使用过时的API。他们不知道那个API在那里。他们不断地增加越来越多的技术债务。

所以是的，存在非常高的相关性。我还想说，这种类型的用户帮助很大，因为对我构建Renovate来说，很多人提出了很棒的想法，因为那里的相关性，那里真的有聪明的人，他们有时会进入一个对他们来说完全未知的代码库，并贡献一个非常棒的想法，甚至是重构。我认为

当你拥有吸引早期采用者类型的东西时，你真的可以以你意想不到的方式获益。你还记得那些令人惊叹的想法吗？

哇，你让我措手不及。我的意思是，一个让我想到的，我不会称之为一个令人惊叹的想法，但它当时让我震惊了。我实际上是在度假，从我自己的创业公司休假，但我正在度假，一个家伙出现在Renovate的GitHub仓库中，他说，哦，嘿，我在想，因为我实际上一直在编写测试，他说，嘿，我

我认为如果你采用Jest测试框架会更好。如果你不反对，我很乐意为你设置它并将你所有的测试转换过来。这真的让我大吃一惊，因为这是我第一次真正参与这种类型的开源工作。我想，

当然，那太好了。果然，在接下来的一个星期内，他已经重构了它并采用了Jest的最佳实践。如今，虽然Jest不一定是每个人的最爱或最流行的，但Renovate项目拥有100%的单元测试覆盖率。我们对每个修复、每个功能都强制执行此项。这也是我们能够快速行动的原因之一。而它的起源是一个高绩效的开发者，他进入了代码库并

做了一个非常好的改变。让我们继续这个故事。你有人从外部进来。我假设这是在Mend所谓的收购Renovate之前。是的，甚至在任何商业化之前。所以现在它已经商业化了，如果这个男人或女人现在正在听我们说话，他们会想，“哎呀，我应该从那件事中得到一些报酬。”因为现在它已经商业化了。我的意思是，你对商业开源有什么看法？

你提到这一点很有趣，因为还有一个故事片段我不确定是否要补充进去。当我决定将Renovate作为一个服务以及开源来运行时，我走上了这条道路。我从MIT许可证切换到带有贡献者许可协议的AGPL。

这真的是唯一的方法。它不是一种完全可防御的模式，但它使其具有可防御性。这很有趣，因为我需要做的是追踪所有在此之前做出贡献的人，并基本上请求他们的许可，让他们追溯性地签署使用该代码。

所以他是必须联系的人之一，我说：“嘿，听着，我……”我非常坦诚。我说：“听着，我计划将它从MIT许可证更改为AGPL许可证。这样，如果其他人确实说要将其商业化，至少他们必须……很有可能必须回馈。他们不能只是拿走我们在公开场合所做的一切，

不回馈任何东西。同时，贡献者许可协议将允许我潜在地对其进行自己的修改，你知道，将其作为一项服务运行，而无需将其赠送给其他人，让他们以低于我的价格运行。我很高兴地说，我得到了普遍的支持。人们说：“做得好。我喜欢Renovate。感谢你构建它。我真的很希望你成功。”毫不夸张地说，这是普遍的反馈。所以这是一个快乐、快乐的时刻，而不是“你是什么意思，你免费拿走我的作品，

并从中赚钱？”是的。然后也许再扩展一下。我的意思是，有很多不同程度的商业开源。我认为在存在商业元素时取得成功的秘诀之一是，对于任何有疑问的人来说，你开源的东西都必须非常明显地像真诚的开源一样。我使用了一个术语，真诚与不真诚。

对我来说，不真诚的开源就像，比如说，开放核心，人们开源一部分，他们甚至可能称之为核心。但如果现实情况是他们没有兴趣，他们甚至可能实际上设置障碍，阻止人们实际自己运行它作为商业的替代方案，你知道，他们有点像它在那里，但祝你好运运行它。

这可能是你必须去完全编译并为Windows或Mac等构建它的软件。这并不是真正……这并不属于我对真诚开源的定义，因为如果你不真诚地希望人们完全免费运行它，

甚至不知道是谁，无需许可。我们一直，感谢我的员工，一直真诚地运行它。事实上，我想说，可能99%自己运行Renovate的人都是使用开源版本运行的。我可能不知道他们中的80%或90%，因为正如我所说，真诚的开源，他们无需许可就可以运行它。

你知道，无需……怎么说，无需请求许可即可运行它。它是开源的。你下载它，你运行它。

我不知道现在的数字是多少，但是Renovate开源Docker镜像在Docker Hub上，感谢Docker托管它，在2021年或2022年，也许是2022年，超过了10亿次拉取，类似这样的数字。你知道，这是一个巨大的使用量。这就是为什么我可以直言不讳地说，当你有数十亿，超过10亿人拉取它时，那就是真诚的开源。你认为这是一件好事，而不是试图改变你的模式之类的事情。

查看Renovate GitHub存储库，你看到了标准的，“嘿，这里有星标，向上绘制到右边”，我想。它看起来是一个相当线性的增长。不，它不是曲棍球棒，因为我认为它不是对数图表。所以你说你有数十亿。你确实说了数十亿。Docker拉取次数。是的。我的问题是，好吧，我们在2020年有了一件让世界旋转的事情。你……

看到超过还是……我的意思是，如果我只看使用情况，听起来可能有一个很大的峰值，我们在2024年的情况如何？是的，我认为我看到的和你一样，呃，那里的星标历史和图表，它的增长速度快于线性，它不是……正如你所说，它不是曲棍球棒，它不是完全指数级的，我不知道……我不知道正确的术语

自从我做数学运算以来已经很久了。但是，如果你在每个时期都画直线，我认为你会看到，总的来说，新星的数量正在加速。我对星标有一个声明。我以前从未说过。我现在就说出来。星标就像在沃尔玛买饮料。50美分，你可以喝一杯。

是的，我读到了。我也读到了。据我所知，没有人为了快乐而购买星标。如果我们查看该图表，我们没有看到任何迹象。甚至没有任何微小的波动。这就是我的意思。你的看起来……因为它看起来更自然，所以感觉更合法，我想。是的。

顺便说一句，虽然实际上如果你真的在Zoom上，因为我现在仍然……现在你唤起了我的回忆，你知道，那时几乎每一个清醒的时刻都被用来思考它、计划它或编写代码。当有人在推特上提到你或类似的事情时，你知道，我先检查GitHub通知。我实际上仍然这样做。这真的是我首先检查的事情，当人们在推特上谈论它时。偶尔，如果我可以称之为影响力的话，有观众的人会在推特上谈论Renovate

或者更好的是，如果他们为某个你认识的人工作，他们会说……你知道，我会编造一个，因为它并不完全属实。就像他们说，哦，它……

在Uber或类似的地方，对吧？那时你可以看到峰值。你可以看到峰值。鉴于我的历史，我实际上开始使用它来尝试获得搜索引擎提升，我也会成功地，大多数时候，我会发布峰值的照片，当有人提到它时。比方说，世界各地的维克多会提到它，我会突出显示它，我会加上一个箭头，我会称之为昨天的维克多峰值。这真的很好，因为大多数时候人们觉得这很有魅力，然后会转发它，

这意味着如果他们的观众前一天错过了它，你知道，他们会在第二天或两天后看到它，当他们转发我的推荐时。或者也许他们第一天看到了它，并认为，“呃，随便吧。”但他们看到了两次，他们会想，“哦，维克多似乎喜欢这个。”所以这实际上是我早期使用的另一个小策略。但是，是的，当你现在查看星标图表时，很难看到太多。是的，我的意思是，你知道，这是一个迹象，

当我没有几千次额外的观看次数时，它不会以任何方式显示在任何图表上，对吧？

是的。天哪，这很有趣，因为我的CEO有一次我们正在谈论……我忘了哪个……我不认为是星标增长，因为那不是说，伙计们，我认为我们正在谈论安装或类似的东西。我忘了，他有一个……他当时说，我记得当时我对它的假设在某种程度上是错误的。他正在谈论……你知道，病毒式增长。他说，“好吧，这表明……你知道，这是口碑传播，而不是营销或类似的东西。”所以就像，我们正在查看它，并说，“这似乎表明这种增长方式不同。

它是现有安装的一个因素。没错。我认为你是在说它是现有安装的一个因素。它大于线性。这意味着人们似乎是从现有用户那里了解到的，因为它一直在向上增长。就像他说，“我们没有在营销上投入更多资金。我们没有营销它或其他什么。我们正在投入更多资金用于营销。我们没有……所以如果你看到它每月增长速度是两年前的三倍，这反映了……你知道，安装基数也在增长，这意味着它更像是自然推荐而不是营销。

谁不需要使用Renovate？我会说那些不知道如何编写自动化测试的人。这是一种可能性。我的意思是，我对这一点非常有偏见。我的目标不是每个人都应该使用它并遵循最佳实践等等。我的目标是，Renovate可以根据人们的需求进行少量或大量的调整。我认为没有多少人从不更新依赖项。

即使你有点会说你手动完成它，我仍然希望他们查看Renovate仪表板，然后他们会说，“是的，这就是我想要的。”他们选中该框，然后他们会得到一个自动拉取请求。锁定文件已更新。发布说明在那里。就像即使本质上他们是手动更新一样，默认情况下没有任何东西是自动的，我仍然希望他们从发布说明检索、置信度分数等方面找到价值。实际上，不久前，也许是两个月前，我进行了一次对话。

与一个团队说，“我们不能这样做，因为它太危险了。我们不知道会发生什么，等等。我们无法升级。”然后我问他们，“好吧，那么，但是当你们开始这个项目时，你们是如何选择要使用哪个版本的依赖项的呢？”然后他们开始挠头，有点像当时的最新版本。对我来说，这在某种程度上是愚蠢的，对吧？你没有任何标准，没有任何标准，你将从什么开始。

但是突然之间你开始害怕。你从未知开始，对你来说是未知的，但随后你开始害怕未知不应该继续。是的。感谢你提出这一点。我喜欢这个。因为我也会说，因为我们就像……有些人说，“哦，但是升级到最新版本，太危险了。”我说，“是的，但是……”

你从……我说，“开发人员并不害怕最新版本。他们并不讨厌它。你开始……我不认识一个……好吧，我举一个例子。没有人开始一个新项目，然后坐在那里挑选，“现在我要取第三个版本或类似的东西。”不，因为你没有理由知道为什么那个更好。也许最新的版本修复了第三个最新版本中的某些东西。我唯一一次看到人们……所以，你知道……

因为听众会说，“我知道一个原因。”好吧，有时你可能会说将依赖项从现有项目复制到新项目。这就像一个相当罕见的情况，你就像，“好吧，我们有这个集合，我将从它们开始。”但是是的，当人们添加依赖项时，就像，“好吧，我需要一个库来帮助我与Redis通信或类似的东西。”我要添加Redis缓存。我需要找到Redis的Node.js库。

他们会找到……你知道，可能是最流行的库，他们会安装最新版本。他们甚至不会考虑版本。坦率地说，他们会说“npm install node-redis”，它将只是最新的。他们知道这一点。

一旦完成，他们突然谨慎起来，认为最新版本很危险。特别是，你刚才说了Node.js，对吧？特别是Node.js，除非它改变了，我已经有一段时间没有使用它了。当你为Redis选择该库时，你可能选择了该库使用的另外575个库，这些库你完全……你不知道。你只知道互联网的一半突然出现在该应用程序中。

是的。你知道你刚才让我想起了什么吗？你知道，有一个关于……通常是……我不知道，我不认为我在这里冒犯了任何人，但是，你知道，有一个关于……你知道，有人说……

就像我控制进入我身体的东西一样。然后我们笑着说，“不，没有正常人知道整个食物链以及鸡肉或你正在吃的东西中有什么。坦率地说，甚至连莴苣上喷了什么。”我的意思是，人们知道他们身体里有什么东西的想法。有点类似。就像人们说，“不，不，不，不。我手动选择我的依赖项。”就像，“是的，那另外一千个呢？”

它附带的你没有手动选择它们，很好，你一句话就冒犯了食肉动物和素食主义者，我喜欢它，今天机会均等的冒犯者，是的，哦，伙计，有了这场争议，观看次数将突破屋顶，Mend再次……你说Renovate被收购了，实际上你被收购到了Mend，那是因为Renovate

在那时，它仍然是MIT吗？还是因为这个你使用了AGPL？不，我已经将其切换到AGPL。我不会讨论AGPL是否是真正的开源，但它是。所以让我们假设它是。Mint做什么？升级步骤是什么？所以我可以自己使用Renovate，自己托管它，但我不需要这样做，因为你有一个服务。现在，实际上，Mend……

是你以前拥有的服务，对吗？有点像，尽管Mend做的不仅仅是Renovate。所以Mend处于安全领域。这就是为什么我有时称自己为意外的安全专业人员。本质上，GitHub和Mend都出于安全原因购买了依赖项自动化工具。这是行业的一个阶段，公司擅长告诉你存在漏洞，但随后仍然需要开发人员去修复它。

它。因此，这些工具被引入作为一种自动化我们所说的补救措施，自动修复的方法。这对公司的风险水平产生了巨大影响。所以他们……你知道，这就像这种迁移。呼吁从不知道他们有什么风险转变为公司能够相当准确地告诉他们，“你有很多风险”。然后最后，当你有了自动化，你就可以开始降低风险了。

所以MEN做的不仅仅是更新，显然，Renovate驱动更新，还有扫描、识别漏洞、可利用性预测分数等等。自从我加入以来，我们已经扩展了。我们也做第一方代码安全。你知道，经典的SQL注入，诸如此类的警告和容器扫描，各种类似的东西。所以现在的Renovate本质上是更大套件的一个组件。

如果人们只想尝试Renovate部分，他们可以。绝对可以。是的。所以我们目前的策略是我们已经拥有或正在构建到所有主机平台的应用程序，GitHub.com，你知道，PitBucket Cloud，Azure DevOps，Mend免费计划基本上是Renovate。

你知道，因为以前我们曾经将Renovate作为一个独立的应用程序运行。例如，我们仍然在GitHub上这样运行它，但现在我们正在使其成为Mend免费计划。所以对于那些对Renovate感兴趣的人来说，你仍然拥有这个……正如我所说，它是完全开源的。就像我说的一样，你可以用一行命令运行它。这是一个Docker运行命令或一个MPX命令。它是非常真诚的开源。但是，如果你有兴趣将其作为一项服务运行，你甚至可以免费获得它。是的。

所以Reese的所有联系信息都将在剧集说明中。Reese，感谢你今天与我们在一起。非常感谢。这是一种真正的快乐。我们希望本剧集对您有所帮助。如果您想讨论它或提出问题，请联系我们。我们的联系信息和Slack工作区的链接位于DevOpsParadox.com/contact。如果您通过Apple Podcasts订阅，请务必在那里留下您的评论。这有助于其他人发现这个播客。

现在就注册DevOpsParadox.com，以便在我们发布最新剧集时收到电子邮件。感谢收听DevOps Paradox。