Skip to main content

Eine Migrations-Checkliste für jeden PR erzwingen

Erstelle eine Repo-Skill, mit der Devin destruktive Operationen erkennt, die Rollback-Sicherheit überprüft und Schemaänderungen validiert, sobald ein Pull-Request (PR) Datenbankmigrationen umfasst.
AuthorCognition
CategoryCore Devin
FeaturesSkills
1

Skill „Migrations-Checkliste“ erstellen

Ein Repository-Skill ist eine Markdown-Datei, die du in .agents/skills/<your-skill>/ in eines deiner Repositories committest. Devin erkennt alle Skills in allen verbundenen Repositories – du kannst sie manuell auslösen oder Devin kann sie automatisch auslösen, wenn eine relevante Situation erkannt wird. Dieser Skill weist Devin genau an, wie Datenbank-Migrationen vor dem Öffnen oder Aktualisieren eines Pull-Requests (PR) zu prüfen sind – und fängt dabei Fehler ab, die im Code-Review normalerweise übersehen werden.Committe .agents/skills/migration-checklist/migration-checklist.md in deinem Repository:
# Migrations-Sicherheitscheckliste

## Beschreibung
Überprüfe jede Datenbankmigration im aktuellen PR auf Sicherheitsprobleme,
bevor der Pull Request geöffnet oder aktualisiert wird.

## Verwendung
Verwende diese Skill, wenn der PR-Diff neue oder geänderte Dateien
in `db/migrate/` (Rails), `migrations/` (Django) oder
`prisma/migrations/` (Prisma) enthält.

## Checkliste

### 1. Destruktive Operationen erkennen
Durchsuche jede Migrationsdatei nach:
- `DROP TABLE` oder `drop_table`
- `DROP COLUMN`, `remove_column` oder das Entfernen von Spalten
- `TRUNCATE`
- Datentypänderungen mit Präzisionsverlust (z. B. `text` → `varchar(50)`)

Falls solche gefunden werden, füge einen PR-Kommentar hinzu, der die Operation markiert und
bestätigt, ob ein Datensicherungsschritt in der Migration vorhanden ist.

### 2. Fremdschlüssel-Indizes überprüfen
Stelle für jedes `add_reference`, `add_foreign_key` oder jede neue Spalte, die
auf `_id` endet, sicher, dass ein passender Index vorhanden ist. Falls nicht, füge einen zur
Migration hinzu, bevor du committest.

### 3. Rollback-Sicherheit prüfen
- Führe `bin/rails db:migrate:rollback STEP=<n>` (wobei n = Anzahl der
  neuen Migrationen) gegen die Testdatenbank aus.
- Falls der Rollback fehlschlägt, füge eine `down`-Methode oder einen reversiblen Block hinzu und
  versuche es erneut.
- Dokumentiere nicht umkehrbare Migrationen in der PR-Beschreibung.

### 4. Schema-Datei auf Aktualität prüfen
Vergleiche nach dem Ausführen der Migrationen `db/schema.rb` (oder `structure.sql`)
mit der Version im PR. Falls sie voneinander abweichen, generiere die Schema-Datei neu
und füge sie dem Commit hinzu.

### 5. Modelltests ausführen
Führe `bin/rails test test/models/` aus, um Validierungen oder
Assoziationen zu erkennen, die durch Schemaänderungen fehlschlagen. Alle Tests müssen bestehen, bevor
der PR geöffnet wird.
Sobald diese Datei committed ist, betrachtet Devin sie als verfügbare Fähigkeit. Immer wenn eine Sitzung in diesem Repository Migrationsdateien berührt, kann Devin die Checkliste automatisch ausführen – oder Sie können sie jederzeit manuell aufrufen.
2

Sehen Sie den Skill-Trigger in einer realen Migration

Wenn Devin an einer Aufgabe arbeitet, die eine Migrationsdatei hinzufügt oder ändert, liest es das Diff, erkennt den Migrations-Checklisten-Skill und folgt der Checkliste, bevor es den PR öffnet. So sieht das in der Praxis aus:
  1. Scannt das Diff — Devin erkennt eine neue Datei in db/migrate/ und aktiviert den Migrations-Checklisten-Skill
  2. Markiert eine destruktive Operation — Die Migration entfernt eine legacy_email-Spalte. Devin fügt einen PR-Kommentar hinzu:
    remove_column :users, :legacy_email ist eine destruktive Operation. Verifiziert: Die Migration enthält einen Datensicherungsschritt, der Werte vor der Entfernung nach user_archives kopiert.
  3. Fügt einen fehlenden Index hinzu — Die Migration fügt account_id zur invoices-Tabelle hinzu, hat aber keinen Index. Devin hängt add_index :invoices, :account_id an die Migrationsdatei an
  4. Führt Rollback aus — Devin führt bin/rails db:migrate:rollback STEP=1 auf der Testdatenbank aus. Der Befehl läuft erfolgreich durch
  5. Regeneriert das Schema — Devin führt bin/rails db:schema:dump aus, erkennt ein Diff in db/schema.rb und nimmt die aktualisierte Datei in den Commit auf
  6. Führt Model-Tests aus — Alle Model-Tests bestehen. Devin öffnet den PR mit einer Zusammenfassung jedes Checks
Die PR-Beschreibung enthält eine Checkliste, die zeigt, welche Checks bestanden wurden und was Devin behoben hat, sodass Reviewer sich auf die Business-Logik statt auf die Migrationsmechanik konzentrieren können.
3

Passen Sie den Skill an Ihr ORM und Ihren Stack an

Die obige Checkliste richtet sich an Rails, aber die gleiche Struktur funktioniert für jedes ORM. Bitte Devin, den Skill für deinen Stack neu zu schreiben:
4

Checkliste im Laufe der Zeit erweitern

Jeder Migrationsvorfall offenbart eine Lücke, die die Checkliste nicht abgedeckt hat. Nach jedem fügen Sie eine Regel hinzu – das ist ein Einzeilen-Commit in der Skill-Datei.Hier sind typische Ergänzungen, die Teams nach realen Vorfällen vornehmen:
### 6. Enforce migration naming conventions
Reject migrations that don't follow the pattern
`YYYYMMDDHHMMSS_verb_noun.rb` (e.g. `add_index_to_invoices`).
Rename the file if needed.

### 7. Check for long-running locks
Flag any `add_column` on tables with >1M rows that doesn't use
`disable_ddl_transaction!` (Postgres) or `ALGORITHM=INPLACE`
(MySQL). Large tables need non-blocking migrations.

### 8. Require a migration test
Ensure a corresponding test file exists at
`test/migrations/YYYYMMDDHHMMSS_migration_name_test.rb`.
If missing, generate a skeleton test that runs the migration
up and down.
Da sich die Skill-Datei in eurem Repo befindet, durchlaufen diese Regeln das Code-Review – euer gesamtes Team stimmt zu, was geprüft wird, und sie sind immer mit eurem Migrationstooling synchronisiert.