Roberto Brunetti

Developing in the cloud

.NET Programming

Archives

Team System: Shelving ?

Mi è stata posta più volte questa domanda: cosa significa Shelve/Unshelve in VSTS ?

L'operazioni di shelving significa poter mettere su uno scaffale la versione corrente dei sorgenti su cui si sta lavorando per poi recuperarla in un secondo momento tramite l'operazione inversa Unshelve. L'idea è quella di salvare sullo scaffale la versione attuale per poter recuperare una build precedente su cui effettuare bug fix, aggiunte specifiche etc. Per evitare di perdere i sorgenti eseguendo il Get di una versione precedenti, si possono mettere progetti, file o l'intera solution sullo scaffale. Una volta risolti i bug si possono riprendere i sorgenti e continuare a lavorare. Durante ques'ultima operazione è anche possibile eseguire il merge delle modifiche (es. bug risolti) effettuate sulla build con le "cose" che avevamo lasciato sullo scaffale.

Lo scenario tipico e più semplice per capire questa operazione è il seguente:

1) Il 10 agosto abbiamo messo in produzione il codice 1.0 consegnandolo al cliente
2) Iniziamo a lavorare sulla nuova versione portando avanti un po' di sorgenti
3) Scopriamo un bug nella versione consegnata. Che fare ? Buttiamo via il lavoro attuale per riprendere i sorgenti 1.0, correggere i bug e riconsegnare il prodotto funzionante ? L'idea è
   3.1) Mettiamo i sorgenti in lavorazione sullo scaffale (Shelve)
   3.2) Riprendiamo la build 1.0
   3.3) Correggiamo i bug e facciamo check-in della build corretta
   3.4) Riprendiamo dallo scaffale i sorgenti e proseguiamo con il lavoro. Si può fare il merge delle modifiche che risolvevano il bug alla 1.0 sulla versione in lavorazione.

L'alternativa usata sui prodotti che non supportano Shelve/Unshelve è quella di sempre e potrebbe essere utilizzata al posto della tecnica decritta anche se risulta più complicato fare il merge: si fa un branch nuovo per ogni versione consegnata e continuiamo a lavorare sul branch principale. Quando arriva il bug (e tanto arriva prima o poi:-)) facciamo check-in della versione attuale nel branch principale, riprendiamo il branch della versione consegnata, correggiamo, check-in e poi riprendiamo il branch di lavoro.
Sicuramente l'operazione di shelve è più comoda (per il merge automatico delle modifiche) e soprattutto, visto che VSTS potrebbe imporre delle regole per fare check-in (es. deve essere compilabile, deve aver passato certi test, etc), potrebbe essere impossibile eseguire il check-in dei sorgenti su cui stiamo smanettando. Lo shelve evita una copia manuale dei vari progetti "da qualche parte".

Posted: set 03 2005, 04:25 by rob | with 3 comment(s)
Filed under:

Comments

Nice blog said:

Your blog is really very interesting.
# febbraio 23, 2006 7:05

ASP.NET Italiano Blogs said:

Nelle scorse settimane ho pubblicato questa serie di articoli introduttivi su VSTS 2010 e .NET 4.0. Visual

# dicembre 3, 2008 7:28

devcon2009 said:

DevCon 2009 sarà una conferenza di approfondimento sulla versione 3.5 del .NET Framework e di anteprima

# dicembre 7, 2008 12:51