Blocco B · La filiera automatizzata — Modulo 8 di 16
Git e Pipeline as Code
Obiettivi di oggi
- Flusso Git di squadra: branch corti, merge request, main protetto
- Prima pipeline:
.gitlab-ci.yml, stage, job, runner
- Lint e build automatici a ogni push
La procedura diventa un file
stages: [lint, build]
lint-python:
stage: lint
image: python:3.12-slim # ogni job in un container PULITO
script:
- pip install ruff==0.4.4
- ruff check api/
build-api:
stage: build
image: docker:26
services: ["docker:26-dind"]
script:
- docker build -t pratiche/api:ci api/
Chi esegue? Il runner
- Un agente registrato su GitLab che prende i job e li esegue in container
- Nell'Ente: lo gestiscono i sistemisti (host, capienza, aggiornamenti)
- La pipeline (il file) è dello sviluppo: nasce qui il confine dei ruoli sulla CI
Le stesse idee, altrove
| GitLab CI | GitHub Actions | Azure DevOps |
|---|
| .gitlab-ci.yml | .github/workflows/*.yml | azure-pipelines.yml |
| stage / job | job (needs) / step | stage / job |
| runner | runner | agent |
Impariamo su GitLab; i concetti si trasferiscono 1:1 — anche verso i fornitori che usano altro.
Laboratorio (2h)
- Progetto su GitLab (o GitLab d'aula), push del codice Pratiche
- Pipeline lint+build; rompila apposta, guardala bloccare, riparala
- Badge di stato nel README
Riepilogo e prossimo passo
- A ogni push, un collega instancabile controlla e builda — uguale per tutti
- Ma non testa nulla e non pubblica ancora…
- Modulo 9: test come cancello e release versionate