Blocco B · La filiera automatizzata — Modulo 7 di 16
Registry e versionamento
Obiettivi di oggi
- Pubblicare immagini su un registry (GitLab o locale)
- Convenzioni dell'Ente: naming, semver, doppio tag, retention
- Capire il registry come confine tra chi pubblica e chi preleva
Il registry è il punto di scambio
- Sviluppo (persone e pipeline) pubblica; esercizio (server) preleva
- Niente più "ti passo l'immagine", "builda sul server", "copia la cartella"
- È anche il punto di controllo: scansioni, retention, immagini approvate
Naming e versioni dell'Ente
registry.ente.it/servizi-cittadino/pratiche/api:1.2.0
# registry / area / servizio / componente : versione
- SemVer
X.Y.Z: la release, per gli umani — creata SOLO dalla pipeline
sha-a1b2c3d: il commit esatto, per l'audit — a ogni build- Un tag pubblicato è immutabile: mai ri-pushare
Perché latest è vietato
- Due deploy di
latest possono essere immagini DIVERSE: non sai cosa gira
- Rollback impossibile: "torna a latest di ieri" non esiste
- Consentito solo come comodità in sviluppo locale
Laboratorio (2h)
- Push di api e web (GitLab Container Registry, o registry:2 in aula chiusa)
- Doppio tag semver + sha; catalogo via API
- "Deploy da registry": rimuovi le immagini locali e riavvia con
image:
- Scrivi
docs/convenzioni-immagini.md: nasce la prima linea guida
Riepilogo e prossimo passo
- Le immagini hanno una casa e un nome parlante; le versioni un significato
- Ma il push è ancora manuale, da chiunque, senza controlli…
- Modulo 8: la pipeline — d'ora in poi pubblica solo lei