Skip to main content

Impor uma lista de verificação de migração em todos os PRs

Crie uma skill de repositório que faça o Devin identificar operações destrutivas, verificar a segurança de rollback e validar alterações de esquema sempre que um PR envolver migrações de banco de dados.
AuthorCognition
CategoryCore Devin
FeaturesSkills
1

Crie a habilidade de checklist para migração

Uma skill de repositório é um arquivo Markdown que você faz commit em .agents/skills/<your-skill>/ em qualquer um dos seus repositórios. Devin vê todas as skills em todos os repositórios conectados — você pode acioná-las manualmente ou o Devin pode decidir acioná-las automaticamente quando detectar uma situação relevante. Esta skill informa ao Devin exatamente como revisar migrações de banco de dados antes de abrir ou atualizar um PR — identificando erros que a revisão de código normalmente não encontra.Faça commit de .agents/skills/migration-checklist/migration-checklist.md no seu repositório:
# Checklist de Segurança de Migração

## Description
Revise cada migração de banco de dados no PR atual em busca de problemas de segurança
antes de abrir ou atualizar o pull request.

## When to use
Invoque esta skill sempre que o diff do PR incluir arquivos novos ou modificados
em `db/migrate/` (Rails), `migrations/` (Django), ou
`prisma/migrations/` (Prisma).

## Checklist

### 1. Detect destructive operations
Verifique cada arquivo de migração em busca de:
- `DROP TABLE` or `drop_table`
- `DROP COLUMN`, `remove_column`, or column removal
- `TRUNCATE`
- Data-type changes that lose precision (e.g. `text` → `varchar(50)`)

Se algum for encontrado, adicione um comentário no PR sinalizando a operação e
confirmando se existe uma etapa de backup de dados na migração.

### 2. Verify foreign-key indexes
Para cada `add_reference`, `add_foreign_key`, ou nova coluna terminada
em `_id`, confirme se existe um índice correspondente. Caso contrário, adicione um à
migração antes de fazer o commit.

### 3. Check rollback safety
- Execute `bin/rails db:migrate:rollback STEP=<n>` (onde n = número de
  novas migrações) no banco de dados de teste.
- Se o rollback falhar, adicione um método `down` ou bloco reversível e
  tente novamente.
- Relate quaisquer migrações irreversíveis na descrição do PR.

### 4. Validate schema file is up-to-date
Após executar as migrações, compare `db/schema.rb` (ou `structure.sql`)
com a versão no PR. Se diferirem, regenere o arquivo de schema
e inclua-o no commit.

### 5. Run model tests
Execute `bin/rails test test/models/` para identificar validações ou
associações quebradas por alterações no schema. Todos os testes devem passar antes
de o PR ser aberto.
Depois que esse arquivo for incluído em um commit, Devin o verá como uma capacidade disponível. Sempre que uma sessão envolver arquivos de migração neste repositório, Devin poderá acionar a checklist automaticamente — ou você pode invocá-la manualmente a qualquer momento.
2

Veja o gatilho de skill em uma migração real

Quando o Devin trabalha em uma tarefa que adiciona ou modifica um arquivo de migração, ele lê o diff, identifica a skill de checklist de migração e segue o checklist antes de abrir o PR. Veja como isso funciona na prática:
  1. Examina o diff — Devin vê um novo arquivo em db/migrate/ e ativa a skill de checklist de migração
  2. Sinaliza uma operação destrutiva — A migração remove a coluna legacy_email. Devin adiciona um comentário no PR:
    remove_column :users, :legacy_email é uma operação destrutiva. Verificado: a migração inclui uma etapa de backup de dados, copiando os valores para user_archives antes da remoção.
  3. Adiciona um índice ausente — A migração adiciona account_id à tabela invoices, mas não tem índice. Devin acrescenta add_index :invoices, :account_id ao arquivo de migração
  4. Executa o rollback — Devin executa bin/rails db:migrate:rollback STEP=1 no banco de dados de teste. A execução é bem-sucedida
  5. Regenera o schema — Devin executa bin/rails db:schema:dump, detecta um diff em db/schema.rb e inclui o arquivo atualizado no commit
  6. Executa os testes de models — Todos os testes de models passam. Devin abre o PR com um resumo de cada verificação
A descrição do PR inclui um checklist mostrando o que passou e o que o Devin corrigiu, para que revisores possam focar na lógica de negócios em vez da mecânica da migração.
3

Adapte a skill ao seu ORM e stack de tecnologia

A checklist acima é voltada para Rails, mas a mesma estrutura funciona para qualquer ORM. Peça ao Devin para reescrever a skill para o seu stack:
4

Expanda a lista de verificação ao longo do tempo

Cada incidente de migração revela uma lacuna não coberta pela checklist. Depois de cada um deles, adicione uma regra — é só um commit de uma linha no arquivo de skill.Aqui estão algumas adições comuns que as equipes fazem após incidentes reais:
### 6. Aplicar convenções de nomenclatura de migrations
Rejeite migrations que não seguem o padrão
`YYYYMMDDHHMMSS_verb_noun.rb` (ex.: `add_index_to_invoices`).
Renomeie o arquivo se necessário.

### 7. Verificar locks de longa duração
Sinalize qualquer `add_column` em tabelas com >1M de linhas que não use
`disable_ddl_transaction!` (Postgres) ou `ALGORITHM=INPLACE`
(MySQL). Tabelas grandes precisam de migrations sem bloqueio.

### 8. Exigir um teste de migration
Certifique-se de que existe um arquivo de teste correspondente em
`test/migrations/YYYYMMDDHHMMSS_migration_name_test.rb`.
Se estiver ausente, gere um teste esqueleto que execute a migration
up e down.
Como o arquivo de skill fica no seu repositório, essas regras passam por code review — toda a sua equipe concorda com o que será verificado, e isso está sempre alinhado às suas ferramentas de migração.