Add unified implementation plan for Phase A and Phase B in Markdown format
- Create a new document `plans/implementation-plan-A-B.md` that consolidates the implementation plans for the Python rewrite (Phase A) and the migration to Linux Mint (Phase B). - The document includes detailed sections such as executive summary, checklist, prerequisites, step-by-step activities, architectural hooks for future phases, risk matrix, and references. - Ensure the plan is self-contained, adhering to specified structure and style guidelines, and does not introduce new technologies or modify existing files.
This commit is contained in:
+63
-34
@@ -1,50 +1,79 @@
|
||||
# Overview delle tre idee evolutive
|
||||
# Roadmap evolutiva — overview
|
||||
|
||||
Documento di sintesi che mette in relazione i tre piani esplorativi:
|
||||
Decisione presa: implementare **prima Idea 1 (Python) + Idea 2 (host Linux)**
|
||||
in sequenza, e **solo dopo** valutare Idea 3 (ESXi).
|
||||
|
||||
- [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
|
||||
| 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) |
|
||||
|
||||
---
|
||||
|
||||
## Matrice di sinergia
|
||||
## 1. Razionale dell'ordine
|
||||
|
||||
| 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. |
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Ordine consigliato (se si vogliono perseguire tutte)
|
||||
## 2. Sinergie sfruttate
|
||||
|
||||
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.
|
||||
- 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`.
|
||||
|
||||
---
|
||||
|
||||
## Quando NON fare nulla
|
||||
## 3. Riepilogo prerequisiti per fase
|
||||
|
||||
Il sistema attuale è documentato come `production-ready`. Astenersi se:
|
||||
| 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 |
|
||||
|
||||
- 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.
|
||||
## 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.
|
||||
|
||||
Reference in New Issue
Block a user