ruicesar/Deploy-Automatico
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Page: Versionamento
Pages
Deploy V.1.0.0 Deploy V.1.0.1 Deploy V.1.0.2 Deploy V.1.0.3 Deploy V.1.0.5 Home Versionamento
Clone
1
Versionamento
VPS 4 Deploy Agent edited this page 2026-05-30 15:00:17 +02:00
Table of Contents

🔢 Versionamento — rx.scoreodonto.com

Documentação completa do sistema de versões do servidor web e do cliente Windows, como identificar a versão em produção e como garantir que mudanças são detectadas corretamente.

Modelo de referência: rx.scoreodonto.com (servidor) + rx.scoreodonto.com-client (cliente Windows Electron).

1. Servidor — rx.scoreodonto.com

Onde a versão é definida

O servidor tem três lugares onde a versão aparece — e hoje estão dessincronizados (problema documentado abaixo):

Arquivo Valor atual Propósito
dental-server/version.txt 2.1.0 Arquivo lido em runtime pelo servidor
dental-server/package.json → "version" 2.0.5 Metadado do pacote Node
dental-server/public/index.html linha 33 v2.1.2 Exibido na sidebar do painel web

A versão visível ao usuário (sidebar do painel) é a do index.html — hardcoded diretamente no HTML:

<h2>RF Dental <span>v2.1.2</span></h2>

⚠️ Problema atual: três fontes, três valores diferentes

version.txt  →  2.1.0
package.json →  2.0.5
index.html   →  v2.1.2   ← o que o usuário vê

Não existe nenhum script que sincronize esses três valores automaticamente. A versão do index.html é editada manualmente a cada deploy, e pode ficar para trás (ou ser bumped fora de ordem).

Como saber a versão em produção (hoje)

# O que o usuário vê no painel:
ssh deploy@10.99.0.1 "grep 'v2\.' /home/deploy/stack/rx.scoreodonto.com/dental-server/public/index.html | grep span | head -1"

# O que o servidor lê no arquivo:
ssh deploy@10.99.0.1 "cat /home/deploy/stack/rx.scoreodonto.com/dental-server/version.txt"

Como bumpar a versão do servidor (processo atual)

  1. Editar manualmente os três arquivos para o novo número.
  2. Rodar ./deploy-prod.sh (processo manual, sem webhook).
  3. Verificar no painel web se a versão exibida mudou.

2. Cliente Windows — rx.scoreodonto.com-client

Onde a versão é definida

O cliente tem uma fonte única de verdade — o package.json:

// rx.scoreodonto.com-client/package.json
{
  "version": "1.2.7"
}

O electron-builder lê esse valor na hora do build e:

  • Nomeia o instalador: ScoreOdonto Dental Client Setup 1.2.7.exe
  • Grava no latest.yml que vai para a pasta updates/:
# dental-server/updates/latest.yml
version: 1.2.6       ← versão que está no ar nas clínicas hoje
files:
  - url: ScoreOdonto Dental Client Setup 1.2.6.exe
    sha512: zEYuIRBUTlpGa1...
    size: 102459655

⚠️ Problema atual: latest.yml aponta para 1.2.6, mas 1.2.7 já foi buildado

Local Versão
package.json na VPS 4 1.2.7
.exe mais recente em dist/ (VPS 4) 1.2.7
latest.yml em updates/ (VPS 1) 1.2.6
O que as clínicas recebem via auto-update 1.2.6

O deploy-client.sh foi rodado para gerar o 1.2.7.exe mas o rsync para a VPS 1 não foi executado (ou foi executado com --delete e o latest.yml não foi atualizado). As clínicas nunca receberão o 1.2.7 enquanto o latest.yml disser 1.2.6.

Como o auto-update funciona (fluxo completo)

Clínica (Windows)
  └─► electron-updater verifica: GET https://rx.scoreodonto.com/updates/latest.yml
          │
          ├─ version no yml > version instalada?
          │      SIM → baixa o .exe silenciosamente → instala ao reiniciar
          └─     NÃO → nada acontece

Portanto: a versão que as clínicas têm é determinada pelo latest.yml em produção, não pelo package.json nem pelo .exe na VPS 4. Se o latest.yml não for atualizado, nenhuma clínica recebe a nova versão.

Como bumpar a versão do cliente (processo correto)

# 1. Editar o package.json com a nova versão
nano /home/deploy/stack/rx.scoreodonto.com-client/package.json
# Ex: "version": "1.2.7" → "1.2.8"

# 2. Rodar o deploy (build + rsync para VPS1)
cd /home/deploy/stack/rx.scoreodonto.com-client
./deploy-client.sh

# 3. Confirmar que o latest.yml foi atualizado na VPS1
ssh deploy@10.99.0.1 "cat /home/deploy/stack/rx.scoreodonto.com/dental-server/updates/latest.yml"
# → version: deve mostrar a nova versão

# 4. Confirmar a URL pública (o que as clínicas acessam)
curl -s https://rx.scoreodonto.com/updates/latest.yml

Histórico de versões observado (dist/ na VPS 4)

Versão Data build
1.2.0 28/05/2026 02:59
1.2.1 28/05/2026 03:09
1.2.2 28/05/2026 03:18
1.2.3 28/05/2026 03:32
1.2.4 28/05/2026 03:56
1.2.5 28/05/2026 05:34
1.2.6 28/05/2026 05:45 ← em produção (VPS1)
1.2.7 28/05/2026 20:38 ← buildado, não publicado

3. Comparativo e regra de ouro

Servidor Cliente Windows
Fonte de verdade index.html (exibição) + version.txt (runtime) package.json → latest.yml
Onde o usuário vê Sidebar do painel web Bandeja do Windows (ícone)
O que determina se há update Deploy manual (rebuild Docker) latest.yml na pasta updates/
Risco atual Três arquivos dessincronizados latest.yml desatualizado → clínicas presas na versão anterior

Regra de ouro: no cliente, a única versão que importa para as clínicas é a do latest.yml em produção. O .exe na VPS 4 não vale nada se o latest.yml não for sobrescrito com a nova versão. Sempre confirmar com curl https://rx.scoreodonto.com/updates/latest.yml após o deploy.

4. Melhorias recomendadas (sem aplicar — apenas registro)

Servidor

  • Criar um update-version.js na raiz do projeto que escreva o mesmo número nos três arquivos (version.txt, package.json, index.html) atomicamente — elimina a dessincronização.
  • O deploy-prod.sh chamaria esse script antes do rsync.

Cliente

  • O deploy-client.sh já tem a estrutura certa; falta apenas garantir que o rsync com --delete inclua sempre o latest.yml mais novo (não usar || fallback sem --delete em versões parciais).
  • Com a automação GitOps: o push para main dispara o build + deploy automaticamente, eliminando o risco de esquecer de rodar o script.