camilafagundesandClaude Opus 5
5b11496cd9
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>
2.3 KiB
2.3 KiB
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 o16-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,workspaceseworkspace_membersjá existem. Se existirem com outro formato, não aplique0001_platform_shim.sql. Aplique só0002,0003e0004depois de adaptaridentity-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 definirADAPTER_DEV_AUTHnem o segredo de desenvolvimento. - Definir
SPREADSHEET_TEMP_TTL_SECONDScom o prazo operacional do piloto. - Preencher
SENTRY_DSN. Confirmar que o evento de teste não contém célula. - Rodar
npm run migrateno banco já conferido. - Iniciar a web com
npm run start. - Iniciar
npm run workercom as mesmas variáveis. GET /api/health/livedeve responderlive.GET /api/health/readydeve responderreadysem connection string.- Executar o smoke do caminho completo no ambiente real (
SMOKE_REALainda 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.