Spesso nello sviluppo di un software è necessario effettuare l’upgrade di componenti o framework presenti nella propria soluzione, fase che è poi seguita da compilazione e testing dell’applicativo per identificare eventuali problemi di natura tecnica o funzionale. Naturalmente queste operazioni vengono eseguite sulla macchina locale, prima di condividerle sulla main con gli altri sviluppatori.
[fonte: http://www.extremeprogramming.org/rules/spike.html]
Poniamo ad esempio, che vogliamo aggiornare la versione di Entity Framework nel nostro progetto, ma vogliamo essere sicuri di non andare incontro a qualche breaking change. Se l’aggiornamento ha esiti positivi, possiamo promuovere il codice alla nostra linea principale. Nell’eventualità che queste modifiche non vadano a buon fine, in genere il codice viene eliminato.
Questa operazione viene definita come Spike, termine coniato in Extreme Programming.
Lo spike in genere si usa nei seguenti casi:
– Codice per testare nuovi framework o tecnologie;
– Codice per isolare e testare bugs che si sono verificati in un framework o una libreria;
– Codice one-time shot, come nei casi di importazione massiva di dati da effettuare un’unica volta;
Poiché l’intero processo si basa sul testare o ritestare il proprio applicativo,gli spike sposano benissimo la metodologia Test Driven Development, perché in questo modo, dopo aver aggiornato il proprio progetto o è possibile creare un pò di unit test per le user story, oppure rieseguire l’insieme di unit test già presenti per verificare eventuali problematiche.
In Team Foundation Server non esiste alcuna funzionalità che prende il nome di spike, anche se però esiste qualcosa che si avvicina al concetto di base: la Shelveset.
La Shelveset è un’area che può essere utilizzata per diversi motivi:
Interruzione momentanea del lavoro;
Condivisione del proprio work in progress con un altro membro del team;
Code review;
– Build e automazione prima del check-in;
– Backup.
Per creare una Shelveset in Team Foundation Server basta selezionare la voce Shelve all’interno della sezione Pending Changes nel Team Explorer. E’ sufficiente dare un nome ed un eventuale commento.
Una importante scelta che occorre fare in questa fase è selezionare o no la voce “Preserve Pending Changes Locally”. Tramite questa opzione possiamo scegliere se lasciare le modifiche nel nostro workspace (selezionata) oppure rimuoverle se ad esempio dobbiamo lavorare sugli stessi file a cui abbiamo apportato delle modifiche.
Se abbiamo necessità di condividere queste modifiche con un altro utente, possiamo utilizzare nel menù Actions della stessa sezione del Team Explorer la voce “Find Shelveset”. Da qui possiamo filtrare tramite il nome utente e cercare la Shelveset di nostro interesse.
Poiché in TFS 2013 è stato aggiunto il supporto a Git, pare opportuna la domanda su come gestire le spike con questo DVCS. In sostanza, se usiamo Git come repository, purtroppo non abbiamo la voce Shelve, ma il meccanismo che possiamo usare per gli spike sono i branches. Quindi quello che facciamo nel momento in cui abbiamo il nostro spike, è creare un nuovo branch in fase di commit:
Dopo aver pubblicato il branch, abbiamo la possibilità di continuare a lavorare e di dare la possibilità anche ai nostri colleghi di poter lavorare direttamente dal branch.
Più un generale, l’uso dei branches può essere applicato anche se si usa il TFVC. Questo facilità sicuramente la possibilità di creare e condividere ai colleghi il proprio codice che si sta testando, per poi promuoverlo alla linea principale attraverso il meccanismo di merging (occhio come sempre ai permessi che hanno gli utenti sul branching e merging). In genere si può adottare una organizzazione delle cartelle di questo tipo:
– MioProgetto
– dev (folder)
– feature1 (branch)
– feature2 (branch)
– feature3 (branch)
– main (branch)
– blackOps (folder)
– EF6 (branch)
– NHibernate (branch)
– ELibLogging (branch)
– releases (folder)
– v1 (branch)
– v1 HotFix (branch)
– v1 sp1 (branch)
In questo caso ho usato come nome della cartella BlackOps, ma qualsiasi altro nome come Spike va benissimo.
Generalmente una spike viene eliminata se non raggiunge il suo scopo. In diversi casi però è consigliato conservare queste porzioni di codice. Alcune ragioni valide le potete trovare nei seguenti post:
Enjoy it! 
Login