Blocco B · La filiera automatizzata — Modulo 11 di 16

Deploy automatico in staging

Obiettivi di oggi

Merge su main → servizio aggiornato in staging, da solo
Il server "magro": solo compose + .env, niente codice né build
Smoke test = criterio di successo del deploy

Anatomia del server di esercizio

/srv/pratiche/
├── compose.staging.yaml    # image: dal registry (MAI build:)
├── .env                    # config e segreti, permessi 600 (sistemisti)
├── deploy.sh               # pull + up + smoke test
└── backup/

Niente codice, niente git, niente build sul server
Staging identico a produzione: stesse immagini, stesso compose

Il job di deploy

deploy-staging:
  environment: { name: staging }
  rules: [{ if: $CI_COMMIT_BRANCH == "main" }]
  script:
    - scp deploy/* utente@staging:/srv/pratiche/
    - ssh utente@staging "cd /srv/pratiche &&
        TAG=sha-$CI_COMMIT_SHORT_SHA ./deploy.sh"

Chiave SSH = variabile CI protetta e mascherata (la gestiscono i sistemisti)
environment: GitLab tiene la cronologia di cosa è deployato dove

Lo smoke test non è opzionale

for i in $(seq 1 20); do
  curl -fsS http://localhost:8080/health && exit 0
  sleep 3
done
exit 1     # deploy FALLITO → pipeline rossa → tutti lo vedono

Un deploy senza verifica è una speranza. Il job fallisce se il servizio non risponde.

Laboratorio (2h)

compose.staging.yaml + deploy.sh; job deploy-staging
Merge su main → osserva lo staging aggiornarsi da solo
Sabota lo staging → lo smoke test boccia il deploy

Riepilogo e prossimo passo

commit → merge → staging aggiornato: nessun passaggio a mano
La produzione merita tre cose in più: approvazione, backup, rollback
Modulo 12: il rilascio completo — e il Blocco B si chiude