# Deploy — Subir um release

> Situação: **quero colocar uma versão nova em produção.**

⚠️ **Regra de ouro:** confirme **DEV ou PRODUÇÃO** antes de agir. `dev.<projeto>` = VPS4 (descartável). `<projeto>` sem `dev.` = VPS1 (real). **Nunca** `git push --force` na `main`. Push e tag exigem **autorização explícita do administrador**.

```bash
# 1) VPS4 — validar em DEV
node --check backend/server.js
docker compose build scoreodonto-backend scoreodonto-frontend
docker compose up -d --force-recreate scoreodonto-backend scoreodonto-frontend   # conferir em dev.<projeto>

# 2) commit + push → o CI builda 1x e publica :<commit> + :latest (NÃO deploya)
git add -A && git commit -m "feat: <descrição>"
git push origin main

# 3) tag = "aprovado para produção" → o CI re-tagueia :<commit>→:vX.Y.Z (SEM rebuild) e deploya
git tag -a vX.Y.Z -m "release vX.Y.Z" && git push origin vX.Y.Z

# 4) verificar (sem SSH)
curl -s https://<projeto>/api/version    # → vX.Y.Z · <commit> · PROD
curl -s https://<projeto>/api/health     # → status ok
```

**Backup do banco de produção antes de releases sensíveis** (não há shell na VPS3; usar container):
```bash
docker run --rm -e PGPASSWORD=<senha> -v /home/deploy/backups:/b postgres:18 \
  pg_dump -h 10.99.0.3 -U <user> -d <banco> -Fc -f /b/<banco>_$(date +%Y%m%d_%H%M).dump
```

> Pré-requisito do passo 3: o commit já tem que estar publicado no registry (passo 2). Se não estiver, o CI **falha de propósito** ("faça push antes da tag") — nunca builda na tag.