Blocco B · La filiera automatizzata — Modulo 12 di 16

Produzione e rollback

Obiettivi di oggi

Deploy in produzione: solo da tag, manuale, con backup automatico prima
Rollback come routine provata, non come emergenza inventata
CHANGELOG e disciplina di release

Cosa distingue la produzione

	Staging	Produzione
Trigger	merge su main (auto)	tag vX.Y.Z + bottone (manuale)
Versione	sha-commit	solo semver
Prima del deploy	—	backup (job obbligatorio)
Chi approva	—	referente di servizio (RACI)

Automazione + approvazione

deploy-prod:
  needs: ["backup-prod"]        # niente deploy senza backup fresco
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
      when: manual              # il bottone Play

L'automazione garantisce il COME (sempre uguale, sempre verificato)
L'umano decide il QUANDO (finestra, comunicazione, presidio)

Il rollback è un deploy

VERSIONE=1.1.0 ./rollback.sh   # = deploy.sh con la versione precedente

Stesso meccanismo del deploy: niente procedure speciali sotto stress
Possibile PERCHÉ le versioni sono immutabili sul registry (M7)
Si prova in tempo di pace — oggi, in lab

Laboratorio (2h)

Stage deploy-prod: backup (pg_dump) → deploy manuale; CHANGELOG
Release v1.1.0 completa
Release v1.2.0 "rotta" → smoke test la boccia → rollback a v1.1.0 eseguito

Fine Blocco B: la filiera è completa

commit → lint → test → build → scan → staging → (approvazione) → produzione → rollback
Questo è l'esempio end-to-end richiesto dall'Ente — funzionante e documentato
Blocco C: da un caso riuscito al modello per TUTTI i servizi

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