c0ca88c028
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.5 KiB
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.