Zum Hauptinhalt springen

​
Erstellen eines Docker-Containers

Da Devin Zugriff auf ein Terminal hat und Software auf seinem eigenen Server konfigurieren und ausführen kann, ist das Einrichten eines Docker-Containers für ihn problemlos möglich. Unsere Beispielanwendung ist ein Go-Projekt mit MongoDB als Datenspeicher. Diese Sitzung ist Devins Version eines Pull Requests, den ein echter Entwickler zu einem Open-Source-Projekt eingebracht hat. Verfolge die Live-Ausführung hier.

​
Mit einem GitHub-Issue beginnen

Wir starten mit dem ursprünglichen GitHub-Issue:
Devin
Als Nächstes können wir einen einfachen Prompt für Devin formulieren, basierend darauf, was in diesem Issue gefordert wird. Wir weisen Devin an, das oben stehende GitHub-Issue für zusätzlichen Kontext zu lesen, geben ihm aber auch unsere eigene Zusammenfassung der vorgeschlagenen Lösung und der Ergebnisse, die Devin erzeugen soll.
Devin

​
Untersuchung der Codebase

Devin beginnt mit einem Untersuchungsschritt, in dem es unser verlinktes GitHub-Issue liest und den eigentlichen Code sowie die Konfigurationsdateien des Projekts nach erforderlichen Abhängigkeiten durchsucht.
Devin
Nachdem die Analyse abgeschlossen ist, installiert Devin Docker auf seiner lokalen Maschine und erstellt anschließend unser erstes Dockerfile, die docker-compose.yml und die .dockerignore, damit es mit dem Testen des Container-Setups beginnen kann. Außerdem konfiguriert es unsere .env-Datei, sodass die Anwendung mit dem neu konfigurierten Container-Backend ausgeführt werden kann.
Devin

​
Testen der Container

Devin testet anschließend jeden Container, beginnend mit unserem MongoDB-Server und danach unserer Go-Umgebung. Sobald die Container laufen, fährt Devin damit fort, die Anwendung selbst zu testen. Beim Durchsehen von Devins Command History sehe ich, dass Devin unsere Swagger-API-Definition gefunden und sie im integrierten Browser geladen hat, um nachzuvollziehen, wie die Backend-API funktioniert.
Devin
Anschließend hat Devin eine curl-Anfrage zusammengestellt, um zu testen, dass die Backend-API läuft und Ergebnisse wie in der Design-Spezifikation vorgesehen zurückgibt.
Devin

​
Debugging

Da wir einen Verbindungsfehler Connection refused erhalten, macht sich Devin sofort ans Debuggen und Korrigieren der Docker-Konfiguration. Dies ist ein häufiges Muster, bei dem Devin Fehler im Verlauf einer Session selbst korrigieren kann. Devin behebt das Konfigurationsproblem schnell, startet den Docker-Container neu und fasst die erledigte Arbeit für uns zusammen.
Devin
Wenn wir Devins Arbeit mit dem PR im eigentlichen Projekt vergleichen, gibt es einige bemerkenswerte Unterschiede und Verbesserungen:
  • Devin richtet zusätzlich zu unserem Dockerfile eine docker-compose.yml-Datei ein. Das verschafft uns spezifischere Orchestrierungseinstellungen, etwa wie unser Netzwerk funktioniert, wie unsere Volumes konfiguriert sind und welche Dienste voneinander abhängen.
  • Devin ändert den Build-Prozess von go mod tidy zu einer Methode, mit der wir einige der Abhängigkeiten in unserem Docker-Build cachen können.
  • Devin erstellt ein statisch gelinktes Go-Binary statt eines dynamisch gelinkten, was für unseren Docker-Build schlanker sein sollte.
  • Devin konfiguriert unsere CA-Zertifikate für HTTPS und ermöglicht uns die Verwendung einer .env-Datei für die Konfiguration, anstatt Umgebungsvariablen direkt zu übergeben.
  • Und am deutlichsten: Devin fügt unserer Docker-Konfiguration einen MongoDB-Dienst hinzu, den der PR im Projekt nicht enthält. Dort wird davon ausgegangen, dass bereits eine separate MongoDB-Instanz des Entwicklers läuft.
Devin
In 13 Minuten hat Devin erfolgreich unseren Docker-Container für das Backend dieses Projekts nach Best Practices erstellt, getestet und eine umfassende Zusammenfassung seiner Arbeit geschrieben. Probieren Sie noch heute Ihren eigenen Containerisierungs-Prompt auf Ihrer eigenen Codebasis aus, indem Sie sich für ein Devin-Konto für Ihr Team anmelden.