DB Guard : avant que la migration d’un agent n’atteigne la production

Les fichiers modifiés sous des chemins comme migrations/, prisma/migrations, db/migrate et Flyway V1__x.sql sont examinés. Il lit le SQL pour Postgres, MySQL et SQLite, et le code de migration de Rails, Laravel, Django et des outils de type Knex ou Sequelize.

• DROP TABLE et DROP COLUMN, TRUNCATE, UPDATE et DELETE sans WHERE.
• CREATE INDEX sans CONCURRENTLY, ALTER TYPE, SET NOT NULL, nouvelles contraintes FK, CHECK et UNIQUE.
• Migrations sans étape down ; RunPython sans reverse_code dans Django.
• Niveaux de risque : none, low, medium, high ; la perte de données est signalée séparément.

Choisissez l’une des connexions de votre gestionnaire de base de données comme « proche de la production » et les vrais nombres de lignes sont lus, de sorte que le risque dépend de la taille des tables. Sans connexion, les risques sont évalués sans connaître les tailles. Un risque élevé ou moyen, ou une perte de données, déclenche une notification de bureau.

Chaque rapport propose des boutons pour l’étape suivante.

• Try on shadow DB : exécute la migration sur une connexion de développement ou de staging, dans une transaction toujours annulée.
• Review with Claude : une relecture Claude en lecture seule.
• Have the agent make it safe : les constats vont à l’agent qui a écrit la migration ; s’il n’existe plus, un nouvel agent Claude « DB Guard düzeltme » (correction DB Guard) s’ouvre.
• Analyse SQL : collez un migration.sql de Prisma, la sortie de artisan migrate --pretend ou de manage.py sqlmigrate pour l’analyser.