scoreodonto.com/documentação/VERDADE-HOJE.md

Qual é a verdade hoje? — Auditoria de infra ScoreOdonto

Resposta direta às 6 perguntas essenciais, verificada em 16/jun/2026. Sem teoria, sem fantasma. Detalhes em arquitetura.md (real), deploy.md (alvo) e DEPLOY-PRODUCAO.md (runbook).

---

1. Onde está o código?

• Fonte da verdade: Gitea na VPS3, repo ruicesar/scoreodonto.com (ssh://git@10.99.0.3/ruicesar/scoreodonto.com.git).
• Cópia de trabalho (dev): VPS4 em /home/deploy/stack/scoreodonto.com (onde se programa).
• Cópia de produção: VPS1 em /home/deploy/stack/scoreodonto.com (HEAD verificado: 19dbbae).
• Documentação: centralizada em scoreodonto.com/documentação/ (este diretório).

2. Onde está o banco?

• PostgreSQL no host da VPS3 (10.99.0.3:5432), banco scoreodonto, usuário scoreodonto_user.
• ⚠️ DEV e PROD usam o MESMO banco. Não há isolamento. Backup (pg_dump -Fc) é a única rede de segurança.
• Cache DragonflyDB (10.99.0.3:6379, índice /1). Mensageria NATS (:4222) e Temporal (:7233).

3. Onde estão os containers?

• Produção (VPS1, docker rootless unix:///run/user/1000/docker.sock):
  • scoreodontocom-scoreodonto-frontend-1 — roda imagem versionada do registry (git.clube67.com/ruicesar/scoreodonto-frontend:<tag>), promovida por deploy-por-tag. Produção não builda mais.
  • scoreodontocom-scoreodonto-backend-1 — idem (:8018).
  • traefik-traefik-1 — borda TLS (Up ~13 dias). Também: rx, newwhats, subdominio, mercado.
• Dev (VPS4, docker root /var/run/docker.sock):
  • scoreodontocom-nginx-1 (0.0.0.0:8020->80, alvo do Traefik para dev.), scoreodonto-frontend-1 (:3013), scoreodonto-backend-1 (:8018).
• Roteamento: Traefik na VPS1 → scoreodonto.com (containers locais) e dev.scoreodonto.com → http://10.99.0.4:8020.

4. Quem faz deploy?

• CI/CD por tag (Gitea Actions). git tag vX.Y.Z && git push origin vX.Y.Z → o runner vps4-builder builda as imagens, publica no registry e o job deploy promove para a VPS1 (deploy-prod.sh). Push na main NÃO deploya — só builda.
• Produção não builda mais: consome a imagem versionada do registry (docker compose -f docker-compose.yml -f docker-compose.prod.yml pull && up -d --no-build).
• Deploy manual também disponível: na VPS1, ./deploy-prod.sh <tag>. Ver deploy.md e REGISTRY.md.

5. Como versiona?

• APP_VERSION em frontend/constants.ts (dev hoje V1.0.13), incrementado por update-version.js (patch++).
• ⚠️ Bump é manual — nada chama update-version.js no build (npm run build = só vite build). Por isso a versão fica parada se ninguém rodar o script.
• ✅ Versão visível (Etapa 3): rodapé do Sidebar + GET /api/version + log de boot [VERSION] …. Carimbo (versão/commit/data/ambiente) injetado no build. No ar em DEV e em PRODUÇÃO (prod hoje: v1.0.14 · 081985c · PROD).

6. Como volta uma versão (rollback)?

• Por imagem, sem rebuild: na VPS1, ./deploy-prod.sh <tag-anterior> (ex.: ./deploy-prod.sh v1.0.13) — puxa a imagem da tag anterior do registry e sobe. Minutos, sem recompilar.
• Seguro porque as migrações são aditivas (voltar código não quebra o schema). Restaurar o dump (/home/deploy/backups/) só em caso extremo.

---

Veredito de uma linha

O código está salvo no Gitea (VPS3) e roda em containers na VPS1 (prod) e VPS4 (dev), ambos no mesmo banco da VPS3. CI/CD por tag ativo: git tag vX.Y.Z → CI builda imagem → deploy automático na VPS1, com versão visível no rodapé//api/version e rollback por imagem (deploy-prod.sh <tag-anterior>). Pendência estrutural restante: isolar um banco scoreodonto_dev (dev e prod ainda compartilham o banco).