Noções Básicas de Git para Trabalho com Banco de Dados
Um guia para migrações SQL em git com revisão de PR em equipes PostgreSQL 18.4 - layout de pastas, política de branches e coordenação com a ordem de deploy da aplicação.
Receita
# Trabalho diário de migração
git checkout main && git pull --ff-only
git checkout -b feat/DB-128-add-orders-priority
# editar db/migrations/V20260709_128__orders_priority.sql
git add db/migrations/
git commit -m "feat(db): add orders.priority column [DB-128]"
git push -u origin feat/DB-128-add-orders-priority
# Abrir PR com seções EXPLAIN + rollback preenchidasdb/
├── migrations/
│ ├── V20260701_100__baseline.sql
│ ├── V20260709_128__orders_priority.sql
│ └── R__views.sql # repetível (Flyway)
├── rollback/
│ └── V20260709_128__orders_priority_down.sql
└── seeds/
└── dev_fixtures.sqlQuando usar este guia:
- Qualquer alteração de esquema é enviada via CI, não psql manual em produção
- Múltiplos serviços compartilham o mesmo esquema de banco de dados
- Auditoria requer vinculação de DDL a ticket e revisor
Exemplo de Trabalho
Passo 1 - Arquivo de migração com metadados
-- V20260709_128__orders_priority.sql
-- Ticket: DB-128
-- Risco de bloqueio: médio (índice CONCURRENTLY em arquivo separado)
-- Deploy: antes de orders-api v2.7.0
ALTER TABLE orders ADD COLUMN IF NOT EXISTS priority text NOT NULL DEFAULT 'normal';Passo 2 - Migração de índice concorrente separada
-- V20260709_129__orders_priority_index.sql
-- executeInTransaction=false (Flyway)
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_priority ON orders (priority);Passo 3 - Checklist do template de PR
## PR de Banco de Dados
- [ ] Migração flyway em staging aplicada
- [ ] Consulta de monitoramento de bloqueio executada durante a migração
- [ ] SQL de rollback vinculado
- [ ] Ordem de deploy da aplicação documentada (migração antes do código)
- [ ] EXPLAIN anexado se for alteração de consulta/índicePasso 4 - Job de migração da CI
# .github/workflows/db-migrate-staging.yml
- run: flyway -url="${{ secrets.STAGING_JDBC }}" migrate
- run: psql "$STAGING_URL" -c "SELECT version, success FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 3;"Aprofundamento
Política de Branches
| Branch | Propósito | Regra de Migração |
|---|---|---|
main | Integração | Apenas migrações forward que passaram em staging |
feat/* | Feature de Esquema | Um ticket por série de migrações |
hotfix/* | Correção de Produção | Cherry-pick da migração para main no mesmo dia |
Ordem de Deploy
Correto: merge da migração → migração staging → migração prod → deploy da aplicação
Errado: deploy da aplicação primeiro → código espera coluna ausenteTabela de Histórico vs Git
SELECT installed_rank, version, description, success
FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;- Git registra a intenção;
flyway_schema_historyregistra a ordem de aplicação em cada ambiente - Detecção de drift: comparação de esquema staging vs prod após deploy falho
Armadilhas
- Editar arquivos de migração mesclados - falha de checksum em outros ambientes. Correção: apenas nova migração forward.
- Squash de migrações após aplicação em produção - quebra o histórico. Correção: fazer squash apenas de baselines pré-produção.
- DDL manual em produção sem commit - git não corresponde mais à produção. Correção: script de emergência ainda commitado em branch hotfix em até 24h.
- Grandes dumps binários no git - usar armazenamento de objetos para dados, apenas migrações SQL para esquema.
- DB compartilhado entre serviços - dois PRs colidem na versão da migração. Correção: alocador serial de versão de migração ou fila central de DBA.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Changelogs do Liquibase | Padrão da loja XML/YAML | Equipe prefere SQL puro |
| Auto-migração ORM (apenas dev) | Protótipo local | Produção |
| Banco de dados por serviço | Velocidade de migração independente | Esquema monolítico |
FAQs
Apenas migrações forward ou down?
Muitas equipes usam apenas forward em produção com SQL de rollback documentado em db/rollback/ não aplicado automaticamente. Escolha a política no ADR; seja consistente.
Quem é o dono dos números de versão das migrações?
O DBA da plataforma ou um bot atribui o próximo VYYYYMMDD_NNN para evitar colisões. Nunca reutilize uma versão após o merge.
Monorepo: migrações no repo da aplicação ou no repo da plataforma?
Esquema único: um caminho de repo de migrações. Banco de dados por serviço: migrações ao lado de cada serviço. Documentar em CONTRIBUTING.md.
Relacionados
- Revisão de Código para SQL - Evidência de PR
- Melhores Práticas de Git - Resumo de 25 itens
- Noções Básicas de Migrações - Configuração do runner
- Flyway e Liquibase - Ferramentas
- Skill de Segurança de Migração - Pontuação de bloqueio
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4, Flyway 10+ e Liquibase 4+.