Développement de logiciels avec Devin : Sécurité, déploiement, maintenance (partie 4)

Bienvenue ! Nous y sommes presque : Slack gazouille, Jira a des tickets, les tests sont verts, et notre CI bloque tous les PR bâclés. La quatrième partie est l'étape finale où nous transformerons l'aire de jeu du fp-ts en quelque chose que nous pourrions, en théorie, montrer au public.

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)

Voici le plan de ce quatrième tutoriel :

• Auth : Fini les UUID anonymes, nous ajouterons des identifiants NextAuth, des cookies JWT, et un GqlAuthGuard afin que les progrès soient liés à de vrais utilisateurs.
• La production est en ligne de mire : Une ligne de code Sentry dans l'application Web, une dans l'API Nest, et toutes les exceptions sont affichées dans le tableau de bord.
• Déploiement par bouton-poussoir : Le front-end est mis en ligne sur Vercel avec des URL de prévisualisation sur chaque PR. (L'API restera locale pour l'instant, nous simulerons la production avec Docker).

Nous réfléchirons également à cette programmation en binôme avec Devin et verrons où elle brille et où un humain doit encore régler les détails avant que le monde ne voie le repo. Prêt pour la dernière ligne droite ?

Des UUID anonymes aux utilisateurs réels

Ce que j'ai demandé à Devin

En bref, j'ai demandé à Devin de supprimer le flux anonyme UUID et de me donner une vraie pile d'authentification :

• NextAuth v6 credentials provider in apps/web
• NestJS AuthModule avec Argon2 hashing et JWT cookies
• Migration Prisma qui ajoute un tableau User et modifie Progress.sessionId → userId (non nul)
• Copiez toutes les lignes de progression UUID existantes dans un utilisateur fictif afin que les apprenants conservent leurs badges.
• Ne pas remplacer Postgres par SQLite

Ce qui est revenu (principalement bon)

Voici un résumé des résultats :

Une autre migration SQLite

Devinez ce que j'ai vu apparaître à nouveau dans la petite boîte à idées de Devin.

Migration réussie de PostgreSQL vers SQLite pour le développement local 🥳

Exactement ce que je lui avais dit de ne pas faire ( ). Le schéma Prisma a été réécrit pour SQLite, et les chaînes de connexion et les types ont été modifiés (de TIMESTAMP à DATETIME). Je l'ai vu au milieu de la session :

1. Pause de la session.
2. git checkout main apps/api/prisma/schema.prisma (restauration du schéma Postgres).
3. Supprimez le nouveau fichier dev.db.
4. npm run prisma:migrate --workspace=apps/api pour réappliquer les migrations Postgres.
5. Reprenez Devin ; il a détecté la réversion et a continué sans se plaindre.

Dommages : 0,8 ACU et une dizaine de minutes.

Liste de contrôle de la rupture pour les coéquipiers

J'apprécie vraiment les instructions que Devin donne dans les PR. Ici, il nous a dit de le faire :

# 1  Install new deps
npm install --workspaces

# 2  Run the Postgres migration
npm run prisma:migrate --workspace=apps/api

# 3  Restart everything
npm run dev:api   &   npm run dev:web

Aperçu de l'architecture

Dans le wiki, j'ai trouvé ce diagramme utile de notre nouveau système d'authentification :

Avec de vrais utilisateurs en place et la base de données fermement revenue sur Postgres, nous sommes enfin prêts à suivre les progrès des apprenants authentiques, à envoyer des versions préliminaires à Vercel et à détecter les erreurs d'exécution avec Sentry.

Front-end sur Vercel, liens de prévisualisation sur chaque PR

Une fois les connexions sécurisées mises en place, la prochaine étape évidente était de montrer au monde quelque chose de cliquable. Nous avons décidé de ne déployer que le front-end Next.js pour l'instant. API et Postgres resteront sur ma machine locale jusqu'à ce que nous choisissions un hébergeur qui corresponde à notre budget.

Accrochage manuel du compte (0 ACU)

Connecter Devin à mon compte Vercel personnel via les intégrations natives n'est pas encore possible. Je l'ai donc fait manuellement, via le tableau de bord Vercel :

1. Connectez-vous à Vercel et cliquez sur "New Project → Import Git Repository".
2. Sélectionnez le répertoire fp-ts-exercises, laissez la commande de construction comme npm run build --workspace apps/web, et cliquez sur Deploy.
3. Copiez les fichiers VERCEL_PROJECT_ID et VERCEL_TOKEN dans GitHub Secrets.

Laissez Devin mettre à jour le flux de travail de l'IC (0.4 ACU)

Suite à mon invitation, Devin a ajouté une tâche unique au bas du flux de travail existant et une minuscule étape shell qui boucle l'URL générée vers Slack :

- name: Deploy to Vercel
  if: ${{ success() && github.event_name == 'pull_request' }}
  run: npx vercel deploy --prod --token ${{ secrets.VERCEL_TOKEN }}
  env:
    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
    VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Résultat

Pousser une branche → CI green → Slack ping :

✅ Preview ready: https://fp-ts-exercises-git-my-branch.vercel.app

En ouvrant le lien, vous avez pu voir notre aire de jeu, notre flux d'authentification complet et notre tableau de bord de l'apprenant. Aucune modification de l'environnement n'est encore nécessaire du côté de Vercel, car le front-end communique avec mon API locale via http://localhost:4000.

Un regard plus attentif sur le système des secrets de Devin

Avant d'intégrer Sentry, j'ai jeté un coup d'œil au système de secrets de Devin pour savoir si je devais l'utiliser. Devin propose un coffre-fort intégré "Secrets" qui vous permet de donner à l'agent des clés API, des URL de base de données ou des jetons OAuth sans les enregistrer dans Git et sans les exposer dans le chat. Considérez-le comme un équivalent léger des secrets d'actions de GitHub ou des variables d'environnement de Vercel, mais limité aux espaces de travail de Devin dans le cloud.

Ajout d'un secret

Voici les étapes à suivre pour ajouter un secret :

1. Ouvrir Équipe → Secrets dans le tableau de bord Devin.
2. Cliquez sur "Ajouter un secret et entrez un nom (SENTRY_DSN_WEB ) et sa valeur.
3. Devin confirme le stockage ; la clé est maintenant disponible à l'adresse $.SENTRY_DSN_WEB.

Utiliser un secret dans une tâche

Tâche : mise à jour de l'initialisation de l'API Sentry ; définir le DSN sur $SECRET.SENTRY_DSN_API

Devin substitue la valeur lorsqu'il écrit main.ts. Dans l'onglet shell, vous verrez le DSN littéral, mais le journal de discussion le masque.

Avantages et inconvénients

Pour :

• Il n'y a pas de risque de fuite de clés dans les RP ou les journaux Timelapse.
• Les secrets définis par l'organisation fonctionnent d'une session à l'autre : un seul téléchargement, plusieurs utilisations.
• Aucun coût de crédit pour le stockage ou la recherche.

Cons :

• Les clés ne sont pas disponibles localement, sauf si vous les copiez dans .env. Les essais en dehors de Devin nécessitent une configuration manuelle.
• Pas de délimitation par environnement (par exemple, "uniquement en production"). Toutes les sessions bénéficient de tous les secrets.

Quand l'utiliser ?

Je trouve qu'il est plus facile d'utiliser le coffre-fort de Devin lorsque Devin lui-même a besoin de la clé (par exemple, en poussant vers Vercel, en frappant un registre privé, ou en câblant Sentry pendant la construction). Je continuerais à utiliser .env / GitHub Actions secrets pour tout ce qui s'exécute également dans votre shell de développement local ou vos exécutions CI.

Intégration de Devin avec Sentry

Voici le texte que j'ai utilisé : Ajoutez Sentry aux deux applications pour que chaque exception apparaisse dans mon tableau de bord. Utilisez les variables d'environnement dans .env. Il n'y a pas d'autre changement de comportement".

Travail de Devin (0,6 ACU, une session)

Voici un résumé des résultats :

Mes étapes manuelles

Voici les étapes que j'ai suivies :

1. Copiez les DSN de mon projet Sentry dans .env.
2. Redémarrage des deux serveurs de développement.
3. J'ai lancé une requête délibérément mauvaise sur le site http://localhost:4000/graphql pour vérifier qu'elle fonctionnait. Un problème est apparu dans Sentry en quelques secondes.

Pourquoi j'ai zappé les secrets de Devin

C'est la raison pour laquelle j'ai sauté l'étape des secrets de Devin :

• Modèle mental plus simple : le même fichier .env partout.
• Il est plus facile d'exécuter des versions préliminaires sur Vercel (les variables d'environnement y sont déjà définies).
• Pas de brûlage ACU pour les opérations de stockage de secrets.

Réflexions : Les points forts et les points faibles de Devin

Il y a quatre parties de tutoriel, ce repo était une pile poussiéreuse d'exercices de fp-ts - maintenant, c'est fait :

• Base de code modernisée: Dernières dépendances, configuration TS stricte, règles lint & Prettier (Partie 1).
• Terrain de jeu par navigateur: Next.js 14 + Editeur Sandpack avec retour d'expérience Vitest (Partie 2).
• NestJS + Postgres backend: API GraphQL, migrations Prisma, suivi de la progression anonyme → JWT (cursus 2 & 4).
• Pipeline en voie d'achèvement: Flux de travail CI qui lie, vérifie le type, exécute Jest et Playwright, et bloque tout PR défaillant (Partie 3).
• Intégrations d'équipes: Les pings d'état Slack, l'analyse des étiquettes Jira et les URL de prévisualisation sur chaque branche (Partie 3).
• Observabilité de la production: Sentry se connecte à la fois au web et à l'API, capturant toutes les exceptions (Partie 4).
• L'aperçu déploie: Vercel crée une URL partageable pour chaque pull request (Partie 4).

Nous avons dépensé environ ≈ 70 UCA au total (~157 $ pour le plan de base) et environ deux jours ouvrables d'examen pratique.

Ce que Devin fait terriblement bien

C'est là que je pense que Devin est très bon :

Quand l'humain bat encore l'agent

C'est sur ce point que je pense que Devin doit encore s'améliorer :

Mon avis

Les documents de Devin n'ont jamais promis un constructeur de produits. Ils définissent une zone de tolérance beaucoup plus étroite et, rétrospectivement, j'aurais dû rester à l'intérieur de cette zone. La page officielle "Quels sont les points forts de Devin ? énumère quatre utilisations des titres :

La documentation qualifie d'"expérimental" le développement de fonctionnalités qui couvrent l'interface utilisateur, l'API et les flux de données. Ils sont décrits comme des tâches importantes et ouvertes pour lesquelles l'agent peut "nécessiter une révision et une itération humaines significatives". C'est exactement ce que nous avons vu lorsque Sandpack a codé des tests en dur ou lorsque le tableau de bord semblait bon mais ne calculait pas réellement les données.

Donc, en règle générale :

Utilisez Devin pour tout ce qu'un développeur senior pourrait automatiser à l'aide d'un script, et gardez le volant pour les tâches qui nécessitent un sens du produit.

Conclusion

Nous sommes arrivés à la fin de notre tutoriel en quatre parties :

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)

Voici les prochaines étapes à suivre :

1. Hébergez l'API pour que les versions préliminaires (et les futurs utilisateurs) aient accès à un véritable backend.
2. S'assurer que les fonctionnalités de base fonctionnent et corriger les 30 bogues que je sais qu'il y a là.
3. Polir l'interface utilisateur
4. Ajouter du contenu et des exercices
5. Libérez les gens pour qu'ils puissent l'utiliser !

Si vous suivez la même voie, rappelez-vous : vous pouvez laisser l'agent poser le béton, mais c'est à vous de concevoir la maison. Bon codage !