机器人控制学习机器编程代码_带上机器人，让他们维护我们的代码！

机器人控制学习机器编程代码

了解如何使用Renovate，Travis CI和CodeCov自动执行尽可能少的维护

去年，我撰写了由五部分组成的系列文章，这些文章使用Parcel构建了React样板 。 它展示了如何使用流服务器端渲染 ，如何自动执行代码质量 ，实现100％的代码覆盖率 ，探索如何使用Docker进行开发以及如何覆盖多阶段Dockerfile进行生产 。

不幸的是，随着时间的流逝，样板已经开始陈旧。 我选择的某些库已更改了它们的API，结果，遵循本文教程的人们在跟随并键入npm i时获取更高版本时遇到了一些错误。

现在是更新此样板的时候了，但是以我典型的方式，我决定通过展示如何让机器人为我完成繁重的工作，将其转变为学习体验。

在本文中，我们将使用一个名为“ Renovate ”的特别有用的机器人，该机器人将跟踪项目的依赖关系，并在每次需要更新时发出“拉取请求”。 Renovate最近被WhiteSource收购，以前被称为RenovateBot。 因为在方法的每个步骤中都有大量的自动化测试和代码质量执行，所以我们应该能够快速查看是否一切仍在进行中，或者特定的更新是否导致中断。

最后，我们还将探讨可以采取哪些额外步骤，使我们对每次更改都更有信心。

话虽如此，这是我们将要翻修的仓库： https : //github.com/patrickleet/streaming-ssr-react-styled-components

让我们开始吧。

步骤1：启用装修

我的存储库位于Github上，因此我们将转到Github Marketplace，在其中可以启用Renovate Application 。 根据他们的网站，它还支持GitLab，以及可以在其他情况下（例如本地）通过一些手动设置运行的工具。 我已经使用Renovate Bot一年多了，取得了巨大的成功，但是我只尝试了GitHub版本。

开发人员时间很昂贵，最好让机器人尽可能多地做！

设置非常简单，只需按下底部的“免费安装”即可。 如果您需要更多帮助，我们不愿检查他们的网站 ，因为在撰写本文后，过程可能会有所更改。

步骤2：配置装修

一旦安装了Renovate，就可以从您的帐户或组织的“设置”页面的“应用程序”选项卡中对其进行配置。

您可以选择为所有存储库启用它，或者选择存储库。 似乎我有很多回购协议，所以我决定仅对某些回购协议启用它。 该选择取决于您。

在授予Renovate访问存储库的权限后不久，您应该会收到一个名为“ Configure Renovate”的请求请求，该请求将向您的项目添加一个名为renovate.json的文件。

如果我们看一下内部，可以看到配置非常简单，但是可以进行很多自定义 。

{"extends" : [
    "config:base"
  ]
}

如果您对自动测试覆盖率和代码质量实施有足够的信心，则可能要进行一些自定义，例如启用自动合并。 如果所有检查都通过，这将使翻新为您自动更新软件包。 也可以仅对次要版本，devDependencies等启用自动合并。 我将留给您查看所有配置选项，并确定最适合您的团队和项目的项目。

在此最初的Pull Request中 ，Renovate将详细说明它检测到的软件包文件以及合并后可以看到的哪些Pull Requests和哪些更新。

我从使用Greenkeeper切换到Renovate的原因之一是它对Node.js软件包的支持远不止于此。 就我们的目的而言，它还将使Dockerfiles，docker -compose和Helm图表文件保持最新，但还支持更多功能，例如Gradle。 完整列表可在项目文档中找到。

要完成对Renovate的存储库配置，只需合并Pull Request。

步骤3：使用Travis CI自动为每个拉取请求运行测试

在之前的文章中，我们设置了一堆代码质量强制措施以及配置为100％代码覆盖率的自动化测试。 在开始合并可能破坏项目的更改之前，我们需要确保所有这些检查都与每个Pull Request一起运行。

有许多选项可以执行此操作，但是对于开源项目而言，最快，最简单的方法可能是Travis CI。

启用Travis CI就像翻新一样容易，只需转到Github Marketplace中的应用程序，选择免费的“开源”版本，然后按Install。

同样，您可以选择为所有存储库启用它，或者选择存储库。 我再次选择将其限制为仅我选择的存储库。

为了启动Travis，我们需要使用适当的设置将.travis.yml文件添加到项目中。 我们需要的最低要求是设置项目的语言。 支持的语言可以在其文档中找到。

language: node_js

这是将文件添加到项目的PR： https : //github.com/patrickleet/streaming-ssr-react-styled-components/pull/10

Travis会立即注意到并开始运行我们的构建。

默认情况下，Travis CI不知道我们应该运行哪个版本的Node，但是使用的默认版本为0.10.48 ，到现在大概0.10.48十年了。 我们将需要对配置文件进行小幅更新，以告诉我们我们想要什么。 在撰写本文时，Node 11是最新版本，并且已被选中。

让我们继续告诉Travis在Node 11以及最新版本12中运行该构建。

language: node_js
node_js:
  - 11
  - 12

Travis知道可以将测试作为其默认Node.js脚本的一部分运行，对于许多库或应用程序来说，这就足够了。 但是，该特定应用程序针对Parcel输出的构建版本运行了一些测试，因此，我们将需要自定义脚本以确保我们的Parcel构建在测试之前运行。

让我们再次更新.travis.yml文件，以解决脚本运行之前的此构建步骤。

language: node_js
node_js:
  - 11
  - 12

before_script:
  - npm run build

这样，我们就可以通过构建！

步骤4：启用代码覆盖率报告

好了，我们已经通过构建，并且我们的测试正在输出代码覆盖率，但是很难理解。 我们希望确保我们不会失去新PR的覆盖范围，因此如果我们将这些信息作为Pull Request的一部分，那将非常有帮助。 为此，我们可以使用来自Github Marketplace的称为CodeCov的工具。

和以前一样，选择“开源”计划，然后按Install。

同样，我选择了只授予特定存储库的权限，因为我有很多。

为了完成CodeCov的设置，我们可以向.travis.yml文件中添加几个步骤。 我们可以在after_success生命周期步骤中执行此操作。

这是我们新的.travis.yml文件：

language: node_js
node_js:
  - 11
  - 12

before_script:
  - npm run build

after_success:
  - npm i -g codecov
  - codecov

现在，随着每个PR的出现，一个漫游器都会对覆盖范围的更改进行评论。 这是启用CodeCov的PR 。

问号仅仅是因为我们在master分支中还没有覆盖率数据。 一旦合并此PR，将来的报告将包括PR和主分支之间的差异。

步骤5：引脚依赖关系

当我们设置Travis和CodeCov时，Renovate提出了一些请求。 首先是将所有依赖项设置为固定版本。 这消除了对SemVer或语义版本控制的依赖。 SemVer允许使用各种版本，并且在每次运行npm install时获取次要版本和补丁更新很有用。 似乎我们有一个机器人为我们监控软件包，我们将依靠它来代替SemVer来完成这项工作。 这样可以提高可复制性，并减少每个开发人员机器之间的差异。 可以在Renovate的博客中找到有关其原因的更详细讨论。

我们希望了解每个PR如何影响测试覆盖率，并确保它们仍然通过。 装修非常聪明，可以很容易地对已经建立的PR进行基础调整。 如果有足够的时间，它通常会自动执行此操作，但是我们可以通过单击PR描述中的复选框“如果您希望对该PR重新设置基准或重试，请选中此框”来帮助完成此任务。

过一会儿一变基已经进行的特拉维斯构建揭开序幕，并在几分钟后，我们路过的构建和测试，以及显示范围没有变化的代码覆盖率报告- 100％不动。

固定依赖项是一个相当安全的操作，因为所有发生的事情都是package-lock.json文件中已经安装的显式版本反映在package.json中。 我们还可以看到所有测试仍在通过，并且代码覆盖率没有受到影响。

让我们合并吧！

步骤6：测试我们的Dockerfile

如果您密切关注，您会注意到我们正在测试Node应用程序，而不是Dockerfiles。 在上一篇文章中，我们创建了一个运行和测试Dockerfile的过程，但是我们没有在Travis中利用该过程。 问题在于，Renovate将使PR保持Dockerfile的最新状态，如果我们不自动运行它们，我们可能会错过某些在Travis上有效但在容器中不起作用的东西。

让我们修复它。 为此，我们可以在.travis.yml文件中添加一个名为.travis.yml的新部分，以定义.travis.yml构建作业。

language: node_js
node_js:
  - 11
  - 12

before_script:
  - npm run build

after_success:
  - npm i -g codecov
  - codecov

jobs:
  include:
    - services:
        - docker
      script:
        - docker build . -t ssr
    - services:
        - docker
      script:
        - docker build . -f nginx/Dockerfile -t nginx

我们有两个Dockerfile，因为该项目专门演示了两种不同的选择-一种使用SSR，一种使用Nginx。 因此，我们定义了两个新的作业。

在Travis UI中，我们可以看到现在有四个作业–原始的Node 11和Node 12构建，以及另外两个运行docker build命令的作业。

在“ 25.3 ”和“ 25.4 ”内部单击，我们可以看到指示其成功的每个docker build命令的输出。

步骤7：套件更新

有了固定的依赖关系，我们将开始为其他需要更新的包接收“拉取请求”。 更新将是次要版本更新（只要软件包作者适当地使用semver通常是相当安全的），或者是主要版本更新（应接受更多检查）。 确保在Travis和CodeCov更改之前是否有任何未完成的操作会触发这些分支的重新设置。 我们还将获得对Dockerfiles的更新，由于有了最后一步，我们知道这些文件也正在构建中。

装修每小时只会发出两个请求请求，一次最多不会打开二十个请求请求。

让我们看一下到目前为止我收到的PR，并讨论如何处理它们。

到目前为止，其中有五个，还有一系列不同类型的示例。 ＃9和＃11都是对Dockerfile的更新，并且都通过了，包括实际运行构建，因此我们知道更新仍然可以使Dockerfile正常工作。 最好同时运行它们并为每个环境自动创建一个预览环境，但是要获得该工具，我们将需要更多的工具和更复杂的设置。 这是完全有可能的，通常我会为我的客户设置一些东西，但是这篇文章已经很长了。

＃12是主要版本更新。 在react-helmet-async的版本1中，发生了重大变化，并且我们的100％代码覆盖率正确检测到出了问题。 如果启用了自动合并，则不会完全按计划进行。

＃14也是主要版本更新，但是我们的构建和测试正在运行，因此我们可以很自信地说我们在这里都很好。 再次，为我们实际在云中运行此构建的预览环境将使我们更加自信。 我们可以单击PR说明中“发行说明”旁边的向下箭头以进行更深入的了解。

如果作者勤奋工作，他们应该详细说明哪些重大更改可以保证主要版本的功能。 不幸的是，在这种情况下，作者没有提供此信息。 不知道是什么原因会增加风险，并降低开发人员的信心。 如果您是图书馆作者，我强烈建议您使用诸如commitizen和语义发布之类的工具来确保您的软件包用户保持知情。 在上一篇文章中，我写了一个有关如何执行此操作的过程： 这6个基本工具将为您发布，版本化和维护您的NPM模块 。

最后， ＃16是次要版本更新，但展示了Renovate对相关软件包进行分组的能力。 一些库选择一起对库的所有组件进行版本控制。 Renovate以这种方式包含一些预设的流行库，例如我们在这里看到的babel。

我喜欢生活在狂野的一面，讨厌机器人可以点击的按钮，因此，我不会继续进行合并，而是继续为Renovate启用自动合并功能。 我非常有信心，正如PR＃12所展示的那样，测试的100％覆盖率在捕获重大变化方面做得很好。

要启用automerge，更新renovate.json文件，如下所示：

{"extends" : [
    "config:base"
  ],
  "automerge" : true
}

这是启用自动合并的PR 。

但是，如果没有预览环境，则主要版本可能存在太多错误。 让我们再进行一次更新，以便主要版本需要手动审核并合并：

{"extends" : [
    "config:base"
  ],
  "automerge" : true ,
  "major" : {
    "automerge" : false
  }
}

自动合并将需要一些时间才能开始，所以我让它做一段时间。

当我的机器人开始工作时，让我们看一下失败的PR，看看是否可以找出问题所在。

步骤8：调查失败的构建

构建失败是由于将库“ react-helmet-async”从版本0.2.0更新到1.0.0引起的。 不幸的是，当我们扩展发行说明时，库作者没有提供任何有关可能发生的重大更改的信息。

Renovate确实允许我们通过“比较源”链接单击以查看发生了哪些提交和代码更改，当然，查看失败的测试可能会向我们显示出了什么问题。

通过单击V1.0.0的“比较源”，我们可以看到重大更改将默认导出移动到了命名导出。

测试中的错误消息尚不清楚，因此谢天谢地地查看“比较源”链接有助于我们很快找到更改。

要解决此问题，我将继续检查Renovate所做的分支，并简单地向其添加一个新的提交，该提交会将导入更改为使用新的命名导入。 这是包含修订的提交 。

至此，我们的测试现在又通过了。

步骤9：测试主要版本变更

PR＃14是为什么我们需要测试主要版本更改的一个很好的例子。 如果我们有一个预览环境，我们会发现尽管所有测试都通过了，但是仍然存在与react-imported-component API更改相关的运行时错误。 似乎我们不是，我不得不通过检出翻新创建的分支并手动运行它来发现这一点。

库已更改，以便与React Suspense和React.lazy内联。 浏览文档会向我们展示如何重构以使用新的API。 如果您有兴趣， 可以在这里查看差异 。

结论

开发人员时间很昂贵，维护很重要，因为软件包更新通常包含安全修复程序。 保持最新状态将确保在作者进行更新时，可以修复正在使用的软件包中的所有已知错误。 由于使所有内容保持最新状态需要时间，因此这些小的更新通常会被抛在一边，并且在数月甚至数年中，您的项目可能会过时。 通过使用一组机器人来为您完成繁重的工作，使所有内容保持最新状态变得容易得多。

目前为止就这样了！ 编码愉快！

查看本系列的其他文章！ 这是第6部分。

• 第1部分：移至Next.js和Webpack
• 第2部分：使用Docker开发Node.js的更好方法
• 第3部分：增强Node.js的代码质量
• 第4部分：100％代码覆盖率神话
• 第5部分：两层（Docker多阶段构建）层的故事

有兴趣深入研究，并在每个“拉取请求”中获取诸如“预览环境”之类的东西吗？ 在我的新大师班Cloud Native Entrepreneur中，您将通过使用微服务后端设计端到端营销系统并使用Kubernetes在生产环境中运行它们来做到这一点！ 一路学习营销和企业家精神！ 检查 我的Hackernoon个人资料 以查找如何注册免费的信息会议！

最好，
帕特里克·李·斯科特

翻译自: https://hackernoon.com/bring-in-the-bots-and-let-them-maintain-our-code-gh3s33n9

机器人控制学习机器编程代码