Blocco C · Il modello per l'Ente — Modulo 15 di 16

Architettura standard

e matrice dei ruoli

Obiettivi di oggi

Il blueprint di repository: il template da cui parte ogni servizio
La checklist di adozione: il collaudo tecnico, per interni e fornitori
La matrice RACI: chi fa cosa, riga per riga

Il blueprint: niente di nuovo, tutto al suo posto

NOME-SERVIZIO/
├── README.md            # M2-5: come si avvia
├── .gitlab-ci.yml       # M8-12: la pipeline standard
├── .env.example         # M6: il contratto di configurazione
├── compose*.yaml        # M5-6: base, override dev, prod
├── docs/runbook.md      # M13 · architettura.md · raci.md
└── api/Dockerfile       # M3: multi-stage, non-root, healthcheck

Ogni file rimanda al modulo in cui l'hai costruito. Il blueprint è il corso, compresso.

Il confine dei ruoli, in una frase

Sviluppatore (interno o fornitore): responsabile dentro il container + la pipeline che lo produce
Sistemista: responsabile sotto e intorno — host, rete, dati, segreti, registry, runner
Referente di servizio: decide quando si va in produzione
Sicurezza: decide se un rischio è accettabile

Regole per i fornitori

Consegnano repository conforme al blueprint + pipeline funzionante nel GitLab dell'Ente
MAI immagini via email, MAI accessi manuali ai server: ciò che non passa dalla pipeline non esiste
La checklist di adozione È il collaudo; la conformità è requisito contrattuale
SLA sulle CRITICAL definito in contratto

Laboratorio (2h)

Porta l'Albo Avvisi (M14) sul blueprint: struttura, pipeline, documenti
Compila la RACI del servizio
Gioco di ruolo: fornitore consegna ↔ referente collauda con la checklist

Riepilogo e prossimo passo

Il modello è completo: esemplare (Pratiche) + metodo (M14) + standard (blueprint) + ruoli (RACI)
Resta una domanda: regge in mani autonome?
Modulo 16: la prova — da zero alla produzione in 4 ore, da soli

← portale · frecce/click per navigare · F = schermo intero · Ctrl+P = PDF