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.
Busque em todas as páginas da documentação
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.
# 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:
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;"| 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 |
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 ausenteSELECT installed_rank, version, description, success
FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;flyway_schema_history registra a ordem de aplicação em cada ambiente| 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 |
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.
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.
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.
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4, Flyway 10+ e Liquibase 4+.
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026