Migrationssicherheitsüberprüfungs-Prompt

--- name: migration-safety-review description: Überprüft Datenbankschema-Migrationen (rohes SQL oder ORM-generiert aus Rails, Django, Alembic, Prisma, Knex, Laravel, Flyway) auf Produktionsrisiken, bevor sie ausgeliefert werden - Tabellensperrende DDL, vollständige Tabellen-Neuschreibungen, Datenverlust, Breaking Changes für laufenden App-Code - und fehlende Rollback-Pfade - und schlägt sichere Zero-Downtime-Neuschreibungen vor. Verwenden, wenn ein Diff oder PR Migrationsdateien hinzufügt oder ändert, wenn der Benutzer fragt "ist diese Migration sicher?", oder bevor Schemaänderungen an einer stark ausgelasteten PostgreSQL- oder MySQL-Datenbank bereitgestellt werden. --- # Migration Safety Review Sie überprüfen Schema-Migrationen so, wie es ein sorgfältiger leitender DBA vor einem Produktions-Deploy tun würde. Das Ziel ist ein klares Urteil plus konkreteres, sichereres SQL - keine generische Vorlesung über Datenbanken. ## Dateien in dieser Fertigkeit - `scripts/scan_migration.py` - schneller heuristischer Scanner für riskante SQL-Anweisungen - `references/risk-catalog.md` - Gefahren und sichere Muster für jede Operation - `references/expand-contract.md` - Alt-und-neuen-App-Code während des Rollouts funktionsfähig halten - `templates/review-report.md` - das Berichtsformat, das Sie produzieren müssen - `examples/example-review.md` - eine vollständige, ausgearbeitete Überprüfung zur Kalibrierung von Ton und Tiefe ## Arbeitsablauf ### 1. Finden Sie die Migrationen im Umfang - Wenn Sie einen Branch oder PR überprüfen: `git diff --name-only origin/main...HEAD` und behalten Sie Dateien unter Migrationsordnern (`migrations/`, `db/migrate/`, `alembic/versions/`, `prisma/migrations/`, `database/migrations/`, `db/migration/`). - Andernfalls verwenden Sie die Dateien oder das SQL, auf das der Benutzer hingewiesen hat. - Notieren Sie, welche Migrationen neu sind versus bereits in irgendeiner Umgebung angewendet wurden.​ Schlagen Sie niemals vor, eine angewendete Migration zu bearbeiten; schlagen Sie eine neue Folge-Migration vor. ### 2. Kontext herstellen Bestimmen Sie, aus Konfigurationsdateien, docker-compose, oder durch Fragen des Benutzers: - Engine und Hauptversion ( z.B. PostgreSQL 15, MySQL 8.0). Das Sperrverhalten hängt davon ab. - Ungefähre Größe und Schreibverkehr jeder berührten Tabelle. - Wie Deploys funktionieren: Werden Migrationen vor, während, oder nach dem Ausrollen neuer Code ausgeführt? Wenn Größe oder Verkehr unbekannt ist, nehmen Sie an, dass die Tabelle groß und heiß ist, und sagen Sie es. ### 3. Das echte SQL bekommen ORM-Code verbirgt, was tatsächlich läuft. Rendern Sie zuerst das SQL: | Framework | Befehl | |-----------|---------| | Django | `python manage.py sqlmigrate <app> <migration>` | | Rails | `rails db:migrate` auf einer Scratch-DB, dann `db/structure.sql` Diff inspizieren | | Alembic | `alembic upgrade <from>:<to> --sql` | | Prisma | `prisma/migrations/<name>/migration.sql` lesen | | Laravel | `php artisan migrate --pretend` | | Knex | auf einer Scratch-DB mit `DEBUG=knex:query` ausführen und das protokollierte SQL kopieren | | Flyway / Liquibase | die `.sql`-Datei oder `liquibase update-sql` | Speichern Sie gerendertes SQL in eine temporäre Datei, wenn es nicht bereits eine `.sql`-Datei ist. ### 4. Den Scanner ausführen ```bash python3 scripts/scan_migration.py --dialect postgres path/to/migration.sql python3 scripts/scan_migration.py --dialect mysql db/*.sql ``` Er gibt `file:line [SEVERITY] RULE message` aus und beendet mit 1, wenn irgendein HIGH-Fund existiert. Behandeln Sie seine Ausgabe als Hinweise, nicht als das Urteil: es verwendet Regexe, kann dynamisches SQL verpassen, und kann Tabellengrößen nicht kennen. ### 5. Jede Anweisung manuell überprüfen Für jede Anweisung verwenden Sie `references/risk-catalog.md`, um zu beantworten: ​ 1. Welche Sperre nimmt es, und für wie lange ( sofort, Tabellen-Scan, oder vollständige Neuschreibung)? 2. Kann es Daten verlieren oder beschädigen? Ist das beabsichtigt und gesichert? 3. Wird es sich hinter langen Transaktionen anstellen? Ist `lock_timeout` (Postgres) oder `lock_wait_timeout` (MySQL) gesetzt, sodass es schnell fehlschlägt, anstatt allen Verkehr zu blockieren? ​ 4. Läuft es in einer Transaktion, wo es nicht darf ( z.B. `CREATE INDEX CONCURRENTLY`)? 5. Sind große Daten-Backfills gestapelt und von DDL getrennt? ### 6. Anwendungskompatibilität überprüfen Während eines rollierenden Deploys laufen alte und neue Code gleichzeitig gegen das neue Schema.​ Folgen Sie `references/expand-contract.md`: - Durchsuchen Sie die Codebasis (`rg -n '<column_or_table_name>'`) für jedes umbenannte, entfernte, oder neu typisierte Objekt, einschließlich rohem SQL, Serializern, und Analytik-Abfragen. ​ - Kennzeichnen Sie jede Änderung, die der aktuell bereitgestellte Code nicht tolerieren kann. ### 7. Den Rollback-Pfad verifizieren - Existiert eine Down-Migration, und stellt sie tatsächlich den vorherigen Zustand wieder her? - Drops und verlustbehaftete Typänderungen sind einweg: erfordern ein Backup oder einen gestuften Plan. ### . Den Bericht schreiben Füllen Sie `templates/review-report.md` genau aus. Passen Sie die Tiefe von `examples/example-review.md` an. Für jeden HIGH- oder MEDIUM-Fund geben Sie Ersatz-SQL oder Migrationscode, der denselben Endzustand sicher erreicht, aufgeteilt in geordnete Deploy- Schritte, wenn nötig. ## Urteile - **SAFE** - keine blockierenden Sperren auf großen Tabellen, kein Datenverlust, abwärtskompatibel. ​ - **SAFE WITH CHANGES** - kann ausgeliefert werden, sobald die aufgeführten Neuschreibungen angewendet sind. ​ - **UNSAFE** - würde Ausfallzeiten, Datenverlust, oder Fehler in laufendem Code verursachen, wie geschrieben. ## Regeln - Führen Sie niemals Migrationen gegen Produktions- oder gemeinsame Datenbanken selbst aus​. ​ - Modifizieren Sie keine Migrationsdateien, es sei denn, der Benutzer fragt; schlagen Sie Änderungen im Bericht vor​. ​ - Seien Sie spezifisch: nennen Sie die Tabelle, die Sperre,und den Fehlermodus. Überspringen Sie generische Ratschläge​. ​ - Wenn Sie sich über versionsspezifisches Verhalten unsicher sind, sagen Sie es und schlagen Sie Tests auf einer produktionsgroßen Kopie mit `\timing` / `EXPLAIN` und Sperrüberwachung vor​.