Regole di Business - DevOps & CI/CD

Questo documento elenca le regole di business fondamentali del dominio DevOps & CI/CD, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul comportamento della pipeline di integrazione e rilascio.

---

BR-001 - Build once, deploy many

Codice: BR-001 Nome: Un artefatto è costruito una sola volta e promosso immutato tra gli ambienti Descrizione: Lo stesso Artifact prodotto dalla fase di build deve essere promosso identico attraverso staging e produzione. Non è ammesso ricostruire l'artefatto per ogni ambiente, perché introdurrebbe differenze non testate. Motivazione: Garantire che ciò che è stato testato sia esattamente ciò che viene rilasciato; tracciabilità. Priorità: ALTA Attori: CI Runner, Release Manager Violazione: la promozione è bloccata se l'artefatto in produzione non corrisponde per digest a quello testato. Tracciabilità: 12factor.net; build-and-release.md; Artifact (glossary).

---

BR-002 - Artefatti immutabili e versionati

Codice: BR-002 Nome: Ogni artefatto ha un identificatore univoco immutabile (digest/versione) Descrizione: Un Artifact pubblicato nell'ArtifactRegistry non può essere sovrascritto. Una nuova build produce un nuovo identificatore (tag versione o digest del contenuto). I tag mutabili (es. latest) non sono fonte di verità per la promozione. Motivazione: Riproducibilità dei rilasci e rollback affidabile. Priorità: ALTA Attori: CI Runner, Artifact Registry Tracciabilità: OCI image digest; SemVer; BR-001.

---

BR-003 - Ogni modifica passa per la pipeline

Codice: BR-003 Nome: Nessun cambiamento raggiunge la produzione senza superare la pipeline CI/CD Descrizione: Ogni Commit destinato alla produzione deve attraversare la Pipeline (build, test, scan, gate) con esito verde. Sono vietate modifiche manuali dirette negli ambienti. Motivazione: Qualità, ripetibilità e auditabilità di ogni rilascio. Priorità: CRITICA Attori: Developer, CI Runner Violazione: rollback immediato e blocco dell'accesso diretto agli ambienti. Tracciabilità: commit-to-deploy.md; GitOps (glossary).

---

BR-004 - Gate di qualità bloccanti

Codice: BR-004 Nome: Una pipeline con test, SAST o scansioni falliti non promuove Descrizione: Se un Job di test, di analisi statica (SAST) o di sicurezza fallisce, lo Stage corrispondente fallisce e la Pipeline non procede alla promozione. I gate non possono essere aggirati senza un'eccezione tracciata e approvata. Motivazione: Impedire che difetti o vulnerabilità note raggiungano la produzione (shift left). Priorità: ALTA Attori: CI Runner, Security Engineer Tracciabilità: Shift Left, DevSecOps (glossary); commit-to-deploy.md.

---

BR-005 - I segreti non risiedono mai nel codice o nei log

Codice: BR-005 Nome: Credenziali e token sono iniettati dal Secrets Manager, mai versionati Descrizione: Nessun segreto deve comparire nel repository Git, nella cronologia, nei file di pipeline o nei log dei Job. I segreti sono recuperati a runtime dal secrets manager con accesso auditato e mascherati nei log. Motivazione: Prevenire la disclosure di credenziali nella supply chain. Priorità: CRITICA Attori: Security Engineer, CI Runner Violazione: lo scan di segreti blocca la pipeline; rotazione immediata. Tracciabilità: Secrets Management, Supply Chain Security (glossary).

---

BR-006 - Deploy a downtime zero con rollback rapido

Codice: BR-006 Nome: Ogni rilascio in produzione è progressivo e reversibile rapidamente Descrizione: I rilasci usano strategie progressive (blue-green o canary) con health check; in caso di degrado, il Rollback riporta alla versione precedente in pochi minuti senza ricostruire l'artefatto. Motivazione: Ridurre il rischio e il blast radius di un rilascio difettoso. Priorità: ALTA Attori: Release Manager, Deployment Target Tracciabilità: Blue-Green, Canary, Zero-Downtime Deployment (glossary); deploy-rollback.md.

---

BR-007 - La pipeline è definita come codice nel repository

Codice: BR-007 Nome: La definizione della pipeline vive versionata accanto al codice Descrizione: La configurazione di build, test e deploy (Pipeline, Stage, Job) è dichiarata in file versionati nel repository, non configurata manualmente nell'interfaccia del sistema CI. Le modifiche passano per code review. Motivazione: Tracciabilità, riproducibilità e revisione delle modifiche al processo di rilascio. Priorità: ALTA Attori: Developer, Platform Engineer Tracciabilità: Infrastructure as Code, GitOps (glossary).

---

BR-008 - Supply chain verificabile (SBOM e provenienza)

Codice: BR-008 Nome: Ogni artefatto ha un SBOM e una provenienza firmata Descrizione: La pipeline genera un SBOM (Software Bill of Materials) per ogni Artifact e ne registra la provenienza firmata. Le dipendenze sono scansionate per vulnerabilità note prima della promozione. Motivazione: Tracciare e mettere in sicurezza la catena di fornitura del software. Priorità: ALTA Attori: Security Engineer, CI Runner Tracciabilità: SBOM, Supply Chain Security (glossary); BR-004.

---

BR-009 - Le metriche DORA guidano il miglioramento

Codice: BR-009 Nome: Lead time, frequenza di deploy, MTTR e change failure rate sono misurati Descrizione: Il dominio misura le quattro DORA metrics per ogni servizio: lead time for changes, deployment frequency, mean time to recovery e change failure rate. Le decisioni di miglioramento del processo si basano su questi indicatori, non su opinioni. Motivazione: Migliorare in modo misurabile velocità e stabilità del delivery. Priorità: MEDIA Attori: Platform Engineer, Release Manager Tracciabilità: DORA Metrics, Lead Time for Changes, MTTR, Change Failure Rate (glossary).