scoreodonto.com/doc/VERDADE-HOJE.md

Qual é a verdade hoje? — Auditoria de infra ScoreOdonto

Resposta direta às 6 perguntas essenciais, verificada em 23/jun/2026. Somente fatos do estado atual. Documento principal: em caso de divergência entre docs, este prevalece. Como operar → DEPLOY-PRODUCAO.md (runbook). Para onde vamos → deploy.md (arquitetura-alvo).

---

1. Onde está o código?

• Fonte da verdade: Gitea na VPS3, repo ruicesar/scoreodonto.com.
• Dev (trabalho): VPS4 em /home/deploy/stack/scoreodonto.com.
• Produção: VPS1 roda imagens versionadas do registry (não código-fonte). No ar: v1.0.28 · commit 6a88995.
• Documentação: centralizada em scoreodonto.com/doc/ (pasta única).

2. Onde está o banco?

• Produção: PostgreSQL no host da VPS3 (10.99.0.3:5432), banco scoreodonto, user scoreodonto_user.
• ✅ DEV ISOLADO: a VPS4 usa um container PostGIS próprio pgdev (banco scoreodonto_dev), NÃO mais o banco de produção. Dev e prod não compartilham mais. (Ver BANCO-DEV-ESTRATEGIA.md.)
• Cache DragonflyDB (10.99.0.3:6379, índice /1). NATS (:4222) e Temporal (:7233).

3. Onde estão os containers?

• Produção (VPS1, docker rootless): scoreodontocom-scoreodonto-{frontend,backend}-1 rodam a imagem do registry (git.clube67.com/ruicesar/scoreodonto-*:<tag>). Produção não builda. Também na VPS1: traefik (borda TLS), rx, newwhats, subdominio, mercado.
• Dev (VPS4, docker rootless): nginx-1 (8020→80, alvo do Traefik para dev.), frontend-1 (:3013), backend-1 (:8018) — buildados localmente e apontados ao pgdev.
• 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). Push na main → o runner act_runner "vps4-builder" (VPS4, rootless) builda e publica no registry (NÃO deploya). git tag vX.Y.Z && git push → CI + job deploy promove para a VPS1 (deploy-prod.sh).
• Produção consome imagem (pull + up -d --no-build).
• ✅ Build Once → Promote (Passo 5, validado em produção): push builda 1× e publica por commit (:<sha>); a tag re-tagueia esse artefato como :vX.Y.Z (sem rebuild — digest idêntico) e deploya. Provado em v1.0.16 (:v1.0.16 == :471c2c2, mesmo digest).

5. Como versiona?

• A versão exibida vem do backend em runtime: GET /api/version (de process.env), mostrada em Configurações → "Sobre o sistema" e nas telas públicas (o frontend consome via useAppVersion(), não embute mais a versão). No ar: v1.0.28 · 6a88995 · PROD.
• A versão nasce da tag git e é injetada no deploy em runtime (APP_VERSION=tag, APP_ENV=PROD); commit/build vêm carimbados na imagem.
• ✅ constants.ts/update-version.js foram removidos (Passo 5) — não há mais versão manual.

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

• Por imagem, sem rebuild: na VPS1, ./deploy-prod.sh <ref-anterior> → pull + up -d --no-build.
• ⚠️ A referência confiável é o commit (:<sha>): tags :vX.Y.Z podem ter sido republicadas com código diferente (colisão de tags pré-Passo 5 — confirmado: :v1.0.14 do registry ≠ o que rodava). Migrações são aditivas (voltar o código é seguro). Dump em /home/deploy/backups/ só em caso extremo.

---

Veredito de uma linha

O código vive no Gitea (VPS3); a produção (VPS1) roda imagens versionadas do registry (hoje v1.0.28), sem buildar; o DEV está isolado no pgdev (não toca o banco de produção). CI/CD por tag ativo no modelo Build Once → Promote → Deploy (push builda por commit; tag re-tagueia sem rebuild e deploya — validado em v1.0.16), com versão visível em runtime (/api/version → Configurações) nascendo da tag git.