Release candidate (RC): cos'è e come gestirla

Una release candidate (RC) è una build che il team ritiene pronta per il rilascio. Ha tutte le funzionalità, ha superato i test previsti e diventa la release finale senza modifiche, a meno che qualcuno non trovi un bug abbastanza grave da bloccarla. L’etichetta è una promessa sulla build: nessuna nuova funzionalità, solo correzioni dei blocchi. Se serve una correzione, il team crea una nuova candidata e fa ripartire il conteggio.

Cos’è una release candidate nel software?

È l’ultima fase di pre-release prima della disponibilità generale. L’idea è che la build sia una candidata alla versione finale, e che il rilascio avvenga promuovendo quella stessa build invece di crearne una nuova. L’articolo di Wikipedia sul ciclo di vita del rilascio del software descrive la stessa sequenza di alpha, beta, release candidate e release, e i termini sono ampiamente compresi nei progetti open source e tra i fornitori.

Qual è la differenza tra beta e release candidate?

Una beta può ancora cambiare. Le funzionalità si possono modificare, le interfacce si possono spostare, e l’obiettivo è capire cosa manca o cosa non va. Una release candidate ha smesso di cambiare in questi modi, e l’obiettivo è confermare che nulla blocca il rilascio. Il test pratico è cosa fa il team con la segnalazione di un bug. In una beta, una segnalazione può portare a una modifica di design. In una RC, una segnalazione porta a una correzione solo se il bug blocca il rilascio, e tutto il resto va in coda per la versione successiva.

Come si numera una release candidate?

Usa un suffisso di pre-release sulla versione che stai per rilasciare. Con il Semantic Versioning, un trattino seguito da identificatori separati da punti indica una pre-release, quindi la prima candidata per la 2.4.0 è 2.4.0-rc.1, la successiva è 2.4.0-rc.2, e il rilascio è semplicemente 2.4.0.

La precedenza segue la specifica: 2.4.0-rc.1 viene prima di 2.4.0-rc.2, e qualsiasi pre-release viene prima della release. Poiché gli identificatori si confrontano uno per uno e i numeri si confrontano numericamente, rc.10 viene dopo rc.9. Anche i nomi alpha, beta e rc si ordinano alfabeticamente nel modo giusto, ed è uno dei motivi per cui i team li usano. Metti un tag git su ogni candidata, come descritto in tag git e release, così il commit esatto resta registrato.

Quali sono i criteri di uscita di una release candidate?

Scrivili prima di creare la prima RC. Un insieme che funziona:

• La suite di test automatici passa sul commit esatto che è stato compilato.
• Il percorso di aggiornamento dalla release precedente è stato testato con dati realistici.
• I problemi noti sono stati valutati e nessuno è classificato come bloccante.
• Prestazioni e tasso di errori corrispondono alla release precedente entro un margine concordato.
• Le release notes sono in bozza e riviste rispetto all’elenco finale delle modifiche.
• Esiste un percorso di rollback e qualcuno l’ha letto.

Quando ogni riga è vera per una candidata, quella candidata è la release. Se una riga fallisce, la correzione produce una nuova candidata e i controlli ripartono. La versione in sette passi di questo flusso, con i responsabili di ciascun passo, è in processo di release management.

Cosa fare con la build quando una RC passa?

Promuovi lo stesso artefatto. Non ricompilare dal tag, perché una ricompilazione può portare dentro una dipendenza diversa o un output diverso del compilatore, e i test che hai fatto valevano per la build originale. Molti team rinominano la candidata cambiando il tag o riposizionando un’etichetta del registro, così i byte testati sono quelli che gli utenti scaricano.

Per i pacchetti, pubblica le candidate su un canale separato, così gli utenti normali non le ricevono per caso. Con npm, npm publish --tag rc lascia il tag predefinito latest dov’è, e solo chi chiede @rc ottiene la candidata. Le immagini dei container e le build mobile hanno la stessa idea con altri nomi: un tag di pre-release, un rilascio graduale o un canale in stile TestFlight.

Come si scrivono le release notes di una release candidate?

Inizia le note dalla prima RC e tienile allineate con le candidate. I tester devono sapere cosa è cambiato, cosa controllare e cosa è noto come rotto, e scrivere in anticipo fa emergere le voci che alla fine nessuno ricorda. Segna la pagina o la release di GitHub come pre-release, così nessuno la scambia per la versione finale, e sposta il testo definitivo sulla release GA quando esce. Struttura e contenuti sono in release notes software, e il lato GitHub è in GitHub release notes.

I team SaaS hanno bisogno delle release candidate?

I team che fanno deploy continuo raramente ne hanno bisogno, perché il deploy in produzione è il test e un feature flag controlla chi vede una modifica. Le release candidate si guadagnano il posto quando gli utenti installano il software da soli e non si può tornare indietro con un deploy: librerie, app desktop e mobile, prodotti self-hosted e API con client di lunga durata. Per un prodotto ospitato che espone le modifiche gradualmente, l’equivalente è un rilascio graduale, che l’articolo sulle release notes con feature flag tratta dal lato della comunicazione.

FAQ

Cosa significa RC nel software? RC sta per release candidate. È una build che il team intende rilasciare come versione finale, a meno che i test non trovino un bug bloccante. Segue le fasi alpha e beta e precede la disponibilità generale.

Una release candidate è abbastanza stabile per la produzione? Di solito sì per i test in staging o in una produzione limitata, e porta un rischio che la release finale non ha, perché i test potrebbero non essere finiti. Trattala come codice di qualità da produzione ancora in prova.

Quante release candidate dovrebbe avere una release? Quante ne servono, e la maggior parte delle release ne richiede da una a tre. Una lunga serie di candidate di solito significa che il congelamento è stato dichiarato troppo presto o che la copertura dei test sta scoprendo i problemi in ritardo.

Una release candidate può diventare la release finale senza modifiche? Sì, ed è l’esito previsto. La release finale dovrebbe essere la stessa build dell’ultima candidata, solo rinominata o rietichettata come GA.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Modello di release notes