Möchtest du das nicht manuell einrichten? Füge einen Link zu dieser Seite in eine Devin-Sitzung ein und bitte Devin, alles für dich einzurichten. Ein Repository-Skill ist eine Markdown-Datei, die du in `.agents/skills//` 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: ```markdown theme={null} # 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=` (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. 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. 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: ```txt Für Django anpassen theme={null} Schreibe den Migrations-Checklisten-Skill für unser Django-Projekt um: - Scanne Dateien in `apps/*/migrations/` nach destruktiven Operationen wie RemoveField, DeleteModel und AlterField mit Datenverlust - Stelle nach Ausführung von `python manage.py migrate` sicher, dass `python manage.py showmigrations` keine unapplied migrations anzeigt - Führe `python manage.py test --tag=models` aus, um Schemaänderungen zu validieren - Prüfe, dass Migrationen einen `reverse_code` oder ein `RunSQL`-Reverse für sicheres Rollback haben ``` ```txt Für Prisma anpassen theme={null} Schreibe den Migrations-Checklisten-Skill für unser Prisma-Projekt um: - Scanne Dateien in `prisma/migrations/` nach DROP TABLE, DROP COLUMN und ALTER COLUMN, das die Feldbreite reduziert - Führe `npx prisma migrate deploy` gegen die Testdatenbank aus und bestätige, dass der Befehl erfolgreich ist - Führe `npx prisma migrate diff` aus, um zu prüfen, dass schema.prisma dem angewendeten Migrationszustand entspricht - Führe `npm test -- --grep "model"` aus, um fehlerhafte Relationen zu finden ``` 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: ```markdown theme={null} ### 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.

{title}