Pular para conteúdo

0029 — Adota o smoke de produção pós-deploy

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-09 · Decidido em: 2026-09-09

Contexto

Este RD não decide nada novo: o smoke pós-deploy é norma da casa (constituição §9, ADR central 0031, página smoke-producao). O que faltava aqui era o rastro local — o que este app declarou como crítico, e por quê.

O problema alcança este repo em cheio: o POST /api/ci/deploy é assíncrono, então o pipeline ficava verde antes de o container novo servir. E /health verde é liveness — prova que o processo subiu e o Flyway passou, não que o app responde o que deveria. A frota já entregou, com o container healthy, tela nova em 500 e <APP>_API_TOKEN ausente que só apareceu como 401 no cliente.

Decisão

Adota o smoke declarando o manifesto no docs/app.json:

"smoke": {
  "bases": ["https://excel.vantroba.xadm.biz"],
  "glitchtip": { "org": "x-adm", "project": "bi-transporte-xls" },
  "routes": [ { "path": "/health", "class": "public", "status": 200 } ]
}

Três escolhas locais, com o porquê:

  • bases é o fqdn PRINCIPAL, não os dois próprios. Canário 50/50 (excel-native.vantroba dono do principal + excel.vantroba-jar-pull): o principal é o que o cliente usa. Ponto cego declarado: com o split, uma sonda pode cair no par que ainda não trocou — o retry mitiga.
  • Só /health nesta onda. Camada 2 no mínimo honesto. Ampliar exige conferir cada rota contra o intercept-url-map deste app (anônimas: /health, /swagger/**, /public/**, /css/**, /images/**; o resto exige sessão). class que mente é o defeito caro que a norma descreve.
  • session/m2m ficam para depois. O seam exige xadm-seguranca ≥ 0.7.1 (aqui 0.6.0), SMOKE_TOKEN no secret e a property smoke.token no recurso Coolify.

Consequências

  • GLITCHTIP_API_TOKEN (read-only) é obrigatório nos secrets do repo no GitHub. Declarar smoke.glitchtip sem o secret REPROVA o smoke — é defeito de configuração, não degradação: sem ele a camada 3 não roda e o job ficaria "verde provando 3 de 4".
  • Bump xadm-comum-web 0.6.1 → 0.9.0, que é quem emite o commit no /health e resolve o release do GlitchTip a partir de XADM_COMMIT. Sem ele a camada 1 degrada para versao e o rollback fica sem alvo. O bump traz junto o flavor no /health (0.7.0) e o 404 autenticado vai a ERROR (0.7.1) — este último aumenta o volume no GlitchTip de propósito: é o sinal que pegou rota podada pelo AOT em produção.
  • O commit do /health passa a ser o discriminador de entrega: XADM_COMMIT entra como build-arg no pipeline e vira ARG/ENV tarde no Dockerfile (declarado no topo, invalidaria o cache de toda camada abaixo a cada commit). Um identificador só atravessa pipeline, imagem, /health e tag imutável.
  • Reprovar reverte para <imagem>:<sha anterior>-<target> e confirma a reversão repolando o /health. Isso torna a tag imutável um ativo operacional: podar a tag que está no /health de um recurso em produção transforma o rollback em "não confirmado" no pior momento.
  • Este RD é ponteiro: divergência de mérito sobre o mecanismo se resolve no ADR central 0031, não aqui. O que se decide localmente é o manifesto — quais rotas não podem quebrar.