La maledizione dell'aggiornamento dell'IDE

Una frenetica ricerca del lunedì per la causa e la cura è stata seguita martedì da una patch per risolvere un problema che ovviamente non era emerso durante i test. Non importa quanto siano buoni i tuoi test, scoprirai sempre che gli utenti reali e dal vivo faranno alcune cose in modo leggermente diverso da come hanno fatto i tester.

La maledizione dell'aggiornamento dell'IDE

Aggiornamenti del processo di sviluppo

Fino ad ora, il nostro controllo del codice sorgente e il monitoraggio del processo di sviluppo sono stati ospitati dal team di Microsoft Foundation Server 2008 (TFS), anche se alcuni progetti ancora attivi avevano addirittura iniziato la loro vita TFS2005.

Sebbene fossimo ragionevolmente soddisfatti di questi strumenti di gestione dei progetti, il software del flusso del processo di sviluppo mostrava decisamente la sua età. Il modello MSF Agile di Microsoft da TFS2005 era un po’ goffo e inflessibile. TFS2008 ha in qualche modo migliorato le cose, ma non abbiamo preso il coraggio di aggiornare diversi progetti di grandi dimensioni. Avevamo persino il codice sorgente di una miriade di piccoli progetti ancora presenti in un repository di Visual SourceSafe.

Abbiamo chiuso presto venerdì, abbiamo inserito tutto il codice SourceSafe in TFS2008, quindi abbiamo eseguito il backup del database TFS, aggiornato il nostro server a TFS2010 ed eseguito nuovamente il backup del database. Il nostro server TFS era una macchina virtuale che eseguiva ancora Windows Server 2003, quindi abbiamo effettuato il provisioning di un nuovo server virtuale con Windows Server 2008 R2, installato TFS2010 su quello e ripristinato il database dal server precedente sul nuovo. Lunedì mattina avevamo tutti i nostri progetti VSS e TFS2008 su un nuovissimo server TFS2010.

Ci sono molti modi in cui questo processo può andare storto, ma abbiamo dovuto fare seriamente marcia indietro solo una volta, quando abbiamo sbagliato l'ordine di installazione dei componenti e non siamo riusciti a ripristinarli. Avevamo previsto un simile incidente e stavamo effettuando il backup del file del disco rigido virtuale (VHD) per il server virtuale dopo ogni singola installazione o aggiornamento.

Questo è uno degli aspetti positivi della virtualizzazione: un backup è un lavoro di cinque minuti, non cinque ore

Questo è uno degli aspetti positivi della virtualizzazione: un backup è un lavoro di cinque minuti, non di cinque ore. L'altro vantaggio principale è stata la possibilità di effettuare il provisioning del nuovo server virtuale e di trasferirvi i dati prima di smantellare il vecchio server virtuale, senza dover acquistare nuovo hardware.

L'hardware fisico su cui erano in esecuzione questi server virtuali aveva molta capacità di riserva ma, se diventasse un po' limitato, sarebbe facile ridurre temporaneamente la capacità numero di processori virtuali o la quantità di memoria virtuale allocata a una qualsiasi delle macchine virtuali, mentre erano ancora necessarie sia le macchine virtuali vecchie che quelle nuove in esecuzione insieme. Ricordatevi solo di ripristinare tali allocazioni una volta che la vecchia macchina sarà definitivamente dismessa.

Per i vecchi progetti che avevamo da TFS2005, abbiamo creato nuovi progetti MSF Agile 5 e spostato i file sorgente nel nuovo progetto in modo da poter sfruttare le sue nuove funzionalità.

I progetti MSF Agile 5 sono molto simili ai progetti Scrum e seguono principi simili, catturando i requisiti come User Story scomposti in sottostorie sempre più piccole fino a definire una serie di attività necessarie per implementare quella funzione e i test necessari per confermarla lavori.

Tutte queste storie sono scritte dal punto di vista dell'utente e di solito iniziano dal modello “As a Voglio affinché ”. Questa struttura può aiutarti a pensare alla sicurezza e alle ragioni dietro l'obiettivo/requisiti e quindi evitare di scrivere "come codificare questa funzionalità" troppo presto nel ciclo di sviluppo.