local-ci-cd-system/plans/ideas-overview.md

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
B	✅ Migrazione host: Windows 11 + Workstation Pro → Linux Mint + Workstation Pro Linux	idea-2-linux-host.md
C	(Futuro, dopo B stabile) Eliminazione dipendenza pwsh dall'host Linux	idea-3-powershell-removal.md
D	(Futuro, condizionato a C stabili) Aggiunta backend ESXi	idea-4-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	Fase B stabile ≥1 settimana; pwsh ancora installato durante il porting	click, subprocess, pytest
D	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): pwsh può essere disinstallato dall'host Linux senza impatti operativi; bench run, validate host e smoke run sostituiscono completamente i relativi .ps1; suite pytest verde ≥90%.
• D 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 §7).
• Stop pianificato in C: nessun impatto — gli script .ps1 originali restano funzionanti; pwsh resta installato. Il sistema continua a girare.
• Stop pianificato in D: nessun impatto — D è opzionale per definizione, Workstation Pro su Linux copre già il caso d'uso primario.