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