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

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