跳转到主要内容

​
创建 Docker 容器

由于 Devin 可以使用终端，并且能够在自己的服务器上配置和运行软件，因此搭建 Docker 容器完全在它的能力范围之内。 我们的示例应用是一个使用 MongoDB 作为数据存储的 Go 项目。本次会话对应的是 Devin 处理一名真实开发者向某开源项目提交的 Pull Request 的版本。你可以在这里查看完整的实时运行过程。

​
从一个 GitHub Issue 开始

我们从原始的 GitHub Issue 开始：
Devin
接下来，我们可以根据这个 Issue 的需求，为 Devin 编写一个简单的提示。我们让它阅读上面的 GitHub Issue 以获取更多上下文，同时也提供我们自己对拟议解决方案的总结，以及我们希望 Devin 最终交付的成果。
Devin

​
分析代码库

Devin 首先会进行初步分析，它会读取我们关联的 GitHub Issue，并扫描项目的实际代码和配置文件，以查找所需的依赖项。
Devin
分析完成后，Devin 接着会在其本地环境中安装 Docker，然后创建初始的 Dockerfile、docker-compose.yml 和 .dockerignore，以便开始测试容器环境。它还会配置我们的 .env 文件，使应用程序能够在新配置的容器化后端环境中运行。
Devin

​
测试容器

接下来 Devin 会开始测试每个容器，先从我们的 MongoDB 服务器开始，然后再测试我们的 Go 运行环境。容器启动并就绪后，Devin 会继续测试应用本身。通过查看 Devin 的命令历史，我可以看到它找到了我们的 Swagger API 定义，并将其加载到内置的 Browser 中，以了解后端 API 的工作方式。
Devin
随后 Devin 构造了一个 curl 请求，用来测试后端 API 是否按其设计规范运行并返回预期结果。
Devin

​
调试

由于我们遇到了 Connection refused 错误，Devin 立刻开始调试并修正 Docker 配置。这是一种常见模式：在单次会话过程中，Devin 能够自我纠错。Devin 很快修复了配置问题，重启了 Docker 容器，并为我们总结了已经完成的工作。
Devin
当我们将 Devin 的工作与实际项目中的 PR进行对比时，可以看到一些明显的差异和改进：
  • Devin 在现有 Dockerfile 的基础上新增了一个 docker-compose.yml 文件。这为我们提供了更精细的编排设置，例如定义网络工作方式、卷（volume）的配置方式，以及各个服务之间的依赖关系。
  • Devin 将构建流程从 go mod tidy 修改为一种可以在 Docker 构建过程中缓存部分依赖的方式。
  • Devin 构建的是一个静态链接的 Go 二进制文件，而不是动态链接的，这样对我们的 Docker 构建来说更轻量。
  • Devin 为 HTTPS 配置了 CA 证书，并让我们可以使用 .env 文件进行配置，而不是直接传入环境变量。
  • 最值得注意的是，Devin 在我们的 Docker 配置中添加了一个 MongoDB 服务，而项目中的 PR 并没有这样做。该 PR 假定开发者已经有一个单独运行的 MongoDB 实例。
Devin
在 13 分钟内，Devin 已经按照最佳实践为这个项目的后端构建好了 Docker 容器，对其进行了测试，并撰写了详尽的工作总结。现在就通过注册团队版 Devin 账号，在你自己的代码库上尝试容器化相关的提示词吧。