netgescon-day0/docs/support/DISTRIBUZIONE-SERVER-DEBUG.md

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