2.7 KiB
2.7 KiB
Overview delle tre idee evolutive
Documento di sintesi che mette in relazione i tre piani esplorativi:
- idea-1-python-rewrite.md — Conversione del sistema in Python
- idea-2-linux-host.md — Host CI su Linux Mint
- idea-3-esxi-support.md — Build VM su ESXi remoto
Matrice di sinergia
| Combinazione | Sinergia | Note |
|---|---|---|
| Solo Idea 1 (Python) | Neutra | Refactor "interno", nessun beneficio funzionale immediato. Utile se prerequisito a 2/3. |
| Solo Idea 2 (Linux host + KVM) | Alta | Cambio piattaforma; PS 7 possibile ma Python (Idea 1) consigliato. |
| Solo Idea 3 (ESXi backend) | Alta | Compatibile con stato attuale; PowerCLI o pyVmomi. |
| Idea 1 + Idea 2 | Molto alta | La rewrite Python rimuove l'attrito cross-platform. |
| Idea 1 + Idea 3 | Molto alta | pyVmomi è Python-only. |
| Idea 2 + Idea 3 | Media | Host Linux + build ESXi: massimo decoupling, ma rischi sommati. |
| Idee 1 + 2 + 3 | Alta | Massima modernizzazione. Da scaglionare in 3 milestone separate. |
Ordine consigliato (se si vogliono perseguire tutte)
- Idea 1 prima fase (estrarre
_Common+_Transportin Python con strangler fig) — riduce rischio futuro senza rompere niente. - Idea 3 con backend astratto (sui job sperimentali, label dedicata) — sblocca scalabilità.
- Idea 1 fasi 2-4 (completamento rewrite Python).
- Idea 2 (migrazione host Linux) — solo dopo 1 e 3 stabili.
Andare nell'ordine inverso (prima Linux, poi ESXi, infine Python) raddoppia il debito tecnico nei periodi intermedi.
Quando NON fare nulla
Il sistema attuale è documentato come production-ready. Astenersi se:
- La concorrenza richiesta è ≤4 job e l'hardware regge.
- Non c'è pressione team su preferenze cross-platform.
- Non si pianifica espansione hardware nei prossimi 6 mesi.
- Il budget tempo è meglio speso in nuovi workflow CI per altri repo.
In quel caso, l'investimento migliore è estendere i test (tests/ Pester
attuali), aggiungere osservabilità (Get-CIJobSummary, metriche) e
documentare meglio l'esistente — non riscrivere.