Deploy no migrator
A imagem do migrator é o passo de deploy do banco; a API e os workers esperam por ele sozinhos.
A imagem migrator é o passo de deploy do banco. O comando padrão dela é:
bun src/main.ts deploydeploy aplica as migrations pendentes do baseline sob um advisory lock e depois roda os seeders padrão
numa transação. Rodar deploy de novo num banco em dia não muda nada.
| Comando | O que faz |
|---|---|
bun src/main.ts deploy | Migrations e seeders padrão (o padrão da imagem) |
bun src/main.ts apply | Só as migrations |
bun src/main.ts status | Lista o estado das migrations |
bun src/db-seed.ts | Só os seeders |
Onde ele roda
- Compose (
compose.yaml): o serviçomigratorroda a cadaup; a API e os workers só sobem depois que ele termina com sucesso. - Fora do Compose: rode a imagem uma vez por versão, antes da API e dos workers.
- Staging (Dokploy): o migrator é uma aplicação one-shot. Ver Staging no Dokploy.
O portão de prontidão
A API e os workers não confiam na ordem de deploy. As imagens carregam o nome da migration mais nova do próprio build
(/app/contracts/schema-version.json, apontado por MONALISA_SCHEMA_VERSION):
- a API responde
GET /readycom 503 e a migration pendente até o banco conter essa migration; - os workers não ficam prontos nem consomem até lá.
As duas respostas de /ready trazem latestMigration, que o deploy de staging usa para confirmar que a versão nova
está no ar. Assim uma API ou um worker novo nunca serve sobre um schema antigo, mesmo quando sobe antes do migrator.
Artefatos gerados no build
openapi.json, permissions.json, tasks.json e schema-version.json são gerados a partir do código e nunca
commitados. As imagens os recebem num estágio do build: um emit que falha (regra de rota quebrada, registry de
permissões inválido, unidade de trabalho não descoberta) falha o build da imagem. O migrator recebe o
permissions.json emitido pelo mesmo build.