Esporta (0) Stampa
Espandi tutto

Branching Strategy e tracciabilità con Team Foundation Server 2012

di Matteo Emili - Microsoft MVP

JJ573928.7B654F178A3842F7F616A829DC6DF588(it-it,MSDN.10).png

Luglio, 2012





Parte essenziale del ciclo di vita del software è il trattamento dei requisiti e la loro trasformazione in funzionalità del software che verrà poi rilasciato, oltre alla creazione dell’albero del Source Control nel modo più adeguato alle esigenze del team di sviluppo.

Storicamente si può approcciare la Branching Strategy in diversi modi:

  • Branch per Feature
  • Branch per Release
  • Branch per Team
  • Branch per Maintenance

Nella Branch per Feature si creano ramificazioni basate sulle feature da implementare, per poi reintegrarle nella Development line.

Nella Branch per Release si adotta un approccio di branching per ogni release che viene sviluppata. E’ molto efficace in contesti agili, come con Scrum, in quanto si basa su rilasci molto ravvicinati e frequenti.

L’approccio di Branch per Team si utilizza quando si hanno molti team piccolo da far lavorare senza essere soggetti a modifiche sostanziali nella loro sezione, oppure che possono lavorare in parallelo verso obiettivi unici.

Infine la Branch per Maintenance è un approccio molto efficace nei casi di manutenzione di codebase legacy, in quanto non destabilizza ciò che è preesistente.

Ognuno di questi approcci ha dei pro e dei contro, che vanno valutati a seconda del progetto sul quale si sta lavorando, su quale processo è basato, quali sono le restrizioni, etc. Ci sono però delle regole fisse consigliate, che vanno oltre la Branching Strategy che sceglieremo di seguire.

Molto semplicemente, lo scheletro di qualunque Branching Strategy dovrebbe seguire il seguente flusso:

JJ573928.90578573304A44CE7D5C44908605FD89(it-it,MSDN.10).png

Dove all’interno di Dev deve essere presente tutto ciò che è sviluppo, quindi instabile, ed all’interno di Release soltanto il codice stabile e prossimo al rilascio (e poi rilasciato).

Tracciabilità mediante Work Item

Essendo Team Foundation Server una soluzione di Application Lifecycle Management e non solamente un Version Control System, mette a disposizione una serie di strumenti per la tracciabilità delle attività, di cui il principe è ovviamente la funzionalità di Work Item Tracking.

Un Work Item mette a disposizione diverse varianti di attività a seconda del Process Template scelto.

MSF for Agile Software Development 6.0

JJ573928.DFD2085B7EAE5300D835EA4D05C77454(it-it,MSDN.10).png

MSF for CMMI Process Improvement 6.0

JJ573928.87AC4203C5590CC3D478E2DC86E85107(it-it,MSDN.10).png

Visual Studio Scrum 2.0

JJ573928.D3437A2D5224C3B15719CAED1B8D7E21(it-it,MSDN.10).png

Ogni Work Item è completamente customizzabile, e permette di trasformare tutti i requisiti, i bug, e i task in qualcosa di integrato nel sistema. Inoltre supportano le gerarchie, quindi è possibile replicare in modo fedele tutto quello che fino ad oggi è stato “su carta”.

Prendendo ad esempio un progetto basato su Visual Studio Scrum 2.0, avremo un Product Backlog con diversi Product Backlog Item, ossia dei Work Item di alto livello che definiscono i requisiti del nostro progetto.

JJ573928.E194F7913F4C69B778039E2A4DEBB785(it-it,MSDN.10).png

In un PBI abbiamo tutte le informazioni relative al requisito in oggetto. I campi a disposizione permettono di identificare in modo chiaro ed immediato a chi è assegnata l’attività, quali sono i criteri di accettazione e validazione, una descrizione dell’attività da svolgere, e svariate altre informazioni.

A partire da un PBI, posso creare nuovi Work Item linkati, in modo tale da creare e replicare una gerarchia di informazioni.

JJ573928.A0D2A3715D5332345FA19BF6C437B764(it-it,MSDN.10).png

Ed ovviamente è visualizzabile dalla scheda Tasks del PBI, che riepiloga tutti i Work Item collegati ad esso.

JJ573928.78838CF72A442354EA885C258602361C(it-it,MSDN.10).png

E’ possibile collegare non solo task con rapporto gerarchico padre-figlio, ma anche con una serie di attributi che permettono di replicare in modo fedele i vari rapporti fra gli attori del progetto

JJ573928.35A4F90BF923CFDD90D2B3E69BEBBE19(it-it,MSDN.10).png

Il legame con le branch

Potendo collegare i Work Item con i check-in, è quindi possibile tracciare l’evoluzione del progetto. In questo modo ad ogni operazione è collegata un’attività, ed è facile gestire processi di deployment e fix, oltre al normale sviluppo del software.

JJ573928.ED3D22DD9AC662E600ACEF0DFABE6073(it-it,MSDN.10).png

Utilizzando invece la funzionalità di Changeset Tracking possiamo verificare in modo visuale l’evoluzione e la vita di un check-in all’interno del progetto. Ad esempio, una funzionalità può essere portata in produzione con una Branching Strategy di tipo Branch per Feature, ed avere questo flusso:

JJ573928.5473556C661E917DE3BAB46B0BE1D779(it-it,MSDN.10).png

Visualizzazione gerarchica del Changeset

JJ573928.BFAB148DEC1028A8282837985713273F(it-it,MSDN.10).png

Visualizzazione temporale del Changeset

L’uso delle funzionalità di tracking all’interno di Visual Studio permette una rapida ed efficace identificazione del flusso avvenuto all’interno del progetto, che utilizzati unitamente ad altri strumenti come la History e l’Annotate aumentano la qualità generale e diminuiscono la probabilità di errori durante le fasi di branch e merge.


di Matteo Emili - Microsoft MVP



Altri articoli di Matteo Emili nella Libreria JJ573928.91D39A44647D350E2B58070202FCA1FD(it-it,MSDN.10).png





Mostra:
© 2014 Microsoft