Conteneurisation

Comme Devin a accès à un terminal et peut configurer et exécuter des logiciels sur son propre serveur, la mise en place d’un conteneur Docker est tout à fait à sa portée. Notre application d’exemple est un projet Go utilisant MongoDB comme stockage de données. Cette session correspond à la version, par Devin, d’une pull request qu’un développeur humain a soumise à un projet open source. Suivez l’exécution en direct ici. Nous commençons avec l’issue GitHub d’origine : Ensuite, nous pouvons rédiger un prompt simple pour Devin, basé sur ce qui est demandé dans cette issue. Nous lui demandons de lire l’issue GitHub ci-dessus pour obtenir du contexte supplémentaire, mais nous lui fournissons également notre propre résumé de la solution proposée et de ce que nous voulons que Devin produise. Devin commence par une étape d’analyse où il lit notre ticket GitHub associé et analyse le code et les fichiers de configuration du projet afin d’identifier les dépendances requises. Une fois son analyse terminée, Devin passe à l’installation de Docker sur sa machine locale, puis crée notre Dockerfile initial, docker-compose.yml et .dockerignore afin de pouvoir commencer à tester la configuration du conteneur. Il configure également notre fichier .env pour que l’application puisse s’exécuter avec le backend de conteneur ainsi configuré.

​

Test des conteneurs

Devin passe ensuite aux tests de chaque conteneur, en commençant par notre serveur MongoDB puis en poursuivant avec notre environnement Go. Une fois les conteneurs opérationnels, Devin passe au test de l’application elle-même. En parcourant l’historique des commandes de Devin, je vois qu’il a trouvé notre définition d’API Swagger et l’a chargée dans le navigateur intégré pour voir comment fonctionne l’API backend. Devin a ensuite construit une requête curl pour vérifier que l’API backend fonctionne et renvoie des résultats conformes à sa spécification de conception.

​

Débogage

Comme nous obtenons une erreur Connection refused, Devin passe immédiatement au débogage et à la correction de la configuration Docker. C’est un schéma récurrent dans lequel Devin peut s’auto-corriger au fil d’une session. Devin corrige rapidement le problème de configuration, redémarre le conteneur Docker et résume le travail qu’il a accompli pour nous. Lorsque nous comparons le travail de Devin au PR sur le projet lui-même, on constate plusieurs différences et améliorations notables :

• Devin met en place un fichier docker-compose.yml en plus de notre Dockerfile. Cela nous donne des paramètres d’orchestration plus précis, comme la définition du fonctionnement de notre réseau, la configuration de nos volumes et les dépendances entre services.
• Devin modifie le processus de build, passant de go mod tidy à une méthode qui nous permet de mettre en cache certaines dépendances dans notre build Docker.
• Devin génère un binaire Go lié statiquement plutôt que dynamiquement, ce qui devrait être plus léger pour notre build Docker.
• Devin configure nos certificats CA pour HTTPS et nous permet d’utiliser un fichier .env pour la configuration au lieu de passer directement les variables d’environnement.
• Et surtout, Devin ajoute un service MongoDB dans notre configuration Docker, ce que le PR sur le projet ne fait pas. Il part du principe que le développeur dispose déjà d’une instance MongoDB séparée en cours d’exécution.

En 13 minutes, Devin a réussi à assembler notre conteneur Docker pour le backend de ce projet en appliquant les bonnes pratiques, à le tester et à rédiger un récapitulatif complet de son travail. Essayez dès aujourd’hui votre propre prompt de conteneurisation sur votre base de code en vous inscrivant pour obtenir un compte Devin pour votre équipe.