Piano operativo¶
Versione del 27/10/2026. Obiettivo: portare midserver v3, box della linea stage, pannello e qAlarm 2 in produzione in modo sicuro, mantenendo attivo il sistema vecchio finché il nuovo non è completo.
Fuori scope (segnalato)¶
- Monitoraggio automatico con allarmi (R1): problema aperto e segnalato, non fa parte di questo piano. Nel frattempo, dopo ogni intervento in prod si fanno controlli manuali.
Principi¶
- Prima la messa in sicurezza, poi il codice. La Fase 0 non cambia il comportamento dei sistemi.
- Tutto passa da dev. Niente arriva in prod senza aver superato i test su Coolify dev con box di prova.
- Il lato server cambia prima dei box. Il midserver si riporta indietro in minuti; 38 box remoti no.
- Indirizzi stabili. I box conoscono
172.16.16.253:5000,:1883e185.31.66.185:9999: restano gli stessi. - Il vecchio sistema non si tocca (Telegram, progetto di Michele, ewelink, VPN degli impianti non migrati) finché il nuovo non lo sostituisce.
- Ogni passo in prod ha un rollback scritto prima di essere eseguito.
- Porte di controllo (gate): alla fine di alcune fasi si decide insieme se andare avanti, con una checklist.
Fasi¶
| Fase | Nome | Obiettivo | Tocca la prod? | Dipende da |
|---|---|---|---|---|
| 0 | Messa in sicurezza | backup, pulizia pfSense, revisione VPN, inventario, documentazione | sì, a basso rischio | — |
| 1 | Ambiente di test completo | box di prova collegati al dev, piano di test | no | 0 (in parte) |
| 2 | Codice dei box | comportamenti della 3.2.9 in stage, live e connessioni alle telecamere, API v1, import delle configurazioni e ponte di aggiornamento, release |
no | — |
| 3 | Codice del midserver v3 | parità con la v2, più istanze, Redis persistente, build ECR | no | — |
| 4 | Codice di qAlarm 2 | Q1–Q10, richieste della centrale | no | — |
| 5 | Validazione in dev — GATE A | test end-to-end, aggiornamento senza fermo, ripristino backup | no | 1, 2, 3, 4 |
| 6 | Infrastruttura di prod | dominio, VM prod-apps, Coolify prod, backup | sì (nuove risorse) | 0, A |
| 7 | qAlarm 2 in prod (pilota) — GATE B | pochi operatori in parallelo a Telegram | sì (nuovo servizio) | 6 |
| 8 | Midserver v3 in prod — GATE C | cambio in finestra con rollback | sì, alto impatto | 5, 6, 9a |
| 9 | Aggiornamento dei box | 9a: tutti a 3.2.9; 9b: migrazione graduale alla nuova versione | sì, sul campo | 1 (9a), 8 (9b) |
| 10 | Dismissioni e consolidamento | ewelink nel midserver, Telegram spento, VPN segmentata, segreti, domini | sì | 7, 8, 9b |
Le Fasi 2, 3 e 4 possono procedere in parallelo. La Fase 9a (allineamento a 3.2.9 con il midserver attuale) può partire appena la procedura è provata sulle macchine di test.
flowchart LR
F0[0 Messa in sicurezza] --> F1[1 Ambiente test]
F1 --> F5
F2[2 Codice box] --> F5
F3[3 Codice midserver v3] --> F5
F4[4 Codice qAlarm] --> F5
F5{{5 Validazione dev<br/>GATE A}} --> F6[6 Infra prod]
F0 --> F6
F6 --> F7{{7 qAlarm pilota<br/>GATE B}}
F1 --> F9a[9a Box a 3.2.9]
F9a --> F8{{8 Midserver v3 in prod<br/>GATE C}}
F6 --> F8
F8 --> F9b[9b Box alla nuova versione]
F7 --> F10[10 Dismissioni]
F9b --> F10
Hold "Ctrl" to enable pan & zoom
Ticket¶
Il lavoro è diviso in ticket in 07-ticket: il piano dice cosa e perché, i ticket chi e in che ordine.
Documenti del piano¶
| Documento | Contenuto |
|---|---|
| piano-avvio-operativo.md | Primi passi: ricognizione in sola lettura, scelta del box di prova, isolamento del dev e primo intervento mirato |
| attivita.md | Elenco dettagliato delle attività: per ognuna perché, chi, passi, criterio di completamento, rollback, stato |
| piano-test-dev.md | Matrice dei test da superare in dev (Fase 5) |
| piano-cambio-midserver.md | Procedura passo per passo del passaggio v2 → v3 in prod, con rollback (Fase 8) |
| checklist-gate.md | Checklist dei gate A, B, C |
Ruoli (vedi persone e ruoli)¶
- Sviluppo (Lorenzo, Mohammad, coding agent supervisionati): Fasi 2, 3, 4 e la parte tecnica di 5, 8, 9.
- Sistemi (Michele, Mattia): Fasi 0 (pfSense, Proxmox), 6, il lato rete di 8 e 10.
- Coordinamento (Enrico, Emanuele): gate, finestre di manutenzione, rapporti con la centrale.
- Centrale operativa: test di accettazione di qAlarm (Fase 7) e conferma dopo il cambio (Fase 8).
Tempi¶
Il piano non fissa date: le durate dipendono dalla disponibilità delle persone e delle macchine di test. Il coordinamento lo trasforma in calendario, partendo dalla Fase 0, che si può iniziare subito.
Come aggiornare il piano¶
- Lo stato di ogni attività si aggiorna in attivita.md (⬜ da fare, 🔄 in corso, ✅ fatto, ⛔ bloccato, ❌ annullato), con data e riferimento (commit, PR, ticket).
- Se un'attività cambia lo stato del sistema, aggiornare anche 04-stato.