メインコンテンツへスキップ
Devin はターミナルにアクセスでき、自身のサーバー上でソフトウェアを設定・実行できるため、Docker コンテナのセットアップも問題なく行うことができます。
ここで扱うサンプルアプリケーションは、データストアに MongoDB を使用する Go プロジェクトです。このセッションは、実際の開発者がオープンソースプロジェクトに作成・送信したプルリクエストを、Devin が行ったバージョンです。ライブ実行の内容はこちらから確認できます。
まずは元の 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 は、バックエンド API が稼働しており、設計仕様どおりに結果を返すことを確認するための curl リクエストを組み立てました。
Connection refused エラーが発生したため、Devin は直ちにデバッグに進み、Docker 設定の修正を行います。これは、セッションを進めながら Devin が自動的にエラーを修正していく、よくあるパターンです。Devin はすぐに設定上の問題を修正し、Docker コンテナを再起動し、行った作業をまとめて要約します。
Devin の作業内容を実際のプロジェクトの PR と比較すると、いくつか顕著な差分と改善点があります。
- Devin は Dockerfile に加えて、docker-compose.yml ファイルをセットアップします。これにより、ネットワークの構成方法、ボリュームの設定方法、どのサービスが互いに依存しているかといった、より具体的なオーケストレーション設定が可能になります。
- Devin はビルドプロセスを
go mod tidy から変更し、Docker ビルド内で一部の依存関係をキャッシュできる方法に切り替えます。
- Devin は動的リンクではなく静的リンクされた Go バイナリをビルドし、Docker イメージをより軽量にします。
- Devin は HTTPS 用の CA 証明書を設定し、環境変数を直接渡すのではなく、.env ファイルを使って設定できるようにします。
- そして何より重要なのは、プロジェクトの PR にはない MongoDB サービスを Docker 設定に追加している点です。PR 側は、開発者がすでに別の MongoDB インスタンスを起動していることを前提としています。
13 分で、Devin はこのプロジェクトのバックエンド用 Docker コンテナをベストプラクティスに従って構築し、テストし、その作業内容について包括的な概要を書き上げました。チーム向けの Devin アカウントにサインアップして、自身のコードベースに対してコンテナ化用のプロンプトを試してみてください。 
