Feature freeze e code freeze nello sviluppo di app: essenza, differenze e ruolo

Cos'è un feature freeze?

Feature freeze è un divieto temporaneo di aggiungere nuove funzionalità alla base di codice, introdotto prima di un rilascio pianificato. Il team smette di unire funzionalità e si dedica alla correzione di bug, all'ottimizzazione e al perfezionamento del codice esistente. Gli sviluppatori completano le funzionalità incomplete solo nell'ambito delle correzioni di bug, senza espandere l'ambito.

Il feature freeze risolve il problema delle funzionalità in corso (work-in-progress) che non arrivano al rilascio ma sono già state parzialmente unite nel ramo principale. Se le nuove funzionalità continuano a essere unite, aumenta il rischio di regressione: ogni nuova integrazione richiede il ritest dei moduli già completati. Feature freeze fissa l'ambito del rilascio, trasformandolo da un bersaglio mobile in un insieme stabile di funzionalità.

Un chiarimento importante: feature freeze ≠ code freeze. Durante un feature freeze, sono consentiti correzioni di bug, refactoring, aggiornamenti delle dipendenze e documentazione. Sono vietate solo le nuove funzionalità visibili all'utente, ovvero qualsiasi codice che modifichi il comportamento dell'applicazione dal punto di vista dell'utente. Verifica nella code review: se una PR aggiunge una nuova schermata, pulsante o metodo API, viene respinta fino alla rimozione del congelamento.

Cos'è un code freeze e in cosa differisce dal feature freeze

Code freeze è una pratica più rigorosa in cui tutte le modifiche al codice sono completamente vietate. Anche le correzioni di bug non sono consentite a meno che non siano critiche. Il code freeze viene introdotto per un breve periodo (di solito 24-48 ore) e garantisce che la build di rilascio sia assemblata da un insieme fisso di commit.

La differenza tra feature freeze e code freeze risiede nel livello di controllo. Il feature freeze gestisce l'ambito: cosa esattamente sarà incluso nel rilascio. Il code freeze gestisce la qualità: elimina il rischio di introdurre un nuovo bug il giorno prima del rilascio. In pratica, molti team utilizzano un modello a due fasi: 1-2 settimane prima del rilascio, feature freeze; 24-48 ore prima, code freeze. Code freeze è particolarmente rilevante per le app mobili, dove la build deve essere caricata nello store diversi giorni prima della data di rilascio pianificata.

L'eccezione al code freeze riguarda le correzioni di sicurezza per vulnerabilità critiche (CVE con punteggio 9+). Tali modifiche passano attraverso un processo di emergenza con revisione del codice accelerata obbligatoria e notifica al team. Tutte le altre modifiche vengono rimandate al prossimo ciclo di rilascio.

Feature freeze vs code freeze: confronto

La scelta tra feature freeze e code freeze dipende dalla maturità del team e dalla frequenza dei rilasci. I team con CI/CD e feature flags possono aver bisogno solo di un code freeze di 24 ore, mentre i team con rilasci mensili spesso utilizzano entrambi i congelamenti in sequenza.

Tipi di congelamenti: totale, parziale e BAU-freeze

Oltre al feature freeze totale e al code freeze, esistono opzioni più flessibili. Partial feature freeze (congelamento parziale) blocca le nuove funzionalità solo in determinati moduli, ad esempio nel modulo di pagamento o nel modulo di autorizzazione, lasciando gli altri componenti aperti alle modifiche.

BAU-freeze (business as usual freeze) è un'opzione di compromesso in cui vengono vietate solo le grandi funzionalità con un volume di modifiche superiore a una certa soglia (ad esempio, 500 righe di codice). I miglioramenti minori, le regolazioni dell'interfaccia utente e le correzioni di bug continuano a essere uniti. BAU-freeze è comodo per progetti con distribuzione continua, dove un arresto completo dello sviluppo per una settimana non è economicamente sostenibile.

Esiste anche il concetto di deployment freeze (congelamento della distribuzione) — un arresto completo delle distribuzioni in produzione, tipico per la stagione delle festività (vacanze di Natale, Black Friday). Durante questo periodo, anche gli hotfix vengono bloccati a meno che non siano legati alla sicurezza. Il deployment freeze dura di solito 1-2 settimane ed è coordinato a livello aziendale.

Quando introdurre un congelamento e quanto dura

Il momento ottimale per introdurre un feature freeze è dopo il completamento del codice, quando tutte le funzionalità pianificate sono state unite e sono in QA. Il momento esatto dipende dal ciclo di rilascio: per uno sprint di due settimane, il feature freeze viene introdotto 3-4 giorni prima della data di rilascio; per un rilascio mensile, 7-10 giorni prima. Code freeze viene introdotto 24-48 ore prima dell'orario pianificato di compilazione della build di rilascio.

La durata del congelamento dovrebbe essere il minimo sufficiente per stabilizzare il codice. Un congelamento troppo lungo (più di 2 settimane) demotiva il team e crea un accumulo di funzionalità non unite, ciascuna delle quali aumenta il rischio di conflitti dopo la rimozione del congelamento. Un congelamento troppo breve (meno di 24 ore per un feature freeze) non lascia abbastanza tempo per test e correzioni approfonditi.

La pratica consigliata è di impostare il congelamento non per data di calendario ma per stato della base di codice. Il feature freeze viene introdotto quando il numero di bug aperti per il rilascio supera una soglia (ad esempio, 10 bug critici). Code freeze — quando la build supera con successo i test di fumo e la suite di regressione. Time-based freeze (data fissa) rimane lo standard per i settori regolamentati (fintech, medtech) in cui la data di rilascio è approvata da un regolatore.

Automazione dei congelamenti tramite CI/CD e Git

Il controllo manuale dei congelamenti è una fonte di errori: uno sviluppatore potrebbe accidentalmente unire una PR che dovrebbe attendere la rimozione del congelamento. L'automazione risolve questo problema tramite regole di protezione dei rami Git e pipeline CI/CD. Nel fornitore Git (GitHub, GitLab, Bitbucket), vengono configurate regole che bloccano le unioni nel ramo di rilascio senza un tag speciale o l'approvazione del release manager.

Pipeline CI/CD verifica lo stato del congelamento prima di compilare la build. In Jenkins, GitLab CI o GitHub Actions, viene aggiunto un passaggio che legge un file di configurazione con il calendario dei congelamenti e rifiuta le build se la data corrente cade nel periodo di congelamento. Un'alternativa è un feature flag nel pannello di amministrazione che blocca la distribuzione in produzione.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

Lo script di esempio freeze-check.js legge un JSON con il calendario dei congelamenti dalla radice del repository. Se la data corrente cade nell'intervallo tra start_date e end_date per il ramo specificato, la pipeline fallisce con un messaggio sullo stato del congelamento. Git branch protection aggiunge una seconda barriera: anche se la pipeline non si è attivata, la regola non consente di unire la PR senza approvazione.

Errori comuni nell'implementazione dei congelamenti

Il primo errore è un congelamento senza criteri chiari di rimozione. Il team congela il codice ma non definisce quali condizioni devono essere soddisfatte per scongelare: zero bug critici, suite di regressione superata, approvazione del product manager. Senza criteri, il congelamento può protrarsi per settimane. La definizione di completamento per il congelamento dovrebbe essere documentata e nota a ogni sviluppatore.

Il secondo errore sono troppe eccezioni al congelamento. Ogni eccezione (“questa PR non è una funzionalità, è debito tecnico”) offusca il confine del congelamento. Se le eccezioni superano il 20% del flusso normale di PR, il congelamento non funziona. Il team semplicemente rinomina le funzionalità come correzioni di bug per aggirare il blocco.

Il terzo errore è ignorare i release candidate. Se il team non costruisce build candidate di rilascio e distribuisce direttamente in produzione dopo il code freeze, lo scopo del congelamento viene perso: i bug vengono scoperti dagli utenti. Il release candidate dovrebbe essere costruito prima del code freeze, testato da QA e in staging, e solo dopo la conferma della qualità viene introdotto il code freeze.

Il quarto errore è il fattore umano nel controllo manuale. Uno sviluppatore potrebbe dimenticare di verificare lo stato del congelamento prima dell'unione, un release manager potrebbe perdere una notifica. L'unica soluzione affidabile è il blocco automatico a livello del fornitore Git o CI/CD, eliminando l'errore umano.