1.8 KiB
Recently resolved (2026-08-19): OPS66 — deadlock de migrations em caminho estático: o deploy buildava o runner antes do migrate e, se uma migration criasse tabela lida em geração estática (caso S2, 2026-08-18: social_feed_settings na home), o next build falhava para sempre (relation ... does not exist) e o migrate nunca rodava — 4 deploys seguidos vermelhos até o migrator manual. Fix em scripts/deploy-homeserver.sh (reordenação de fases, sem custo novo — migrate e build do migrator já rodavam em todo deploy): build do migrator (o estágio não roda next build — builda contra o schema antigo) → push/tag do migrator → swap do compose (backup + trap na mesma posição) → migrate via docker compose run teqo-1313-migrate (caminho canônico do serviço de maintenance, agora com a imagem do SHA novo) → build do runner contra o banco JÁ migrado → push/tag → rollout → healthcheck → smoke. Alternativas rejeitadas: payload migrate dentro do build do runner (efeito colateral de escrita em prod a partir de um processo de build; contraria o desenho deliberado do Dockerfile) e docker run direto do migrator com env-file (duplicaria a definição do serviço de maintenance — caminho paralelo ao canônico). Caveat do rollback ajustado no runbook: migrate antes do build do runner deixa o banco à frente do código se o build falhar depois (mesma classe do caveat atual — migrations append-only e revisadas). Testes: tests/unit/deployScript.unit.spec.ts com pin de ordem completo (migrator build < swap < migrate < runner build < rollout) + invariante novo do Dockerfile (estágio migrator nunca roda next build). Runbook docs/ops/teqo-1313-deploy.md atualizado (fluxo, caveat, falha conhecida nova). Dockerfile/AGENTS.md com a precisão build-after-migrate.