scoreodonto.com/documentação/DEPLOY-PRODUCAO.md

DEPLOY-PRODUCAO — Runbook operacional (estado de HOJE)

🛑 LEIA PRIMEIRO. Procedimento real e executável hoje, passo a passo, sem adivinhação. Reflete o mecanismo atual: a produção (VPS1) builda a si mesma via git pull + docker compose build + up -d. O fluxo-alvo (registry + deploy por tag, prod sem build) está em deploy.md e ainda não existe. A realidade da infra está em arquitetura.md.

⚠️ Regra de ouro: antes de qualquer build/deploy/push, confirme com o operador DEV ou PRODUÇÃO. dev.scoreodonto.com = VPS4 (descartável, mas mesmo banco da prod). scoreodonto.com = VPS1 (real). Nunca git push --force na main. Dev e prod compartilham o banco (VPS3) — o backup é a única rede de segurança.

---

Mapa rápido (quem é quem)

Onde	Host	Papel	Socket Docker
VPS4	10.99.0.4	dev + builder (código aqui)	/var/run/docker.sock (root)
VPS1	10.99.0.1	produção	unix:///run/user/1000/docker.sock (rootless)
VPS3	10.99.0.3	Postgres + Gitea	—

• Repo: ssh://git@10.99.0.3/ruicesar/scoreodonto.com.git (Gitea).
• Diretório do repo nas duas máquinas: /home/deploy/stack/scoreodonto.com.
• Project Compose: scoreodontocom (containers scoreodontocom-*).

---

FASE 0 — Pré-voo (na VPS4)

cd /home/deploy/stack/scoreodonto.com

# 1. Sanidade do backend
node --check backend/server.js

# 2. Validar a mudança em DEV (já no ar em https://dev.scoreodonto.com)
#    Conferir o bundle servido (deve mudar a cada rebuild):
curl -s https://dev.scoreodonto.com/ | grep -oE 'index-[A-Za-z0-9_-]+\.js' | head -1

# 3. BACKUP DO BANCO (rede de segurança única — dev/prod compartilham o banco)
#    Rodar na VPS3. Usar as credenciais do ambiente/segredo, nunca em texto puro.
ssh deploy@10.99.0.3 'pg_dump -Fc scoreodonto -f /home/deploy/backups/scoreodonto_$(date +%Y%m%d_%H%M).dump'

---

FASE 1 — Versão (na VPS4) ⚠️ passo manual

O bump não é automático (npm run build é só vite build). É preciso incrementar à mão:

cd /home/deploy/stack/scoreodonto.com
node update-version.js      # incrementa o patch em frontend/constants.ts (ex.: V1.0.12 → V1.0.13)
grep APP_VERSION frontend/constants.ts

Hoje a versão não fica visível no navegador (está no bundle JS). Até a Etapa 3 (versionamento visível), anote a versão que está promovendo.

---

FASE 2 — Commit & push para o Gitea (na VPS4)

Só execute com autorização explícita do operador (é o repo de produção).

cd /home/deploy/stack/scoreodonto.com
git add -A
git commit -m "feat: <descrição> (bump vX.Y.Z)"
git push origin main

❗ Push não dispara deploy automático hoje (não há listener/webhook ativo). A promoção é a FASE 3.

---

FASE 3 — Promover para produção (na VPS1)

ssh deploy@10.99.0.1
export DOCKER_HOST=unix:///run/user/1000/docker.sock     # docker rootless da VPS1
cd /home/deploy/stack/scoreodonto.com

# 1. Trazer o código aprovado
git pull origin main

# 2. Carimbo de versão visível (lido pelos build args do compose) — em PROD use APP_ENV=PROD
export APP_VERSION=$(grep -oE 'V[0-9]+\.[0-9]+\.[0-9]+' frontend/constants.ts | head -1)
export GIT_COMMIT=$(git rev-parse --short HEAD)
export BUILD_TIME=$(date -u +'%Y-%m-%d %H:%M UTC')
export APP_ENV=PROD

# 3. Buildar as imagens (frontend faz vite build; backend npm install)
docker compose build scoreodonto-frontend scoreodonto-backend

# 4. Subir (troca os containers pelas imagens novas)
docker compose up -d scoreodonto-frontend scoreodonto-backend nginx

Os 4 export carimbam versão/commit/data/ambiente na imagem. Sem eles, o build ainda funciona mas mostra dev/unknown no rodapé. Em DEV (VPS4) use APP_ENV=DEV.

O backend leva ~10–30s no boot (reconecta Postgres/Dragonfly e roda as migrações idempotentes).

---

FASE 4 — Verificação pós-deploy (na VPS1)

export DOCKER_HOST=unix:///run/user/1000/docker.sock

# Containers no ar
docker ps --format '{{.Names}} | {{.Status}}' | grep score

# Backend: esperar a linha de migração + carimbo de versão
docker logs scoreodontocom-scoreodonto-backend-1 --tail 40 | grep -iE 'migration|VERSION'
# alvo: [MIGRATION] all migrations OK
#       [VERSION] ScoreOdonto API vX.Y.Z · commit ... · build ... · PROD

# Confirmar a versão no ar SEM acessar container (a forma definitiva):
curl -s https://scoreodonto.com/api/version
# {"name":"ScoreOdonto API","version":"vX.Y.Z","commit":"...","build":"...","environment":"PROD"}

# E visualmente: a versão aparece no rodapé do menu lateral (Sidebar).

Smoke tests mínimos: abrir https://scoreodonto.com, logar, e exercitar o que mudou (ex.: lançamento financeiro, agenda, salas). Conferir ausência de erro 500 no docker logs.

---

FASE 5 — Rollback (se algo quebrar)

As migrações são aditivas → reverter o código é seguro (colunas/tabelas extras ficam inertes).

ssh deploy@10.99.0.1
export DOCKER_HOST=unix:///run/user/1000/docker.sock
cd /home/deploy/stack/scoreodonto.com

git log --oneline -5                 # achar o commit bom anterior
git checkout <commit-anterior>       # ou: git reset --hard <commit-anterior>
docker compose build scoreodonto-frontend scoreodonto-backend
docker compose up -d scoreodonto-frontend scoreodonto-backend

Hoje o rollback rebuilda a versão anterior (as imagens são :latest, não há tag por versão). Quando a Etapa 6 entregar deploy por tag + registry, o rollback vira só docker compose pull da tag anterior — sem rebuild. Restaurar o dump do banco (FASE 0) só em caso extremo: pg_restore -d "postgresql://scoreodonto_user:<senha>@10.99.0.3:5432/scoreodonto" --clean <arquivo>.dump

---

Resumo em uma tela

VPS4: validar em dev  →  node --check  →  backup do banco (VPS3)
   →  node update-version.js  →  commit  →  git push origin main   (com OK do operador)
VPS1: git pull  →  docker compose build  →  docker compose up -d
   →  verificar logs ([MIGRATION] all migrations OK) + smoke test
Rollback: git checkout <commit-bom>  →  build  →  up -d