docs(wiki): add versionamento servidor e cliente Windows rx.scoreodonto.com
VPS 4 Deploy Agent
+5
@@ -6,6 +6,11 @@ Documentação da automação de deploy GitOps (Gitea + Multi-VPS) usada no ecos
|
||||
- [Deploy V.1.0.0](Deploy-V.1.0.0) — versão inicial: listener de webhook, modelos A/B de deploy,
|
||||
configuração no Gitea e segurança.
|
||||
|
||||
## Documentação complementar
|
||||
- [Versionamento](Versionamento) — como o servidor e o cliente Windows controlam versões,
|
||||
onde cada número é definido, problemas atuais de dessincronização e como garantir que
|
||||
as clínicas recebem o update correto.
|
||||
|
||||
## Repositório de exemplos
|
||||
Scripts e instruções de referência (sanitizados) estão no repositório
|
||||
[`ruicesar/Deploy-Automatico`](http://10.99.0.3:3000/ruicesar/Deploy-Automatico):
|
||||
|
||||
+170
@@ -0,0 +1,170 @@
|
||||
# 🔢 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:
|
||||
```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)
|
||||
|
||||
```bash
|
||||
# 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`:
|
||||
|
||||
```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/`:
|
||||
|
||||
```yaml
|
||||
# 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)
|
||||
|
||||
```bash
|
||||
# 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.
|
||||
Reference in New Issue
Block a user