Files
2026-06-17 17:31:50 +02:00

1.5 KiB

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.

# 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):

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.