cferraz/adaptador-planilhas

0 Fork 0

Files

T

camilafagundesandClaude Opus 5 5b11496cd9

ci / lint, typecheck, testes e build (push) Has been cancelled

Details

ci / Postgres e Redis reais (push) Has been cancelled

Details

ci / imagem Docker Linux (push) Has been cancelled

Details

Runbook único de homologação, checklist de evidências e ADR do ambiente

Havia dois runbooks sobrepostos, escritos para o piloto, e nenhum documento do
ambiente de homologação.

- `20-homologacao-runbook.md` consolida os dois e cobre DNS, TLS, Nginx,
  Supabase de homologação, banco com a decisão do shim, bucket privado,
  containers, worker, observabilidade, flag, rollback, diagnóstico e smoke.
  Os dois runbooks antigos ficam no repositório marcados como histórico,
  preservando o registro das decisões.
- Rollback de imagem com comandos: identificar o que está no ar, listar tags,
  desligar a flag antes de trocar, subir só web e worker com `--no-deps`,
  conferir saúde, religar a flag. As migrations de segurança — RLS e auditoria
  append-only — estão declaradas sem caminho de volta: desfazê-las afrouxa o
  isolamento entre workspaces, então um rollback que precise disso está errado
  por definição.
- `21-checklist-validacao.md` separa o que foi executado do que depende de
  infraestrutura, com a evidência de cada item e a tabela dos quatro defeitos
  encontrados. Nada está marcado PASS por inspeção de código.
- ADR 0007 registra o ambiente lógico e a autenticação de homologação, com as
  alternativas descartadas e o motivo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-15 20:40:08 -03:00

2.3 KiB

Raw Blame History

Runbook de implantação do piloto

Histórico. Este runbook foi escrito para o piloto, antes do ambiente de homologação existir. Não siga este arquivo. O procedimento vigente está em 20-homologacao-runbook.md, que consolida este e o 16-pilot-deployment-runbook.md. Mantido para registro das decisões.

Execute nesta ordem. Não apague auditoria, banco ou arquivos como parte do rollback.

Preparar o projeto Supabase da Elo Pro e anotar URL, anon key e service role.
Validar que o login Elo Pro emite sessão Supabase e o cookie elo_pro_workspace_id.
Conferir se profiles, workspaces e workspace_members já existem. Se existirem com outro formato, não aplique 0001_platform_shim.sql. Aplique só 0002, 0003 e 0004 depois de adaptar identity-port.ts.
Validar RLS no papel app_user: um usuário não lê modelo de outro workspace.
Criar o bucket privado. Não gerar URL pública.
Subir Redis e preencher REDIS_URL.
Definir ADAPTER_JOB_MODE=worker.
Preencher os secrets da tabela em 15-production-environment.md. Não definir ADAPTER_DEV_AUTH nem o segredo de desenvolvimento.
Definir SPREADSHEET_TEMP_TTL_SECONDS com o prazo operacional do piloto.
Preencher SENTRY_DSN. Confirmar que o evento de teste não contém célula.
Rodar npm run migrate no banco já conferido.
Iniciar a web com npm run start.
Iniciar npm run worker com as mesmas variáveis.
GET /api/health/live deve responder live. GET /api/health/ready deve responder ready sem connection string.
Executar o smoke do caminho completo no ambiente real (SMOKE_REAL ainda não está automatizado contra o host; percorrer a jornada na interface).
Ativar a flag só no workspace piloto: npm run flag -- <workspace_id> on.
Verificar logs do worker: nome do erro e código, sem planilha.
Processar um arquivo pequeno de ponta a ponta e baixar XLSX, CSV e PDF.

Rollback

npm run flag -- <workspace_id> off.
Parar o processo do worker.
Manter audit_log, modelos e o banco.
Não rodar script que apague storage ou tabelas.
Se o deploy em si estiver incorreto, promover de volta o artefato anterior depois da flag desligada.

A última ativação do módulo fica no checklist de 18-pilot-final-gate.md.

2.3 KiB Raw Blame History

Runbook de implantação do piloto

Rollback

2.3 KiB

Raw Blame History