Rollback nello sviluppo: cos'è, metodi e come funziona

Cos'è il rollback nello sviluppo

Rollback è un'operazione che riporta il sistema a uno stato stabile precedente. Nel contesto dello sviluppo, ciò può significare annullare un commit in Git, eseguire il rollback di una transazione nel database o tornare a una versione precedente di un'applicazione sul server. Il termine deriva dall'inglese “rollback” ed è saldamente radicato nel vocabolario degli sviluppatori di tutte le piattaforme.

La necessità di un rollback sorge quando una nuova modifica rompe la funzionalità, causa errori o non supera i controlli di qualità. In un processo di sviluppo ben organizzato, il rollback non è un segno di fallimento, ma una procedura standard integrata nel flusso di lavoro. Più velocemente un team può annullare una modifica problematica, minore sarà l'impatto del bug sugli utenti.

Strumenti diversi offrono meccanismi di rollback diversi: Git offre una scelta tra revert sicuro e reset distruttivo, i database supportano il rollback transazionale e i sistemi CI/CD possono commutare il traffico tra le versioni. La scelta dell'approccio dipende dal contesto e dai requisiti di conservazione della cronologia delle modifiche.

Git revert vs git reset: qual è la differenza

Git revert è un metodo sicuro di rollback che crea un nuovo commit annullando le modifiche precedenti. La cronologia rimane lineare e tutti i vecchi commit vengono preservati. Questa è la scelta corretta per annullare in un ramo condiviso su cui lavorano più sviluppatori. Git revert non elimina la cronologia — aggiunge il fatto del rollback come una nuova modifica.

Git reset sposta il puntatore del ramo corrente su un commit specifico, scartando tutte le modifiche successive. A seconda del flag — soft, mixed o hard — reset gestisce la directory di lavoro e l'indice in modo diverso. La modalità hard rimuove completamente le modifiche dalla cronologia, rendendola pericolosa per i rami condivisi e adatta solo al lavoro locale.

Quando usare revert

Revert viene utilizzato nei rami condivisi: main, develop, release. Preserva la cronologia e consente ad altri sviluppatori di capire che una modifica è stata annullata. Dopo revert, puoi eseguire git pull in sicurezza — il sistema non produrrà conflitti relativi alla cronologia riscritta. Nel lavoro di squadra, revert è lo standard predefinito.

# Annullare l'ultimo commit creando un nuovo commit
git revert HEAD

# Annullare un commit specifico per hash
git revert a1b2c3d

Quando usare reset

Reset è appropriato in un ramo locale dove non hai ancora pubblicato le modifiche. Se stavi sperimentando e vuoi pulire completamente la cronologia — reset hard lo farà. In un ramo locale, puoi usare reset mixed per annullare i commit ma mantenere le modifiche nella directory di lavoro per ricommittare.

# Annullare l'ultimo commit, mantenere le modifiche nella directory di lavoro
git reset HEAD~1

# Annullamento completo — le modifiche vengono rimosse permanentemente
git reset --hard HEAD~2

Rollback nei database: transazioni e ACID

Rollback di transazione è un'operazione che annulla tutte le modifiche apportate nell'ambito della transazione corrente e riporta il database allo stato all'inizio della transazione. Ciò garantisce l'atomicità — uno dei quattro principi ACID (Atomicity, Consistency, Isolation, Durability). Se si verifica un errore in qualsiasi fase della transazione, viene eseguito un rollback e i dati tornano allo stato originale.

Il meccanismo di rollback è implementato tramite il journal di scrittura anticipata (Write-Ahead Log, WAL). Prima di modificare una pagina di dati, il DBMS scrive i vecchi e nuovi valori nel journal. Durante il rollback, il sistema legge il journal e ripristina i valori originali per tutte le pagine modificate. Ciò garantisce che anche in caso di interruzione di corrente, la transazione possa essere correttamente annullata.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: rollback parziale

Nelle transazioni lunghe, è conveniente utilizzare i savepoint — punti di salvataggio intermedi a cui è possibile tornare senza completare l'intera transazione. Ciò consente di gestire gli errori all'interno di un'operazione complessa senza perdere i progressi su altre parti. I savepoint sono supportati dalla maggior parte dei DBMS relazionali: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Rollback nella distribuzione: strategie e strumenti

Rollback di distribuzione è il ripristino di un'applicazione in esecuzione a una versione precedente dopo una distribuzione non riuscita. Questa è una capacità critica per gli ambienti di produzione: il tempo di ripristino (MTTR) influisce direttamente su SLA ed esperienza utente. Le piattaforme moderne offrono diverse strategie di rollback a seconda dell'architettura e dei requisiti di disponibilità.

Blue-green deployment

Blue-green è una strategia in cui due ambienti identici funzionano contemporaneamente: blue (versione corrente) e green (nuova versione). Il traffico viene commutato su green dopo una distribuzione riuscita. Se la nuova versione funziona in modo errato, il commutatore di traffico torna a blue. Il rollback viene eseguito istantaneamente, senza ridistribuzione — basta modificare il routing.

Canary release con rollback automatico

Canary deployment dirige una piccola parte del traffico verso la nuova versione e monitora le metriche: tasso di errore, tempo di risposta, percentuale di richieste riuscite. Se le metriche peggiorano, il sistema annulla automaticamente il canary e dirige tutto il traffico alla versione stabile. Kubernetes e i service mesh (Istio, Linkerd) supportano questa strategia nativamente.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Esempi pratici di rollback nello sviluppo

Esaminiamo tre scenari tipici in cui uno sviluppatore deve annullare le modifiche. Ogni scenario richiede il proprio approccio — da un semplice comando nel terminale a una procedura in più fasi che coinvolge CI/CD.

Scenario 1: commit accidentale in main

Hai accidentalmente inviato un commit con un bug in main. Il tuo compito è annullare le modifiche senza perdere la cronologia per il team. Usa git revert per creare un commit di annullamento e poi git push. Tutti i membri del team vedranno il rollback e potranno continuare a lavorare senza conflitti. Questo è il metodo più sicuro e trasparente.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Scenario 2: migrazione del database fallita

Una migrazione del database è fallita e alcuni dati sono danneggiati. Usa il rollback transazionale nello script di migrazione e ripristina dal backup per le modifiche già applicate. In un sistema ben progettato, ogni migrazione è racchiusa in una transazione — in caso di errore, il DBMS esegue automaticamente un rollback.

Scenario 3: distribuzione con bug critico

Dopo aver distribuito una nuova versione, scopri che l'autenticazione non funziona. Se usi blue-green, il rollback è riportare il router indietro. Se è un aggiornamento progressivo — il comando kubectl rollout undo ripristinerà la versione precedente. Idealmente, il processo di rollback dovrebbe essere automatizzato e non richiedere più di un minuto.