88 lines
3.3 KiB
Markdown
88 lines
3.3 KiB
Markdown
# 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.
|