Hotfix nello sviluppo di app: essenza, meccanismo e come applicarlo

Cos’è un hotfix e quando serve?

Un hotfix (correzione rapida) è una patch per la versione di produzione di un’applicazione rilasciata fuori coda per risolvere un problema critico. Un hotfix viene consegnato agli utenti in ore, non in giorni, ed è destinato esclusivamente a situazioni in cui l’applicazione non è disponibile, perde dati o compromette la sicurezza dell’utente.

Scenari tipici per un hotfix: crash all’avvio su determinati dispositivi (regressione dopo l’ultimo rilascio), perdita di dati personali a causa di un’autorizzazione errata, integrazione di pagamento interrotta (perdita di entrate), violazioni di conformità GDPR/CCPA. Tutte queste situazioni hanno gravità P0 o P1 nella classificazione degli incidenti. Le attività pianificate — ottimizzazione, refactoring, nuovi schermi — non vengono mai eseguite tramite hotfix.

Una regola importante: un hotfix contiene un numero minimo di modifiche (1–2 file, 10–20 righe di codice). Più piccolo è il diff, minore è il rischio di introdurre un nuovo bug. Se per risolvere il problema è necessario modificare l’architettura o aggiungere un nuovo modulo — non si tratta di un hotfix, ma di un rilascio di emergenza che richiede una revisione completa del codice e QA.

Come un hotfix si differenzia da un rilascio normale

Le principali differenze tra un hotfix e un rilascio pianificato sono la velocità, la portata delle modifiche e il livello di test. Un rilascio pianificato può includere decine di funzionalità, passare attraverso un ciclo QA completo (test di regressione + integrazione + UI) e richiedere 1–2 settimane dal blocco del codice alla distribuzione. Un hotfix include una o due correzioni, passa attraverso una revisione accelerata (2 approvazioni invece di 3) e test smoke minimi.

Dal punto di vista del processo Git, un hotfix viene creato da un tag di rilascio, non dal ramo develop. Ciò garantisce che solo le modifiche necessarie per correggere il problema siano incluse nell’hotfix, senza incorporare accidentalmente funzionalità non finite da develop. Dopo la distribuzione, l’hotfix viene unito nuovamente in main e develop (tramite cherry-pick o merge).

Confronto tra rilascio pianificato e hotfix

Importante: non ogni attività urgente è un hotfix. Se un manager dice “dobbiamo urgentemente aggiungere un pulsante” — non è un hotfix, è un cambiamento di priorità. Un vero hotfix è determinato dalla gravità per l’utente, non dall’urgenza per l’azienda. Il criterio: se l’applicazione non si blocca e i dati non vengono persi — l’attività attende un rilascio pianificato.

Processo di hotfix: dal rilevamento alla distribuzione

Il primo passo quando si scopre un problema critico è il triage — una rapida valutazione della gravità. L’ingegnere di turno conferma il bug, controlla i log e i crash report e determina se il problema è una regressione dell’ultimo rilascio o un bug di vecchia data. Se la gravità è P0 — viene attivata la pipeline hotfix. La fase di triage non dovrebbe richiedere più di 15 minuti.

Il secondo passo — creare un ramo dall’ultimo tag di rilascio (v2.5.0 → hotfix/v2.5.1). Lo sviluppatore apporta la correzione minima, esegue il commit con il prefisso HOTFIX nel messaggio, invia e apre una PR con l’etichetta [HOTFIX]. Revisione del codice fast-track: due revisori vengono assegnati automaticamente tramite CODEOWNERS, tempo di revisione — non più di 30 minuti. Se non c’è revisione entro 20 minuti — il revisore viene saltato e viene assegnato il successivo.

Il terzo passo — build e distribuzione tramite CI/CD. La pipeline hotfix differisce da quella normale: i lunghi test di integrazione (che richiedono ore) vengono saltati, viene eseguita solo la suite smoke (10–15 scenari critici, 5–10 minuti). Dopo la distribuzione: monitoraggio del tasso di crash, tasso di errore, latenza dell’API — per 30 minuti. Metriche DORA per gli hotfix: il tempo medio di recupero (MTTR) dovrebbe essere inferiore a 1 ora.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Ottimizzazioni chiave in questa pipeline: controllo del diff (non più di 30 righe), salto dei test di integrazione, distribuzione automatica in staging e production se il test smoke ha successo. HOTFIX_MODE variabile d’ambiente che abilita controlli aggiuntivi in fase di esecuzione — ad esempio, registrazione estesa per una diagnosi rapida dei problemi.

Rami hotfix in Git: la strategia corretta

La strategia per lavorare con i rami hotfix è descritta in Gitflow Workflow. La regola principale: un ramo hotfix viene creato dall’ultimo tag di rilascio (git checkout -b hotfix/v2.5.1 tags/v2.5.0), non da develop o main. Ciò garantisce che l’hotfix sia basato sullo stesso stato del codice attualmente in produzione e non incorpori modifiche non finite da develop.

Una volta completata la correzione, il ramo hotfix viene unito in main (o master) e develop. In main — un commit di merge normale con un nuovo tag di patch release (v2.5.1). In develop — un merge o cherry-pick, a seconda della politica del team. Se develop contiene più modifiche di main, si consiglia di eseguire il cherry-pick del commit hotfix specifico per evitare conflitti. GitFlow raccomanda di unire prima l’hotfix in main, e poi unire main in develop.

# Creare un ramo hotfix dall’ultimo tag di rilascio
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Applicare la correzione
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Unire in main e taggare il rilascio
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Unire anche in develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Pulire il ramo temporaneo
git branch -d hotfix/v2.5.1

Importante: se l’hotfix corregge un bug esistente nel ramo develop corrente (il bug è stato introdotto diversi sprint fa), allora dopo aver unito l’hotfix in main e develop, develop contiene già la correzione. Se il bug è stato introdotto solo nel ramo di rilascio (un errore accumulato tramite cherry-pick), la correzione in develop potrebbe non essere necessaria. L’analisi delle cause profonde aiuta a determinare se è necessario un cherry-pick in develop.

Rischi degli hotfix e come minimizzarli

Il principale rischio di un hotfix è l’introduzione di un nuovo bug più grave a causa della fretta. Secondo uno studio di Stripe (2021), il 15% degli hotfix causa una regressione e richiede un secondo hotfix. È la legge dell’ironia: più velocemente correggiamo, maggiore è la probabilità di sbagliare. La minimizzazione del rischio si ottiene limitando rigorosamente la dimensione del diff (non più di 30 righe) e test smoke automatici obbligatori.

Il secondo rischio — l’accumulo di debito tecnico. Se un team utilizza regolarmente hotfix invece di rilasci pianificati, la base di codice si degrada: i commit hotfix non vengono sottoposti a refactoring, le soluzioni temporanee non vengono sostituite con soluzioni adeguate, la documentazione non viene aggiornata. Controllo di salute: se gli hotfix vengono rilasciati più di una volta al mese — il processo di rilascio necessita di revisione.

Il terzo rischio è psicologico. Gli hotfix regolari esauriscono il team: gli sviluppatori di turno sono sotto stress costante, la revisione del codice diventa una formalità (tutti vogliono andare più veloci) e la cultura della qualità diminuisce. Una frequenza normale di hotfix per un team maturo è di 1–2 per trimestre. Se maggiore — il problema non è negli hotfix, ma nella qualità dei rilasci pianificati.

Cosa fare dopo un hotfix

Dopo aver distribuito un hotfix e stabilizzato le metriche, viene condotta una retrospettiva post-mortem senza colpa. Il team risponde a quattro domande: cosa è successo, perché i controlli non hanno rilevato il bug, cosa è stato fatto per correggerlo e come prevenirne la ricorrenza. Il post-mortem viene condotto entro 24–48 ore dall’hotfix, mentre i dettagli sono ancora freschi. La cultura senza colpa è un principio chiave: si discutono i processi, non le persone.

Il risultato del post-mortem sono azioni concrete con responsabili e scadenze. Azioni tipiche: aggiungere un test unitario per il caso mancato, ampliare la suite di test smoke, migliorare il monitoraggio (aggiungere un avviso sulla metrica), aggiornare il runbook per incidenti simili. Le azioni devono essere completate prima del prossimo rilascio pianificato.