# Distribuzione e aggiornamenti

## Obiettivo

Allineare NetGescon a un flusso di distribuzione reale, verificabile e ripetibile.

Stato operativo attuale:

- sviluppo nel repository `netgescon-day0`
- versionamento e condivisione su Gitea interno
- staging e nodi aggiornati partendo da Gitea
- Docker, APT, immagini pubbliche e canali commerciali restano scenari possibili ma non il percorso principale di oggi

## Flusso reale da usare oggi

1. sviluppo e test nel workspace locale `netgescon-day0`
2. commit Git locali
3. push verso `origin` su Gitea interno
4. aggiornamento di staging allineando il repository pubblicato su Gitea
5. aggiornamento degli altri siti con lo stesso meccanismo

Regola chiave:

- evitare come flusso ordinario il deploy manuale diretto di file o patch dalla macchina di sviluppo verso staging
- la macchina di staging deve essere riallineata dal repository Gitea

## Stato canali distribuzione

- infrastruttura `free` / `licensed` gia prevista nel codice
- uso reale attuale: una sola linea di distribuzione
- il nome del canale tecnico presente nelle config non equivale ancora a un modello commerciale consolidato

## Gitea interno

- remote principale attuale: `ssh://git@192.168.0.53:2222/michele/netgescon-day0.git`
- branch operativo corrente: `main`
- Gitea e il punto di passaggio obbligato per distribuire il codice sviluppato

## Procedura minima di aggiornamento

1. verificare modifiche e contesto con `git status`
2. creare commit coerenti
3. fare push su `origin`
4. documentare il cambiamento se tocca flussi operativi o distribuzione
5. aggiornare staging tramite pull o meccanismo equivalente dal repository Gitea
6. eseguire solo sul nodo aggiornato le normali operazioni Laravel: cache clear, eventuali migrate, check salute

## Cosa non considerare flusso principale

- pubblicazione GitHub pubblica
- distribuzione Docker come percorso standard di tutti i siti
- repository multipli separati per core/plugin/theme come assetto gia in esercizio
- differenziazione commerciale gia attiva tra `free` e `licensed`

## Scenari futuri, non prioritari

- server update dedicato
- pacchettizzazione release
- canali distinti di licensing
- distribuzione containerizzata piu automatica

Questi scenari possono restare documentati, ma devono essere marcati come successivi rispetto al flusso Git/Gitea attuale.

## Checklist pratica attuale

- repository corretto: `netgescon-day0`
- remote corretto: `origin` su Gitea interno
- branch corretto: `main`, salvo eccezioni deliberate
- documentazione aggiornata insieme alle modifiche di processo
- staging allineato dal repository, non da copie locali non tracciate

## Note operative

- se un ambiente usa ancora script remoti o rsync, va considerato transitorio e da riallineare al flusso Gitea
- prima di formalizzare canali commerciali distinti serve una decisione operativa esplicita
- la documentazione deve sempre distinguere tra stato reale attivo e roadmap futura

## Appendice tecnica futura

I seguenti temi restano validi come approfondimenti architetturali futuri, ma non sono il flusso primario corrente:

- container Docker dedicati
- rolling update o blue/green
- repository pacchetti e update server dedicati
- separazione commerciale avanzata dei canali

Quando verranno riattivati come percorso principale, andranno documentati in un documento separato o in una revisione successiva di questo file.