跳转到主要内容
由于 Devin 可以使用终端，并且能够在自己的服务器上配置和运行软件，因此搭建 Docker 容器完全在它的能力范围之内。
我们的示例应用是一个使用 MongoDB 作为数据存储的 Go 项目。本次会话对应的是 Devin 处理一名真实开发者向某开源项目提交的 Pull Request 的版本。你可以在这里查看完整的实时运行过程。
我们从原始的 GitHub Issue 开始：
接下来，我们可以根据这个 Issue 的需求，为 Devin 编写一个简单的提示。我们让它阅读上面的 GitHub Issue 以获取更多上下文，同时也提供我们自己对拟议解决方案的总结，以及我们希望 Devin 最终交付的成果。
Devin 首先会进行初步分析，它会读取我们关联的 GitHub Issue，并扫描项目的实际代码和配置文件，以查找所需的依赖项。
分析完成后，Devin 接着会在其本地环境中安装 Docker，然后创建初始的 Dockerfile、docker-compose.yml 和 .dockerignore，以便开始测试容器环境。它还会配置我们的 .env 文件，使应用程序能够在新配置的容器化后端环境中运行。
接下来 Devin 会开始测试每个容器，先从我们的 MongoDB 服务器开始，然后再测试我们的 Go 运行环境。容器启动并就绪后，Devin 会继续测试应用本身。通过查看 Devin 的命令历史，我可以看到它找到了我们的 Swagger API 定义，并将其加载到内置的 Browser 中，以了解后端 API 的工作方式。
随后 Devin 构造了一个 curl 请求，用来测试后端 API 是否按其设计规范运行并返回预期结果。
由于我们遇到了 Connection refused 错误，Devin 立刻开始调试并修正 Docker 配置。这是一种常见模式：在单次会话过程中，Devin 能够自我纠错。Devin 很快修复了配置问题，重启了 Docker 容器，并为我们总结了已经完成的工作。
当我们将 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 实例。
在 13 分钟内，Devin 已经按照最佳实践为这个项目的后端构建好了 Docker 容器，对其进行了测试，并撰写了详尽的工作总结。现在就通过注册团队版 Devin 账号，在你自己的代码库上尝试容器化相关的提示词吧。 
