Pular para o conteúdo principal

Migrations e Seed

TL;DR: num deploy via DevOps, migrations e seed são automáticos no boot do container — você não roda nada à mão. As migrations sempre aplicam; o seed só roda quando HSBR_RUN_SEED=1.

O que acontece no boot do hsbr-back​

O entrypoint do container faz, nesta ordem:

  1. Migrations — npx prisma migrate deploy (a menos que SKIP_MIGRATIONS=1). Aplica as migrations pendentes no banco que você proveu. É engine-aware: escolhe prisma/migrations ou prisma/migrations-sqlserver conforme DB_ENGINE. Uma falha é logada e não derruba o boot (migrate failed — continuing) — então confira os logs.
  2. Seed — se RUN_SEED=1, roda npm run db:seed (idempotente). Se o seed falhar aqui, o boot aborta de propósito (um container saudável sem usuário = 401 no login, o que é pior que falhar visível).
  3. Start do app.

HSBR_RUN_SEED no .env vira RUN_SEED dentro do container (mapeado no docker-compose.yml). Sim, HSBR_RUN_SEED está no .env.example (grupo [D] HSBR BACKEND, default 0).

Migrations — automático, você não precisa rodar​

  • Toda subida/atualização (deploy-stack.sh, update-stack.sh, up-hsbr.sh) reinicia o hsbr-back, e o entrypoint aplica as migrations pendentes. Não há passo manual para um deploy.
  • Não existe verbo de migrate por engine em produção — o migrate deploy já é engine-aware via prisma.config.ts.
  • São duas histórias de migration (Postgres vs SQL Server) — veja Bancos Suportados.
  • Escape hatch: a imagem respeita SKIP_MIGRATIONS=1, mas o compose do DevOps não expõe essa variável — então, num deploy DevOps, as migrations sempre rodam. (Pular só faz sentido num caso raro de banco migrado por fora.)

Seed — controlado por HSBR_RUN_SEED​

HSBR_RUN_SEEDQuando usarEfeito
1primeiro boot de um banco vazioroda db:seed: cria o admin (HSBR_ADMIN_*), o usuário E2E, ativo_status, níveis, processos, produtos, ZPL e as tabelas de EPC <empresa>…
0 (default)depois do primeiro bootnão semeia (não sobrescreve dados)
Banco novo + HSBR_RUN_SEED=0 = login 401

Sem seed, não há usuário admin. No primeiro boot de um tenant novo use HSBR_RUN_SEED=1; depois do boot verde, volte para 0 e re-suba:

# em .env.<grupo>:  HSBR_RUN_SEED=0
./scripts/up-hsbr.sh --env <grupo> --no-build     # ou deploy-stack.sh <grupo>

O seed é idempotente, mas manter 0 evita surpresas em restart. O new-group.sh já gera o .env.<grupo> com HSBR_RUN_SEED=1 para o 1º boot.

Banco da licença (profile license/all)​

A licença tem suas próprias migrations + seed, que não rodam no entrypoint do hsbr-back. Use o verbo manual:

./scripts/migrate.sh --env <env>            # licença: migrate deploy + seed (no license-worker)
./scripts/migrate.sh --env <env> --fresh    # sobe um migrator efêmero (migrate + seed + keygen)

Grupos comerciais (COMPOSE_PROFILES=hsbr) não rodam isto — consomem a licença remota por HTTP.

Verbo manual: migrate.sh​

Profile./scripts/migrate.sh --env X fazFlags
license / allmigrate deploy + seed da licença--fresh (migrator efêmero), --seed-only
hsbrnpm run db:seed no hsbr-back (⚠ pode sobrescrever; pede confirmação)--force (pula a confirmação), --seed-only

Para HSBR o schema do ga6 já é migrado no boot — migrate.sh no profile hsbr serve para (re)semear sob demanda.

Criar NOVAS migrations (desenvolvimento)​

Isso é tarefa de dev no repo do back, não do deploy:

  1. Edite prisma/schema.prisma (canônico).
  2. npm run db:migrate — usa MIGRATE_URL_POSTGRES / MIGRATE_URL_SQLSERVER do .env do back (veja HSBR-Gestao-Ativos-Back/.env.example).
  3. Commite os arquivos gerados em prisma/migrations (+ prisma/migrations-sqlserver).

O deploy depois só aplica o que está commitado. Detalhes em Bancos Suportados.

Resumo​

SituaçãoO que fazer
Deploy / update normalnada — migrate roda no boot
Primeiro boot de tenant novoHSBR_RUN_SEED=1 (depois volte p/ 0)
Re-semear o HSBR./scripts/migrate.sh --env <grupo> --force
Migrar/semear a licença./scripts/migrate.sh --env <env> (ou --fresh)
Pular migrateraro; SKIP_MIGRATIONS=1 não é exposto no compose DevOps