Blocco B · La filiera automatizzata — Modulo 9 di 16

Pipeline di build e test

Obiettivi di oggi

Test automatici (pytest) come cancello prima della build
Build & push condizionati: sha su main, semver sui tag
Il flusso di release: git tag v1.0.0 → immagine 1.0.0 sul registry

Cosa testiamo (minimo sindacale)

/health risponde · l'elenco risponde · la creazione crea
Furbizia di design: senza DATABASE_URL l'app va in memoria → i test girano ovunque, senza DB
Non serve coverage al 100%: serve il cancello che ferma le rotture evidenti

Un flusso, tre velocità

Evento	Cosa gira	Perché
push su branch	lint + test	feedback veloce a chi lavora
merge su main	+ build & push `sha-…`	ogni main è deployabile
tag `vX.Y.Z`	+ tag immagine `X.Y.Z`	la release ufficiale

rules:
  - if: $CI_COMMIT_BRANCH == "main"
  - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/

La release in pratica

git tag v1.0.0
git push origin v1.0.0
# → pipeline: lint → test → build → push api:1.0.0, web:1.0.0

Il tag Git è l'atto formale; tutto il resto è automatico
Un'immagine sul registry ora CERTIFICA: commit noto + test passati

Laboratorio (2h)

Test in locale, poi stage test in pipeline
Build&push con regole main/tag; release v1.0.0 verificata sul registry
Rompi un test: l'immagine NON si pubblica

Riepilogo e prossimo passo

Dal commit alla release: automatico, tracciato, uguale per tutti
Ma dentro le immagini possono esserci vulnerabilità note…
Modulo 10: i cancelli di qualità e sicurezza dell'Ente

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