# Roadmap evolutiva — overview

Decisione presa: implementare **prima Idea 1 (Python) + Idea 2 (host Linux)**
in sequenza, e **solo dopo** valutare Idea 3 (ESXi).

| Fase | Cosa                                                         | File di dettaglio                                          |
| ---- | ------------------------------------------------------------ | ---------------------------------------------------------- |
| A    | Rewrite in Python sull'host Windows attuale (codebase cross-platform-ready) | [idea-1-python-rewrite.md](idea-1-python-rewrite.md)       |
| B    | Migrazione host: Windows 11 + Workstation Pro → Linux Mint + Workstation Pro Linux | [idea-2-linux-host.md](idea-2-linux-host.md)               |
| C    | (Futuro, condizionato a A+B stabili) Aggiunta backend ESXi   | [idea-3-esxi-support.md](idea-3-esxi-support.md)           |

---

## 1. Razionale dell'ordine

1. **Idea 1 prima di Idea 2**: scrivere Python *sapendo già* che girerà anche
   su Linux evita un doppio porting. Tutto il codice nuovo nasce
   cross-platform (no path hardcoded `F:\`, no `Get-StoredCredential`,
   no `New-PSSession` come unica via). Idea 2 diventa un'operazione di
   "swap della base OS" con codice già pronto.
2. **Workstation Pro su entrambi gli OS**: scegliendo Workstation Pro anche
   su Linux (binario `/usr/bin/vmrun`, senza `.exe`) si mantiene **lo stesso
   comando `vmrun` e gli stessi VMX template** — zero conversione VMDK→qcow2,
   zero rewrite del backend hypervisor. Idea 2 diventa un porting di
   plumbing (path, service manager, credential store) e non di logica.
3. **ESXi dopo**: una volta stabilizzato Python + Linux, l'introduzione di
   ESXi è un nuovo backend dietro un'astrazione `VmBackend` (introdotta
   già in fase A come hook di design); il core non cambia.

---

## 2. Sinergie sfruttate

- Python (Idea 1) abilita `pypsrp` (WinRM cross-platform), `paramiko` (SSH
  cross-platform), `keyring` (Credential Manager su Win, Secret Service su
  Linux): un unico tooling che funziona su entrambi gli host.
- Tenere VMware Workstation Pro su Linux (Idea 2) elimina la necessità di
  imparare libvirt/KVM ora; resta come opzione futura se Broadcom dismette
  Workstation Pro.
- L'astrazione `VmBackend` introdotta come "design hook" già in Idea 1
  riduce a costo marginale l'aggiunta del backend ESXi (Idea 3) tramite
  `pyVmomi`.

---

## 3. Riepilogo prerequisiti per fase

| Fase | Prerequisiti host                                                                               | Prerequisiti competenze                                  |
| ---- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| A    | Python 3.11+ su Windows; ambiente venv in `F:\CI\python\venv\`                                  | Python, pytest, pypsrp/paramiko                          |
| B    | Hardware Linux Mint operativo; VMware Workstation Pro Linux installata; storage analogo a `F:\CI\` | systemd, bash, secret-tool, gestione utente di servizio  |
| C    | Hardware ESXi + licenza Essentials o superiore; account vSphere dedicato                        | pyVmomi, datastore/portgroup management                  |

---

## 4. Criteri di "fase completata"

- **A done**: `Invoke-CIJob.ps1` retired; tutti i job CI passano via
  `python -m ci_orchestrator job ...`; test pytest verdi; capacity burn-in
  4 job concorrenti PASS sull'host Windows attuale.
- **B done**: act_runner gira come systemd service su Linux Mint; tutti i
  workflow esistenti (Windows + Linux build) PASS dal nuovo host; storage
  migrato a `/var/lib/ci/`; capacity burn-in PASS.
- **C done** (se attivata): label `windows-build:esxi` operativa con backend
  pyVmomi; canary su almeno 1 workflow di produzione per ≥1 settimana
  senza regressioni.

---

## 5. Cosa fare se A o B falliscono / si bloccano

- **Stop in A**: il sistema PowerShell attuale resta in produzione (rollback
  banale, niente è stato distrutto). La parte Python già scritta resta come
  modulo "side-by-side" non utilizzato.
- **Stop in B**: l'host Windows resta primario; eventuale runner Linux
  secondario può comunque essere utile per workload sperimentali (path
  "dual-host" descritto in [idea-2-linux-host.md](idea-2-linux-host.md) §7).
- **Stop pianificato in C**: nessun impatto — C è opzionale per definizione,
  Workstation Pro su Linux copre già il caso d'uso primario.