Skip to main content

Applicare una checklist di migrazione a ogni PR

Crea una skill del repository che permetta a Devin di individuare operazioni distruttive, verificare la sicurezza del rollback e convalidare le modifiche allo schema ogni volta che una PR tocca le migrazioni del database.
AuthorCognition
CategoryCore Devin
FeaturesSkills
1

Crea la skill per la checklist di migrazione

Una repository skill è un file markdown che esegui il commit in .agents/skills/<your-skill>/ in uno qualsiasi dei tuoi repository. Devin vede tutte le skill presenti in tutti i repository collegati: puoi attivarle manualmente oppure Devin può decidere di attivarle automaticamente quando rileva una situazione rilevante. Questa skill indica a Devin esattamente come revisionare le migrazioni del database prima di aprire o aggiornare una pull request (PR), intercettando gli errori che di solito sfuggono alla code review.Esegui il commit di .agents/skills/migration-checklist/migration-checklist.md nel tuo repository:
# Migration Safety Checklist

## Description
Review every database migration in the current PR for safety issues
before opening or updating the pull request.

## When to use
Invoke this skill whenever the PR diff includes new or modified files
in `db/migrate/` (Rails), `migrations/` (Django), or
`prisma/migrations/` (Prisma).

## Checklist

### 1. Detect destructive operations
Scan each migration file for:
- `DROP TABLE` or `drop_table`
- `DROP COLUMN`, `remove_column`, or column removal
- `TRUNCATE`
- Data-type changes that lose precision (e.g. `text` → `varchar(50)`)

If any are found, add a PR comment flagging the operation and
confirming whether a data backup step exists in the migration.

### 2. Verify foreign-key indexes
For every `add_reference`, `add_foreign_key`, or new column ending
in `_id`, confirm a matching index exists. If not, add one to the
migration before committing.

### 3. Check rollback safety
- Run `bin/rails db:migrate:rollback STEP=<n>` (where n = number of
  new migrations) against the test database.
- If rollback fails, add a `down` method or reversible block and
  retry.
- Report any irreversible migrations in the PR description.

### 4. Validate schema file is up-to-date
After running migrations, diff `db/schema.rb` (or `structure.sql`)
against the version in the PR. If they differ, regenerate the schema
file and include it in the commit.

### 5. Run model tests
Execute `bin/rails test test/models/` to catch validations or
associations broken by schema changes. All tests must pass before
the PR is opened.
Una volta eseguito il commit di questo file, Devin lo considera una skill disponibile. Ogni volta che una sessione coinvolge file di migrazione in questa repository, Devin può attivare automaticamente la checklist — oppure puoi richiamarla manualmente in qualsiasi momento.
2

Vedi come si attiva la skill in una migrazione reale

Quando Devin lavora a un task che aggiunge o modifica un file di migration, legge il diff, associa la skill migration checklist e segue la checklist prima di aprire la PR. Ecco come avviene in pratica:
  1. Analizza il diff — Devin vede un nuovo file in db/migrate/ e attiva la skill migration checklist
  2. Contrassegna un’operazione distruttiva — La migration rimuove la colonna legacy_email. Devin aggiunge un commento alla PR:
    remove_column :users, :legacy_email è un’operazione distruttiva. Verificato: la migration include uno step di backup dei dati che copia i valori in user_archives prima della rimozione.
  3. Aggiunge un indice mancante — La migration aggiunge account_id alla tabella invoices ma non prevede alcun indice. Devin aggiunge add_index :invoices, :account_id al file di migration
  4. Esegue il rollback — Devin esegue bin/rails db:migrate:rollback STEP=1 sul database di test, che va a buon fine
  5. Rigenera lo schema — Devin esegue bin/rails db:schema:dump, rileva un diff in db/schema.rb e include il file aggiornato nel commit
  6. Esegue i test dei modelli — Tutti i test dei modelli passano. Devin apre la PR con un riepilogo di ogni controllo
La descrizione della PR include una checklist che mostra quali controlli sono passati e cosa Devin ha corretto, così i revisori possono concentrarsi sulla business logic invece che sulla meccanica della migration.
3

Adatta la skill al tuo ORM e stack tecnologico

La checklist sopra è pensata per Rails, ma la stessa struttura funziona con qualsiasi ORM. Chiedi a Devin di riscrivere la skill per il tuo stack:
4

Amplia la checklist nel tempo

Ogni incidente di migrazione rivela una lacuna che la checklist non copre. Dopo ognuno, aggiungi una regola: basta un commit di una riga al file delle skill.Ecco le aggiunte più comuni che i team fanno dopo incidenti reali:
### 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.
Poiché il file delle skill si trova nel tuo repository, queste regole passano attraverso la code review — tutto il team è allineato su ciò che viene verificato e rimane sempre in sincronia con i tuoi strumenti di migrazione.