- Remove o stack de "staging" que nunca foi isolado (apontava para o banco de
produção) e não tinha rota no Traefik:
- docker-compose-staging.yml, nginx/default-staging.conf
- deploy-prod-builder.sh, deploy-to-prod.sh (pipeline deprecado — ver DEPLOY-PRODUCAO.md)
- CHECKLIST-DEPLOY-PRODUCAO.md realinhado ao fluxo real: dev.scoreodonto.com (VPS4)
-> build -> VPS1; dev e prod compartilham o mesmo banco (sem ambiente isolado).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# Checklist de Deploy para Produção — Pacote Financeiro + Salas (jun/2026)
> Consolida tudo entregue na rodada: **Financeiro V1 (Épicos 1–4)**, **V2 Comissão/Repasse**, **Glosas**, **GTO→Financeiro**, **modelo de contrato p/ convênio** e o **redesenho de Salas** (perfil Dono de Sala, sala como workspace, financeiro de locação, painel/relatório/agenda).
> Tudo foi desenvolvido e testado em **DEV (VPS4 / dev.scoreodonto.com)**. **Nada commitado/empurrado ainda.**
> Consolida a rodada: **Financeiro V1 (Épicos 1–4)**, **V2 Comissão/Repasse**, **Glosas**, **GTO→Financeiro**, **modelo de contrato p/ convênio** e o **redesenho de Salas** (perfil Dono de Sala, sala como workspace, financeiro de locação, painel/relatório/agenda).
> O **procedimento canônico de deploy** é o `DEPLOY-PRODUCAO.md` — este arquivo é só o checklist desta entrega.
- **Atenção (verificar):** o `docker-compose.yml` aponta `DATABASE_URL=…@10.99.0.3:5432/scoreodonto`. Se PROD (VPS1) **usa o mesmo banco**, as migrações **já foram aplicadas** durante o desenvolvimento (rodam no boot do backend, que fala com o VPS3). Se PROD tiver `.env` próprio com outro banco, as migrações aplicam no **1º boot do backend de prod**. → **CONFIRMAR o `DATABASE_URL` efetivo na VPS1 antes de prosseguir.**
-**Regra:** **NÃO** rodar `deploy-to-prod.sh` automaticamente — é execução manual do operador, com autorização.
## 0. Arquitetura (sem ambiente isolado)
- **VPS4** = **desenvolvimento + builder**. O ambiente de teste é **`dev.scoreodonto.com`** (servido pela VPS4 via Traefik da VPS1) e é onde se **buildam** as imagens que vão pra produção.
- **VPS1** = **produção** (`scoreodonto.com`) — só recebe a imagem pronta e sobe.
- **VPS3** = **dados** (Postgres `scoreodonto`, Dragonfly, Gitea). **Dev e prod apontam para o MESMO banco `scoreodonto`.**
-⚠️ Consequência (confirmada): **dev e prod compartilham o banco** → as migrações desta entrega **já foram aplicadas** ao banco real durante o desenvolvimento (rodam no boot do backend de dev). Promover é, na prática, **levar o CÓDIGO** para a VPS1 — o schema já está migrado. **Não há ambiente nem banco isolado** entre dev e produção.
- [ ] Código **commitado e pushado** para `origin/main` (Gitea `10.99.0.3`). O builder faz `git reset --hard origin/main`. *(push exige sua autorização; NUNCA `--force` na main.)*
- [ ]`node --check backend/server.js` OK.
- [ ] Build do frontend sem erros.
## 1. Fluxo de promoção (resumo do DEPLOY-PRODUCAO.md §2)
1.`git push origin main` (na VPS4) — já feito (commit `3e64514`).
2. Bump de versão (`update-version.js` → `frontend/constants.ts`).
3.**Build da imagem Docker na VPS4** (`npm install` + `vite build` dentro do Dockerfile) — peso fora da produção.
4.**Envia a imagem pronta para a VPS1** (registry privado pela WireGuard — recomendado — ou `docker save | ssh | docker load`).
5.**VPS1:**`docker compose up -d` (troca o container pela imagem nova). Backend leva ~10–30s no boot (reconecta Postgres/Dragonfly + roda migrações).
- *(Os scripts `deploy-prod-builder.sh` e `deploy-to-prod.sh` estão **DEPRECADOS** — ver seção "Fluxo ANTIGO" do `DEPLOY-PRODUCAO.md`. Não usar.)*
## 2. Pré-requisitos
- [ ]**Backup do banco** VPS3 (`pg_dump scoreodonto` — custom format `-Fc`). Como dev/prod compartilham o banco, esse backup é a **única rede de segurança**.
- [ ] Código em `origin/main` (Gitea) — ✅ `3e64514`.
- [ ]`node --check backend/server.js` OK; build do frontend OK.
- [ ] Validado em `dev.scoreodonto.com`.
## 2. Mudanças de banco (migrações idempotentes no boot — `runMigrations()`)
Todas são **aditivas** (`CREATE TABLE/INDEX IF NOT EXISTS`, `ADD COLUMN IF NOT EXISTS`) — **nenhuma destrutiva**.
## 3. Mudanças de banco (migrações idempotentes no boot — todas ADITIVAS)
> Já aplicadas no banco (dev=prod). Listadas para auditoria/rollback. Nenhuma destrutiva.
- **CHECK constraints (DROP+ADD no boot):** `usuarios_role_check` e `vinculos_role_check` ganham **`donosala`** (lista é superset → seguro; nenhum role existente é removido).
- **Seed (boot):** `cmod_odo_14` "Atendimento a Convênios / Repasse" (ON CONFLICT DO NOTHING).
## 3. Backend — env / infra
- [ ]`DATABASE_URL`de prod correto (ver §0).
- [ ]`JWT_SECRET` definido e estável — usado no login **e** em `signMedia/verifyMedia` (URLs assinadas das **fotos de procedimento** e dos **comprovantes de repasse**).
- [ ]**Volume de mídia**(`MEDIA_PATH` → `MEDIA_ROOT`, default `/app/media`) montado e persistente: grava em `…/procedimentos/<id>/`, `…/repasses/<id>/`.
- [ ]**Cron**`processarVigenciasContratos` (boot + 6h): marca **Atrasado**, vigência de contratos, **renovação automática** e **cobrança recorrente** — conferir nos logs após subir.
Smoke tests: criar**lançamento financeiro** (valida `normalizeFinanceiro` — antes nenhum salvava pela UI); **GTO → recebível**; **comissão/repasse/comprovante**; **glosa**; **contrato de convênio**; **orçamento→parcelas**; **fluxo de salas** (Dono de Sala, reserva→recebível, painel); **isolamento cross-tenant 403**.
## 6. Rollback
-As migrações **só adicionam** → rollback de**código** é seguro (colunas/tabelas extras ficam inertes). Reverter para a imagem/artefato anterior na VPS1 e, se necessário, restaurar o dump do §1.
## 7. Rollback
-Migrações **só adicionam** → reverter o**código** (imagem anterior na VPS1) é seguro; colunas/tabelas extras ficam inertes. Restaurar o dump da §2 só se necessário (`pg_restore -d "<url>" --clean <arquivo>`).
## 7. Riscos específicos desta entrega
- **`normalizeFinanceiro` (crítico):** corrige o bug em que `enforceUppercase` mandava `PAGO`/`PIX` e violava os CHECK capitalizados (`Pago`/`Pix`) — antes a tabela `financeiro` ficava sempre vazia. Garantir que entrou no build de prod.
- **Banco compartilhado dev/prod (se confirmado no §0):** dados de teste do desenvolvimento podem aparecer; os E2E desta rodada sempre limparam, mas conferir contagens de `financeiro`, `salas`, `repasses`, `glosas` antes de liberar.
- **Convênios:** o modelo de contrato e os textos jurídicos seguem padrão de mercado — recomendar revisão por advogado.
- **Locação sempre ativa:** todos os papéis (menos superadmin) passam a ver MINHAS/ALUGAR SALAS — confirmar que é o comportamento desejado em produção.
## 8. Riscos específicos desta entrega
- **`normalizeFinanceiro` (crítico):** corrige o bug em que `enforceUppercase` mandava `PAGO`/`PIX` violando o CHECK capitalizado — antes a tabela `financeiro` ficava vazia. Garantir que entrou na imagem.
- **Banco único dev/prod:** dado de teste de desenvolvimento pode aparecer; os E2E desta rodada sempre limparam, mas conferir contagens de `financeiro`, `salas`, `repasses`, `glosas`.
- **Contratos de convênio:** textos seguem padrão de mercado — recomendar revisão por advogado.
- **Locação sempre ativa:** todos os papéis (menos superadmin) passam a ver MINHAS/ALUGAR SALAS.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
VPS 4 Builder