Développement de logiciels avec Devin : Intégrations, tests et CI/CD (Partie 3)

Bienvenue ! A la fin de le deuxième tutorielnous avions un terrain de jeu fp-ts au thème pastel, un backend NestJS + PostgreSQL, et un cursus anonyme UUID.

Vous pouvez accéder à tous les tutoriels de la série Devin ici :

1. Mise en place et première Pull Request (Partie 1)
2. Expédition d'une tranche verticale avec Devin (Partie 2)
3. Intégrations, tests et CI/CD (Partie 3) 
4. Sécurité, déploiement, maintenance (partie 4)

Ce que nous avons fait jusqu'à présent est parfait pour le piratage en solo, mais il est temps de voir comment Devin s'intègre dans les flux de travail d'une équipe. Dans ce troisième tutoriel, nous verrons :

• Intégrations: Devin ouvrira des tickets Jira, travaillera dessus et diffusera chaque statut de RP directement sur Slack.
• Portes de qualité:  Nous ajouterons des tests unitaires Jest pour l'API, des flux Playwright de bout en bout pour l'interface utilisateur et nous appliquerons une couverture de 90 %.
• CI/CD: Les actions GitHub lintent, vérifient le type, exécutent tous les tests et joignent les rapports Playwright aux demandes de téléchargement avant qu'elles ne soient fusionnées.

Pas d'authentification ni de déploiement en production pour l'instant, cela se fera dans la partie 4 !

Mettre en place une intégration Slack sur Devin

L'intégration de Devin dans votre flux de communication et de tickets est entièrement manuelle et se fait via l'interface Devin.

Vous pouvez vous connecter à Slack à partir de l'onglet d'intégration des paramètres de Devin, ou installer l'application "Devin AI" à partir de l'App Directory de Slack.

L'application affiche toujours "Not approved by Slack" dans la boîte de dialogue OAuth. Cognition indique que l'examen de la sécurité est en cours et que la fonctionnalité n'est pas affectée.

Choisissez ensuite une chaîne :

Vous pouvez discuter avec Devin en le mentionnant simplement :

Il démarre une session à laquelle vous pouvez accéder dans l'interface utilisateur :

Par défaut, vous êtes informé des mises à jour des relations publiques dans le canal de votre choix, mais il existe quelques paramètres de notification différents que vous pouvez ajuster dans les paramètres de chaque session.

Configurer une intégration Jira sur Devin

Pour intégrer Jira, vous devez créer un compte utilisateur dédié au bot (par exemple, devin-bot@… ) et lier ces informations d'identification sous Devin → Équipe ▸ Intégrations ▸ Jira.

Depuis votre compte personnel, vous pouvez alors créer un nouveau ticket et ajouter l' étiquette devin.

Devin publie un commentaire d'analyse avec les grandes lignes d'un plan et une invite "Commencer la session ? Tapez "oui" pour le laisser coder ou supprimez l'étiquette pour que le ticket reste réservé à l'homme.

Note : Devin ne déplace pas automatiquement les cartes sur votre plateau. Vous ou votre GP devez encore les faire glisser vers En cours ou Terminé. Le contrôle du flux de travail reste ainsi entre les mains de l'homme.

Permettre à Devin de travailler à partir de tickets Jira

Une fois Slack et Jira connectés, j'ai tenté une véritable expérience d'"agent en tant que coéquipier" et j'ai lancé de vrais tickets à Devin pour voir s'il pouvait les mettre en œuvre sans aide.

Le flux de travail que j'ai utilisé

Voici comment je procède :

1. Créez un ticket dans mon projet JIRA nouvellement créé et rédigez un critère d'acceptation clair.
2. Ajoutez l' étiquette devin, qui indique à Devin qu'il doit analyser.
3. Devin fait des commentaires avec un plan par étapes, une estimation de confiance et demande : "Commencer la session ?".

4. J'ai répondu "Oui". Le ticket indique "Session démarrée" et donne le lien de l'IDE web. Lorsque le PR atterrit, Devin poste "Merged ✅" sur Slack, et je déplace la carte sur le plateau. Rien de tout cela ne coûte des UCA jusqu'à ce que je réponde "oui".

Cinq billets réels, cinq résultats très différents

Voici un résumé de ce qui s'est passé pour cinq billets réels :

Des choses qui semblaient aléatoires

Ce sont les points qui auraient dû être améliorés :

• Titres des relations publiques : J'ai spécifié un modèle de dénomination dans chaque invite, mais Devin a inventé un nouveau format à chaque fois.
• Fidélité à la base de données : Sur un billet, il a migré vers Postgres, et sur un autre, il a réintroduit silencieusement SQLite.
• Estimation ACU : Le commentaire d'analyse indiquait que le ticket de sac de sable nécessiterait 1,5 UCA, alors qu'en réalité il s'agissait de deux sessions et de 5 UCA.
• La confiance contre l'exécution : Un ticket avec un faible niveau de confiance a été exécuté en 3 minutes, et parfaitement. L'une d'entre elles, avec un niveau de confiance élevé, a nécessité 45 minutes de bricolage.

Devin sur Jira est prometteur : deux tickets ont été clôturés parfaitement, un autre avec un léger coup de pouce, et même le pire des cas n'a coûté que du temps, pas de retour en arrière. Mais la cohérence n'est pas encore au rendez-vous, c'est pourquoi un cadrage serré et des contraintes explicites sont vos amis.

Ajouter des tests automatisés avec Jest et Playwright

Une fois que le chat et les tickets sont en circulation, l'étape suivante consiste à s'assurer que le code défectueux ne peut pas se faufiler. J'ai demandé à Devin deux choses : des tests unitaires de backend et des tests Playwright de bout en bout qui imitent un apprenant modifiant un exercice dans le navigateur.

Tests unitaires du backend : étonnamment sans douleur

J'ai demandé à Devin des suites de tests Jest couvrant le résolveur GraphQL, la couche de service et les modèles Prisma. Lorsque j'ai demandé une estimation de l'ACU, il m'a été répondu 20 ACUs !

J'ai pensé qu'il s'agissait d'une erreur et j'ai quand même lancé la tâche. Elle a coûté 1,1 UCA et a été de loin la tâche la mieux exécutée jusqu'à présent.

Dramaturge e2e : mur rouge, mur vert

Cette dernière était légèrement plus chère et coûtait 2,3 UCA.

Le flux enregistré : ouvrir /learn/option-01 → éditer le code → attendre ✓ → rafraîchir la page → ✓ persiste.

Lors de la première exécution, environ 70 % des assertions ont échoué. Il y a eu de nombreux problèmes de redimensionnement, des comptes de tableau de bord périmés, et même le "happy path" a flanché.

Malgré la commande "Ignorez les tests qui échouent, nous les corrigerons plus tard" dans mon invite, Devin a continué à patcher le code jusqu'à ce que la suite devienne principalement verte (utile, mais pas ce que j'avais demandé).

Nous avons encore quelques tests qui échouent parce que nous avons un certain nombre de bogues dans le système. Mais ce n'est pas grave, nous réglerons les choses plus tard pour nous assurer que tous ces tests sont verts.

Ajouter un pipeline d'actions GitHub en un clic

Avec les tests unitaires et de bout en bout en place, la dernière étape consistait à s'assurer que chaque demande d'extraction exécute ces vérifications automatiquement. J'ai demandé à Devin un flux de travail dépouillé, sans artefacts, sans portes de couverture, juste lint → type-check → tests.

Devin a fourni un pipeline étonnamment soigné en une seule fois, sans qu'aucun suivi ne soit nécessaire :

• Dérive de configuration zéro: Devin a réutilisé des scripts npm existants, il n'y a donc pas de nouveaux outils à apprendre.
• Tout en parallèle: Lint, type-check, et les deux suites de tests s'exécutent côte à côte, de sorte que l'ensemble du flux de travail se termine en ~4 min sur les runners gratuits de GitHub.
• Triage clair: Si ESLint échoue mais que les tests réussissent, le travail de synthèse signale toujours l'erreur lint ; vous ne fusionnez jamais un code "partiellement rouge".

Devin a poussé le flux de travail, a attendu que la vérification soit terminée dans GitHub, et a ensuite décidé que c'était fait. Je dois dire qu'il est difficile de faire mieux que 0,4 ACU pour un pipeline en parfait état de fonctionnement. YAML est manifestement le domaine de prédilection de Devin.

Avec ce flux de travail fusionné, chaque PR doit passer lint, compiler et les deux suites de tests avant que quelqu'un n'appuie sur le bouton vert !

Wiki de Devin sur les produits

Devin est livré avec un "Wiki" intégré qui peut vivre à côté de votre code. Il s'agit d'une base de connaissances légère, générée automatiquement, que l'agent peut lire et dans laquelle il peut écrire pendant qu'il travaille. Après avoir connecté Slack, Jira et CI, ce Wiki est un bon endroit pour les notes architecturales. Il vaut la peine d'y jeter un coup d'œil !

À ma connaissance, il n'est pas possible de l'éditer manuellement, et vous devez compter sur Devin pour maintenir le Wiki à jour.

Aperçu des coûts et des délais et réflexions

Une fois que toutes les intégrations, les tests et le pipeline ont été mis en place, j'ai fait le compte de la facture et de l'horloge :

Donc, environ 2 heures d'efforts humains pour obtenir des tickets, des tests et des CI poussés. C'est plus rapide que ce que j'aurais fait, c'est certain.

À ce stade, cependant, je suis partagé. Il y a encore beaucoup de bogues, et si j'avais écrit toute la base de code moi-même, je pourrais probablement corriger les problèmes plus rapidement que Devin ne brûle les crédits. 

Mais Devin a écrit la majeure partie de l'application, de sorte que l'agent "connaît" mieux la structure que moi. Néanmoins, il peine à remplacer les valeurs codées en dur par des valeurs dynamiques, il laisse des bouts de code dans chaque fichier, et il a besoin que je m'assoie devant mon ordinateur portable pour surveiller toutes ses actions.

J'ai également trouvé le processus un peu frustrant, mais pas de la même manière que je le serais en poursuivant un insecte que je ne peux pas comprendre. Il y a un monde de différence (pour moi, en tout cas) entre être frustré que le code ne fonctionne pas et être frustré qu'un agent d'intelligence artificielle ne puisse pas suivre quelques instructions de base. Cette dernière est carrément exaspérante.

Je pense que Devin peut être très utile lorsqu'il est bien utilisé, mais comme tous les agents d'intelligence artificielle, il ne peut pas remplacer un ingénieur logiciel. Il est possible de l'utiliser pour certaines tâches, mais je ne pense pas qu'il soit très approprié ou durable de l'utiliser pour chaque billet.

Quelle est la prochaine étape ?

Nous sommes connectés à Slack et Jira, les tests sont verts et le portail CI bloque chaque PR négligé. Mais pour un véritable lancement de la production, il nous manque encore quatre piliers :

1. Authentification: connecter les identifiants NextAuth → cookies JWT → GqlAuthGuard dans NestJS pour que les progrès soient liés à des utilisateurs réels.
2. Renforcement de la sécurité: Suivi des erreurs par le cursus, à la fois pour le web et l'API.
3. Déploiement continu: Un pipeline Vercel (web) qui génère des URL de prévisualisation sur chaque branche et qui passe à prod lorsque la branche principale devient verte.

C'est le programme de la quatrième partie, la dernière ligne droite où nous verrons si Devin peut sécuriser, déployer et surveiller l'application sans intervention humaine. Fixez votre base de données sur Postgres (encore une fois !), mettez ces ACU en place, et je vous verrai dans le dernier chapitre. le dernier chapitre.

Si vous êtes prêt à continuer, cliquez sur le dernier élément de la liste ci-dessous pour accéder au quatrième tutoriel :

1. Mise en place et première Pull Request (Partie 1)
2. Expédition d'une tranche verticale avec Devin (Partie 2) 
3. Intégrations, tests et CI/CD (Partie 3) 
4. Sécurité, déploiement, maintenance (partie 4)