108 lines
2.7 KiB
Markdown
108 lines
2.7 KiB
Markdown
# Distribuzione server e debug separato
|
|
|
|
## Obiettivo
|
|
|
|
Portare NetGescon fuori dalla sola rete locale e iniziare a lavorare con nodi separati per:
|
|
|
|
- deploy piu stabili
|
|
- collaudo fuori macchina sviluppo
|
|
- debug su ambienti isolati
|
|
- verifica reale di update, restore e sincronizzazioni
|
|
|
|
## Punto di partenza
|
|
|
|
Oggi il flusso piu stabile e:
|
|
|
|
1. sviluppo nel workspace Day0
|
|
2. commit e push su Gitea
|
|
3. sync UI da `Supporto > Modifiche`
|
|
4. verifica su staging
|
|
|
|
Questo flusso va mantenuto anche quando iniziamo a distribuire NetGescon su altri server.
|
|
|
|
## Strategia consigliata
|
|
|
|
### Fase 1. Nodo staging separato e disciplinato
|
|
|
|
Obiettivo:
|
|
|
|
- continuare a usare staging come nodo intermedio obbligatorio
|
|
- verificare che update, migrazioni e ricuciture dati passino sempre dalla procedura Git-first
|
|
|
|
Vincoli:
|
|
|
|
- niente modifiche manuali non tracciate sul nodo
|
|
- niente deploy paralleli fuori procedura
|
|
|
|
### Fase 2. Nodo debug esterno alla rete locale
|
|
|
|
Obiettivo:
|
|
|
|
- avere una macchina separata dalla rete di sviluppo
|
|
- usare dati di test controllati
|
|
- validare comportamento applicativo, login, PBX, allegati, storage, update
|
|
|
|
Uso consigliato:
|
|
|
|
- test deployment
|
|
- test restore
|
|
- test debug multi-macchina
|
|
- verifiche su watcher o bridge che non devono vivere solo sul PC principale
|
|
|
|
### Fase 3. Pacchetto installabile ripetibile
|
|
|
|
Obiettivo:
|
|
|
|
- trasformare NetGescon in un installabile coerente
|
|
- poter allestire un nuovo nodo senza ricostruire a mano script, env e procedure
|
|
|
|
Minimo indispensabile:
|
|
|
|
- checklist server
|
|
- script bootstrap
|
|
- procedura aggiornamento
|
|
- procedura backup e restore
|
|
- note di rete e storage
|
|
|
|
## Architettura iniziale consigliata
|
|
|
|
Per il primo ciclo non serve un parco complesso di macchine.
|
|
|
|
Bastano tre ruoli chiari:
|
|
|
|
1. workspace autorevole Day0
|
|
2. staging operativo aggiornato da Gitea
|
|
3. debug node separato per prove e collaudi fuori rete locale
|
|
|
|
## Cosa validare sul debug node
|
|
|
|
- installazione applicativa pulita
|
|
- migrazioni e bootstrap
|
|
- login e permessi ruoli
|
|
- documentazione in `Supporto > Modifiche`
|
|
- procedura Git sync e pacchetto aggiornamento
|
|
- Post-it, ticket e CRM telefonico
|
|
- storage tenant-aware e documenti sensibili
|
|
- eventuali watcher PBX o bridge esterni
|
|
|
|
## Regola pratica per il deploy
|
|
|
|
Ogni nodo deve poter essere ricostruito da materiale nel repository.
|
|
|
|
Quindi il repo deve contenere almeno:
|
|
|
|
- manuale operativo
|
|
- flusso update staging
|
|
- architettura ruoli/moduli
|
|
- note continuita agent
|
|
- script di update e di sync gia usati dalla UI
|
|
|
|
## Decisione attuale
|
|
|
|
Per il prossimo passo concreto:
|
|
|
|
1. completare il commit del slice corrente
|
|
2. aggiornare staging via Git-first
|
|
3. preparare una checklist tecnica per il primo nodo debug esterno
|
|
4. poi estrarre un bootstrap server riusabile, senza dipendere dalla macchina locale
|