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