Pular para conteúdo

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

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-15 · 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.onpetro.xadm.biz"],
  "glitchtip": { "org": "x-adm", "project": "bi-comercial-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. O app está em canário 50/50 (excel-native dono do principal + excel.onpetro-jar-pull), e o principal é o que o cliente usa — é lá que a entrega tem de estar de pé. Consequência declarada: com o split, uma sonda pode cair no par que ainda não trocou; o retry mitiga, e a alternativa (declarar os dois fqdn próprios) prova cada metade mas deixa de provar o que o cliente vê. Cabe revisitar quando o ratio for medível.
  • Só /health nesta onda. É a camada 2 no seu mínimo honesto. Ampliar a lista exige conferir cada rota contra o intercept-url-map (/swagger/**, /public/**, /css/**, /xls/** são anônimas; /admin/** e /api/comercial/** não) — e a norma é explícita sobre o custo de errar: class que mente arma bomba de efeito retardado, e rota protegida declarada public reprova por motivo errado. Cresce app a app, com o manifesto conferido.
  • session/m2m ficam para depois. O seam POST /smoke/session exige xadm-seguranca ≥ 0.7.1 (aqui é 0.7.2 desde a migração da constituição 1.4.8 — o que falta é o resto) mais SMOKE_TOKEN no secret e a property smoke.token no recurso Coolify. Sem os três, rota session vira asserção negativa — não é o que se quer estrear.

Correção (2026-09-15): o manifesto declara uma rota de cada classe de credencial, como a norma de smoke passou a exigir (guarda Classe servida sem rota no smoke do pipeline.yml): GET /api/comercial/processamentos (m2m) e GET /processamentos (session), além do /health. O bases segue o fqdn principal, agora sem canário (deploy só native). O que liga as duas rotas está em Deploy: SMOKE_TOKEN no recurso e nos secrets, SMOKE_M2M_TOKEN nos secrets.

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.7.1 → 0.9.0, que é quem emite o commit no /health e resolve o release do GlitchTip a partir de XADM_COMMIT. Sem o bump, a camada 1 degrada para versao e o rollback fica sem alvo — o job falharia dizendo isso.
  • 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.