Skip to main content

Imposer une checklist de migration pour chaque PR

Créez une compétence de dépôt qui permet à Devin d’identifier les opérations destructrices, de vérifier la sécurité des retours arrière et de valider les modifications de schéma chaque fois qu’une PR touche aux migrations de base de données.
AuthorCognition
CategoryCore Devin
FeaturesSkills
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 :
# Liste de contrôle de sécurité des migrations

## Description
Examiner chaque migration de base de données dans la pull request (PR) en cours pour détecter les problèmes de sécurité avant d'ouvrir ou de mettre à jour la pull request.

## Quand l'utiliser
Invoquer cette compétence chaque fois que le diff de la PR inclut des fichiers nouveaux ou modifiés dans `db/migrate/` (Rails), `migrations/` (Django), ou `prisma/migrations/` (Prisma).

## Liste de contrôle

### 1. Détecter les opérations destructives
Analyser chaque fichier de migration à la recherche de :
- `DROP TABLE` ou `drop_table`
- `DROP COLUMN`, `remove_column`, ou suppression de colonne
- `TRUNCATE`
- Changements de type de données entraînant une perte de précision (ex. `text` → `varchar(50)`)

Si l'un d'eux est détecté, ajouter un commentaire sur la PR signalant l'opération et confirmant l'existence d'une étape de sauvegarde des données dans la migration.

### 2. Vérifier les index de clés étrangères
Pour chaque `add_reference`, `add_foreign_key`, ou nouvelle colonne se terminant par `_id`, vérifier qu'un index correspondant existe. Dans le cas contraire, en ajouter un à la migration avant de valider.

### 3. Vérifier la sécurité du rollback
- Exécuter `bin/rails db:migrate:rollback STEP=<n>` (où n = nombre de nouvelles migrations) sur la base de données de test.
- Si le rollback échoue, ajouter une méthode `down` ou un bloc réversible et réessayer.
- Signaler toute migration irréversible dans la description de la PR.

### 4. Vérifier que le fichier de schéma est à jour
Après l'exécution des migrations, comparer `db/schema.rb` (ou `structure.sql`) avec la version présente dans la PR. S'ils diffèrent, régénérer le fichier de schéma et l'inclure dans le commit.

### 5. Exécuter les tests de modèles
Exécuter `bin/rails test test/models/` pour détecter les validations ou associations cassées par les modifications de schéma. Tous les tests doivent passer avant l'ouverture de la PR.
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 :
### 6. Enforce migration naming conventions
Rejeter les migrations qui ne suivent pas le modèle
`YYYYMMDDHHMMSS_verb_noun.rb` (e.g. `add_index_to_invoices`).
Renommer le fichier si nécessaire.

### 7. Check for long-running locks
Signaler tout `add_column` sur des tables avec >1M de lignes qui n'utilise pas
`disable_ddl_transaction!` (Postgres) ou `ALGORITHM=INPLACE`
(MySQL). Les grandes tables nécessitent des migrations non bloquantes.

### 8. Require a migration test
S'assurer qu'un fichier de test correspondant existe à
`test/migrations/YYYYMMDDHHMMSS_migration_name_test.rb`.
S'il est absent, générer un test squelette qui exécute la migration
en montée et en descente.
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.