Skip to main content
Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous.
1

Créer la compétence « liste de contrôle de migration »

Une compétence de dépôt est un fichier Markdown que vous validez dans .agents/skills/<your-skill>/ dans l’un de vos dépôts. Devin voit toutes les compétences sur l’ensemble des dépôts connectés — vous pouvez les déclencher manuellement, ou Devin peut choisir de les déclencher automatiquement lorsqu’il détecte une situation pertinente. Cette compétence indique à Devin exactement comment relire les migrations de base de données avant d’ouvrir ou de mettre à jour une pull request (PR) — en détectant les erreurs que la revue de code ne repère généralement pas.Validez .agents/skills/migration-checklist/migration-checklist.md dans votre dépôt :
Une fois ce fichier validé, Devin le considère comme une compétence disponible. Dès qu’une session interagit avec des fichiers de migration dans ce dépôt, Devin peut déclencher automatiquement la checklist — ou vous pouvez l’invoquer manuellement à tout moment.
2

Voir le déclenchement d’une compétence lors d’une migration réelle

Lorsque Devin travaille sur une tâche qui ajoute ou modifie un fichier de migration, il lit le diff, fait appel à la compétence de liste de contrôle de migration et suit cette liste de contrôle avant d’ouvrir la pull request (PR). Voici à quoi cela ressemble en pratique :
  1. Analyse le diff — Devin voit un nouveau fichier dans db/migrate/ et active la compétence de liste de contrôle de migration
  2. Signale une opération destructrice — La migration supprime une colonne legacy_email. Devin ajoute un commentaire sur la PR :
    remove_column :users, :legacy_email est une opération destructive. Vérifié : la migration inclut une étape de sauvegarde des données qui copie les valeurs vers user_archives avant la suppression.
  3. Ajoute un index manquant — La migration ajoute account_id à la table invoices mais sans index. Devin ajoute add_index :invoices, :account_id au fichier de migration
  4. Lance un rollback — Devin exécute bin/rails db:migrate:rollback STEP=1 sur la base de données de test. L’opération réussit
  5. Régénère le schéma — Devin lance bin/rails db:schema:dump, détecte un diff dans db/schema.rb et inclut le fichier mis à jour dans le commit
  6. Lance les tests de modèles — Tous les tests de modèles réussissent. Devin ouvre la PR avec un récapitulatif de chaque vérification
La description de la PR inclut une liste de contrôle indiquant ce qui a réussi et ce que Devin a corrigé, afin que les relecteurs puissent se concentrer sur la logique métier plutôt que sur la mécanique de migration.
3

Adaptez ce skill à votre ORM et à votre stack

La checklist ci-dessus cible Rails, mais la même structure fonctionne pour n’importe quel ORM. Demandez à Devin de réécrire la compétence pour votre stack :
4

Faites évoluer la liste de contrôle au fil du temps

Chaque incident de migration révèle une lacune que la checklist ne prend pas en compte. Après chaque incident, ajoutez une règle — c’est un commit d’une ligne dans le fichier de skill.Voici des ajouts courants que les équipes effectuent après de vrais incidents :
Comme le fichier de compétence se trouve dans votre dépôt, ces règles passent par la revue de code : toute votre équipe s’accorde sur ce qui est contrôlé, et elles restent toujours synchronisées avec vos outils de migration.