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>
39 lines
2.3 KiB
Markdown
39 lines
2.3 KiB
Markdown
# 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`](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.
|
|
|
|
1. Preparar o projeto Supabase da Elo Pro e anotar URL, anon key e service role.
|
|
2. Validar que o login Elo Pro emite sessão Supabase e o cookie `elo_pro_workspace_id`.
|
|
3. 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`.
|
|
4. Validar RLS no papel `app_user`: um usuário não lê modelo de outro workspace.
|
|
5. Criar o bucket privado. Não gerar URL pública.
|
|
6. Subir Redis e preencher `REDIS_URL`.
|
|
7. Definir `ADAPTER_JOB_MODE=worker`.
|
|
8. Preencher os secrets da tabela em `15-production-environment.md`. Não definir `ADAPTER_DEV_AUTH` nem o segredo de desenvolvimento.
|
|
9. Definir `SPREADSHEET_TEMP_TTL_SECONDS` com o prazo operacional do piloto.
|
|
10. Preencher `SENTRY_DSN`. Confirmar que o evento de teste não contém célula.
|
|
11. Rodar `npm run migrate` no banco já conferido.
|
|
12. Iniciar a web com `npm run start`.
|
|
13. Iniciar `npm run worker` com as mesmas variáveis.
|
|
14. `GET /api/health/live` deve responder `live`. `GET /api/health/ready` deve responder `ready` sem connection string.
|
|
15. Executar o smoke do caminho completo no ambiente real (`SMOKE_REAL` ainda não está automatizado contra o host; percorrer a jornada na interface).
|
|
16. Ativar a flag só no workspace piloto: `npm run flag -- <workspace_id> on`.
|
|
17. Verificar logs do worker: nome do erro e código, sem planilha.
|
|
18. Processar um arquivo pequeno de ponta a ponta e baixar XLSX, CSV e PDF.
|
|
|
|
## Rollback
|
|
|
|
1. `npm run flag -- <workspace_id> off`.
|
|
2. Parar o processo do worker.
|
|
3. Manter `audit_log`, modelos e o banco.
|
|
4. Não rodar script que apague storage ou tabelas.
|
|
5. 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`.
|