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.

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