The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
你收到一个 GitHub 的 pull request。你进行了审查，看起来没问题——是时候将其合并到 master 分支了。你在评论中提到 @rultor，要求他测试并合并。Rultor 开始创建一个新的 Docker 容器，将 pull request 合并到 master 分支，运行所有测试，若一切正常，就合并、推送并关闭请求。
然后，你要求 @rultor 将当前版本部署到生产环境。它检出你的代码库，启动一个新的 Docker 容器，执行你的部署脚本，并在 GitHub 的问题中向你报告。
市场上有许多工具可以自动化持续集成和持续交付（让我们称之为DevOps）。例如，可下载的开源Jenkins和托管的Travis都可以执行这些任务。那么，为什么我们还需要另外一个呢？
好吧，我们的项目需要三个非常重要的功能，但是在目前市场上的任何DevOps工具中都找不到全部。
Docker。每个构建应该在自己的Docker容器中工作，以简化配置，隔离资源并使错误易于重现。
告诉 vs. 触发。我们需要通过命令与DevOps工具进行通信，这些命令直接来自我们的问题跟踪系统（大多数项目中为GitHub问题）。所有现有的DevOps系统都会在特定条件下触发构建。我们需要开发人员能够通过与他们正在处理的工单中的类人命令与该工具进行交流。
这三个特点的组合是Rultor与所有其他现有系统的不同之处。
一旦Rultor在您的GitHub拉取请求中找到合并命令，它会准确地执行以下操作：
从中获取自动化构建执行命令，例如
bundle test。将您的存储库检出到其服务器上的临时目录中。
合并拉取请求到
master分支。开始一个新的Docker容器，并在其中运行
bundle test命令。如果一切正常，将修改后的
master分支推送到 GitHub。在 GitHub 的拉取请求中向您汇报。
你可以在这个pull request中看到它的实际应用：jcabi/jcabi-github#878。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:35
