Endgame

Cosa succede gli ultimi giorni prima del rilascio? Perché secondo alcuni l’RTM non è un punto nel tempo ma un intervallo di tempo? Provo a dare qualche risposta.

Chi controlla il rilascio di un software è principalmente il test team che firma (col sangue!) sulla qualità del prodotto ed infatti il test team è anche denominato Quality Assurance team. Le fasi di un prodotto si distinguono grosso modo in sviluppo, stabilizzazione e rilascio. Lo sviluppo introduce modifiche che causano bachi: questo di solito è tollerato entro certi limiti e tali limiti durante lo sviluppo di Windows 7 sotto la guida di Sinofsky sono stati ridotti di parecchio. Durante la pianificazione del prodotto si scelgono delle cut-off dates (in genere milestone) e se la feature non ce la fa ad essere codificata in tempo è fuori dal prodotto (feature fantasma, di cui pochissimo si sente parlare in giro).

Successivamente, la fase di stabilizzazione è quella in cui ci si concentra per la sistemazione dei neo-introdotti bachi (o qualche vecchio baco stagionato). I test automatizzati vengono completati e se qualche team dichiara di avere bisogno di più tempo per sistemare i bachi o completare il testing, la feature viene “processata”: in base al tempo richiesto, all’importanza della feature ed altri fattori astrologici viene deciso se la feature viene tagliata (postposta a nuove versioni) o meno valutandone il rischio di far slittare il rilascio. Ovviamente nel frattempo il test team individua nuovi bachi, i developer sistemano e ogni giorno viene generata una nuova build. Man mano che il tempo passa la barra dei bachi sale di livello: ad esempio si passa da “ogni team decide per se” al “tell mode” dove ogni team dichiara la propria mano all’ask mode, dove ogni team chiede il permesso di poter sistemare certi tipi di baco. Durante l’ask mode poi la barra può continuare a salire: alcune priorità vengono automaticamente scartate (esempio: bachi di priorità 3 o più bassa), altri bachi vengono “processati” e così via. Ovviamente trattasi di esempi, ma la costante è il fatto che periodicamente la bug bar viene alzata (o abbassata se si pensa ad una gara di Limbo). Durante tutto questo tempo la differenza tra una build e l’altra, a livello di bit, è così grande che gli stress test assumono un significato diverso da quello più tradizionale di stress test. Si cercano bachi che si verificano solo dopo lunghe sessioni di azioni ripetitive o meno (ortogonalmente: artificiali o meno) ma molti di questi vengono dichiarati “automagically fixed”.

Raggiunta la stabilizzazione comincia il vero e proprio rilascio: questo avviene con la prima build “abbastanza buona” che viene dichiarata escrow e si entra nell’escrow period, ovvero un periodo di tempo in cui quella build è garantita per la maggior parte delle funzionalità di essere equivalente a quella finale. Gli stress test entrano nel vivo, i bachi importanti continuano ad essere sistemati, ogni giorno viene generata automaticamente una nuova build e tutto fila liscio fino all’accadere di due possibili eventi:

nessun nuovo baco viene trovato
viene trovato un baco importante e con un impatto così elevato che bisogna resettare l’escrow, ovvero non si può più garantire con una certa confidenza statistica che la build che contiene la fix sia funzionalmente equivalente alla precedente, baco a parte of course

Nella condizione 2. il ciclo si ripete e si continua fino a quando non si esce dal ciclo tramite la condizione 1.

A questo punto la build è QUASI quella finale. Vengono sistemate le ultime cose (numero della build), viene interrotto il processo di generazione giornaliera delle build (nel ramo RTM of course) e si invita i vari team a fare il sign-off dei propri componenti. Il sign-off consiste nel fare le ultime verifiche durante le quali qualche baco potrebbe sempre fare capolino. Nel caso il baco sia molto importante sarà necessario generare una nuova build e in alcuni casi annullare il sign-off già cominciato. Il sign-off può richiedere un lasso di tempo che va da qualche ora per i prodotti più semplici a qualche giorno o settimana: si tratta di una vera e propria firma su un modulo Web e tutte le eventualità del caso possono accadere (malattie, assenze, ecc.). Ovviamente si può decidere che per alcuni bachi non vale la pena generare una nuova build oppure che vale la pena oppure che si approfitta della necessità di una nuova build richiesta da un altro team (piggy-back) per schiacciare gli ultimissimi bachi. Quando tutti i responsabili firmano il sign-off è fatta; alcuni stappano lo champagne, altri come il sottoscritto escono in corridoio a fare il ballo della banana.

Ora dovrebbe essere chiaro perché una build con qualche numero cabalistico (es. 7600) è condizione necessaria ma non sufficiente per la RTM; dovrebbe anche essere chiaro perché è impossibile prevedere con determinata precisione la data ufficiale di rilascio: ogni previsione ha una componente di rischio non indifferente che può portare ad interpretazioni diverse; e dovrebbe essere anche chiaro perché la build RTM è sempre vecchia di qualche giorno nel momento in cui viene dichiarata tale.

-quack

P.S. quello che ho scritto è valido in generale