From a89eed3ba6fcf86d7c2f52c6b52f3042d1b1bdaf Mon Sep 17 00:00:00 2001 From: VPS 4 Builder Date: Tue, 16 Jun 2026 10:15:19 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20atualiza=20auditoria=20e=20runbook=20pa?= =?UTF-8?q?ra=20o=20fluxo=20CI/CD=20por=20tag=20(Etapa=206=20conclu=C3=ADd?= =?UTF-8?q?a)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - VERDADE-HOJE.md: deploy/rollback/containers/versão refletem CI/CD por tag + registry - DEPLOY-PRODUCAO.md: fluxo canônico = deploy por tag; manual vira fallback Co-Authored-By: Claude Opus 4.8 --- documentação/DEPLOY-PRODUCAO.md | 20 ++++++++++++++++---- documentação/VERDADE-HOJE.md | 19 +++++++++---------- 2 files changed, 25 insertions(+), 14 deletions(-) diff --git a/documentação/DEPLOY-PRODUCAO.md b/documentação/DEPLOY-PRODUCAO.md index 78357d7..7aea8ac 100644 --- a/documentação/DEPLOY-PRODUCAO.md +++ b/documentação/DEPLOY-PRODUCAO.md @@ -1,8 +1,20 @@ -# DEPLOY-PRODUCAO — Runbook operacional (estado de HOJE) +# DEPLOY-PRODUCAO — Runbook operacional -> 🛑 **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`. +> ✅ **FLUXO CANÔNICO HOJE: deploy por TAG (CI/CD).** Para subir uma versão à produção: +> ``` +> # na VPS4, com a versão validada em dev: +> node update-version.js && git add -A && git commit -m "..." && git push origin main +> git tag v1.0.XX && git push origin v1.0.XX # ← a TAG dispara build + deploy automático na VPS1 +> ``` +> A CI builda a imagem versionada, publica no registry e promove para a VPS1 (`deploy-prod.sh`). Confirme em `https://scoreodonto.com/api/version`. +> **Rollback:** na VPS1, `./deploy-prod.sh `. Detalhes em `deploy.md` e `REGISTRY.md`. +> +> ⬇️ O passo a passo manual abaixo continua válido como **fallback** (deploy sem a CI). + +--- + +> 🛑 Procedimento manual (fallback), passo a passo, sem adivinhação. +> Reflete o mecanismo de build local. A realidade da infra está em `arquitetura.md`; o fluxo por tag em `deploy.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). diff --git a/documentação/VERDADE-HOJE.md b/documentação/VERDADE-HOJE.md index a28d6e8..b4dc0ac 100644 --- a/documentação/VERDADE-HOJE.md +++ b/documentação/VERDADE-HOJE.md @@ -18,29 +18,28 @@ ### 3. Onde estão os containers? - **Produção (VPS1, docker rootless `unix:///run/user/1000/docker.sock`):** - - `scoreodontocom-scoreodonto-frontend-1` — Up ~5 dias (imagem `:latest` buildada na própria VPS1). - - `scoreodontocom-scoreodonto-backend-1` — Up ~5 dias (`:8018`). + - `scoreodontocom-scoreodonto-frontend-1` — roda **imagem versionada do registry** (`git.clube67.com/ruicesar/scoreodonto-frontend:`), promovida por deploy-por-tag. Produção **não builda** mais. + - `scoreodontocom-scoreodonto-backend-1` — idem (`:8018`). - `traefik-traefik-1` — borda TLS (Up ~13 dias). Também: rx, newwhats, subdominio, mercado. - **Dev (VPS4, docker root `/var/run/docker.sock`):** - `scoreodontocom-nginx-1` (`0.0.0.0:8020->80`, alvo do Traefik para `dev.`), `scoreodonto-frontend-1` (`:3013`), `scoreodonto-backend-1` (`:8018`). - **Roteamento:** Traefik na VPS1 → `scoreodonto.com` (containers locais) e `dev.scoreodonto.com` → `http://10.99.0.4:8020`. ### 4. Quem faz deploy? -- **Hoje: ninguém automático.** Não há listener nem webhook ativo (o antigo `listener-scoreodonto.js` porta 9002 foi deletado; serviço desligado). **`git push` NÃO dispara deploy.** -- O deploy é **manual**: na VPS1, `git pull` + `docker compose build` + `docker compose up -d` (passo a passo em `DEPLOY-PRODUCAO.md`). -- Ou seja: **a produção builda a si mesma** hoje (o oposto do alvo "prod não builda", que depende do registry — Etapas 4–6). +- **CI/CD por tag (Gitea Actions).** `git tag vX.Y.Z && git push origin vX.Y.Z` → o runner `vps4-builder` builda as imagens, publica no registry e o job `deploy` promove para a VPS1 (`deploy-prod.sh`). **Push na main NÃO deploya — só builda.** +- **Produção não builda mais:** consome a **imagem versionada** do registry (`docker compose -f docker-compose.yml -f docker-compose.prod.yml pull && up -d --no-build`). +- Deploy manual também disponível: na VPS1, `./deploy-prod.sh `. Ver `deploy.md` e `REGISTRY.md`. ### 5. Como versiona? - `APP_VERSION` em `frontend/constants.ts` (dev hoje **`V1.0.13`**), incrementado por `update-version.js` (patch++). - ⚠️ **Bump é manual** — nada chama `update-version.js` no build (`npm run build` = só `vite build`). Por isso a versão fica parada se ninguém rodar o script. -- ✅ **Versão agora é visível** (Etapa 3, 16/jun): rodapé do Sidebar + endpoint `GET /api/version` + log de boot `[VERSION] …`. Carimbo (commit/data/ambiente) injetado no build via build args. **No ar em DEV; produção passa a exibir após o próximo deploy.** +- ✅ **Versão visível** (Etapa 3): rodapé do Sidebar + `GET /api/version` + log de boot `[VERSION] …`. Carimbo (versão/commit/data/ambiente) injetado no build. **No ar em DEV e em PRODUÇÃO** (prod hoje: `v1.0.14 · 081985c · PROD`). ### 6. Como volta uma versão (rollback)? -- **Hoje:** na VPS1, `git checkout ` + `docker compose build` + `up -d` (rebuilda a versão anterior; imagens são `:latest`, sem tag por versão). -- Seguro porque as migrações são **aditivas** (voltar código não quebra o schema). Restaurar dump só em caso extremo. -- **Alvo (Etapa 6):** rollback = `docker compose pull` da tag anterior no registry, **sem rebuild**. +- **Por imagem, sem rebuild:** na VPS1, `./deploy-prod.sh ` (ex.: `./deploy-prod.sh v1.0.13`) — puxa a imagem da tag anterior do registry e sobe. Minutos, sem recompilar. +- Seguro porque as migrações são **aditivas** (voltar código não quebra o schema). Restaurar o dump (`/home/deploy/backups/`) só em caso extremo. --- ## Veredito de uma linha -> O código está salvo no Gitea (VPS3) e roda em containers na VPS1 (prod) e VPS4 (dev), ambos no **mesmo banco** da VPS3. **Não há CI/CD automático**: deploy e rollback são manuais via `git pull` + `docker compose build/up` na VPS1, e a **versão é invisível e bumpada à mão** — as duas dores que as Etapas 3–6 vão eliminar. +> O código está salvo no Gitea (VPS3) e roda em containers na VPS1 (prod) e VPS4 (dev), ambos no **mesmo banco** da VPS3. **CI/CD por tag ativo**: `git tag vX.Y.Z` → CI builda imagem → deploy automático na VPS1, com **versão visível** no rodapé/`/api/version` e **rollback por imagem** (`deploy-prod.sh `). Pendência estrutural restante: **isolar um banco `scoreodonto_dev`** (dev e prod ainda compartilham o banco).