51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
# Overview delle tre idee evolutive
|
|
|
|
Documento di sintesi che mette in relazione i tre piani esplorativi:
|
|
|
|
- [idea-1-python-rewrite.md](idea-1-python-rewrite.md) — Conversione del sistema in Python
|
|
- [idea-2-linux-host.md](idea-2-linux-host.md) — Host CI su Linux Mint
|
|
- [idea-3-esxi-support.md](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)
|
|
|
|
1. **Idea 1 prima fase** (estrarre `_Common` + `_Transport` in Python con
|
|
strangler fig) — riduce rischio futuro senza rompere niente.
|
|
2. **Idea 3 con backend astratto** (sui job sperimentali, label dedicata) —
|
|
sblocca scalabilità.
|
|
3. **Idea 1 fasi 2-4** (completamento rewrite Python).
|
|
4. **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.
|