Notre application d’exemple est une plateforme éducative en ligne développée avec le framework web Python Django. Une PR a récemment été ouverte pour intégrer l’API d’email SendGrid dans l’application, et dans ce tutoriel nous allons demander à Devin de réaliser sa propre implémentation de SendGrid afin de montrer comment il peut interagir avec des API tierces. Dans notre prompt, nous fournissons des instructions précises sur la façon dont et l’endroit où nous voulons que Devin intègre nos hooks SendGrid, et nous lui demandons de revenir à un hash de commit antérieur à la fusion de la PR ci‑dessus, afin de disposer d’un point de départ propre pour notre intégration. Suivez la session Devin en direct ici. Devin examine la base de code et s’assure qu’il n’existe aucune implémentation d’e‑mails conflictuelle déjà présente dans l’application.

​

Implémentation de SendGrid

Il passe ensuite à l’implémentation de l’API SendGrid et nous demande nos identifiants API, que nous pouvons configurer en tant que Secrets dans l’environnement de Devin afin qu’il puisse y accéder par la suite en tant que variables d’environnement (ENV). Maintenant qu’il dispose d’identifiants API valides, Devin termine l’implémentation de SendGrid. Lorsque je compare l’implémentation SendGrid de Devin à la PR effectivement fusionnée à laquelle nous avons fait référence au début, je constate quelques améliorations notables :

• Devin a configuré SendGrid dans un nouveau module email.py plutôt que dans le même fichier que la vue elle‑même. Il renvoie également True ou False pour indiquer si l’envoi de l’e‑mail a réussi, en se basant sur le code de réponse de SendGrid.
• Devin utilise le module de journalisation intégré de Python plutôt que print (ce qui était un point spécifiquement signalé par le relecteur de la PR).
• Devin rend également l’adresse e‑mail de l’expéditeur configurable plutôt que codée en dur, tout en ajoutant une valeur par défaut si la variable d’environnement correspondante n’existe pas.
• Devin ajoute une gestion des exceptions à sa méthode mailInstructor.

Une fois son implémentation principale terminée, je peux demander à Devin de tester l’application en ajoutant un compte formateur associé à mon adresse e‑mail. Pour tester l’application, il devra également installer et configurer toutes les dépendances, comme un serveur PostgreSQL et les bibliothèques Python pertinentes.

​

Débogage

Devin rencontre rapidement une erreur, car je ne lui ai jamais fourni d’adresse d’expéditeur (FROM) pour mon compte SendGrid. Devin utilise en fait son Browser pour accéder à la documentation de l’API, comprendre ce qui se passe et analyser les messages d’erreur ainsi que les bonnes pratiques d’implémentation : Je peux revenir dans la boîte de dialogue Secrets et ajouter une variable SENDGRID_FROM_EMAIL à laquelle Devin pourra accéder. Je demande également à Devin d’utiliser le nom d’utilisateur SendGrid par défaut « apikey », car je n’ai pas configuré de sous-compte pour l’API : Devin détecte que mes demandes et exigences d’implémentation peuvent être généralisées et me propose d’ajouter du Knowledge qu’il pourra réutiliser à l’avenir : Si vous le souhaitez, vous pouvez également modifier le Knowledge pour le rendre encore plus précis, si ces tactiques doivent être utiles lors de futures sessions que votre équipe prévoit de mener.

​

Tests

Après quelques minutes de configuration et de mise en place de l’environnement, Devin termine sa session avec succès et je vois l’e-mail dans ma boîte de réception. Je n’ai pas réellement configuré le modèle SendGrid pour y mettre un vrai contenu, mais la requête API fonctionne et le travail de Devin est donc terminé ! Si je choisis de soumettre une PR, Devin a déjà rédigé le message pour moi, avec le détail de tout ce qu’il a modifié dans l’application et de son fonctionnement : Inscrivez-vous dès aujourd’hui pour essayer Devin et vous attaquer à une intégration d’API qui traîne depuis longtemps dans le backlog de votre équipe.