Visual Studio Team System 2010: primo contatto (parte 2)

Navigation

Home

Visual Studio Team System 2010: primo contatto (parte 2)

Dopo la prima parte ecco un altra serie di informazioni su VSTS 2010.

In Visual Studio 2005 e 2008 il processo di compilazione è demandato a MSBUILD; in prima battuta , avendo un compilatore esterno, è possibile eseguire operazioni di compilazione esterne a Visual Studio e schedularne l’esecuzione. Con l’arrivo della parte server (Team Foundation Server 2005 è uscito 6 mesi dopo rispetto alla Team Suite di VS 2005) il motore di MSBUILD è stato integrato nel processo di Team Build: una build è una operazione di compilazione server-side. MSBuild, da sempre è estendibile, nel senso che possono essere create task custom per effettuare operazioni aggiuntive rispetto alla semplice complilazione. MSBuild quindi, oltre a prendere in pasto i file .proj (VB, C#, DB) e produrre il rispettivo output, ha consentito al motore del Build Server di effettuare operazioni come il recupero dei sorgenti dal repository, l’assegnazione di Label per indicare la fase di compilazione sui sorgenti, il lancio di unit test e la pubblicazione del compilato nella directory outputdrop. In pratica tutto il processo viene eseguito tramite task di MSBuild.

I file .targets di MSBuild che contengono le attività devono essere modificati a mano per inserire attività aggiuntive: questo costringe spesso alla chiusura del progetto (unload da visual studio) e un editing manuale del file .proj per agganciare attività esterne, come ad esempio puntare ad un file .targets custom per lanciare i comandi su stsadm.exe nel caso di sviluppo di una soluzione SharePoint.

In Visual Studio 2010 si cerca di andare oltre: tutto il processo di build sfrutta Workflow Foundation (in versione 4.0) e fornisce quindi un designer molto semplice e intuitivo per compilare gli step di compilazione effettivi. Il flusso può contare su una serie di activity custom sviluppate appositamente per effettuare le operazioni che oggi MSBuild consente di fare, oltre alla normale serie di activiy come ad esempio Sequence, CallExternalMethod per gestire il flusso di lavoro.

Questa una immagine del designer

La sequenza delle attività viene impostate nel designer custom direttamente nella Build Definition. Nella Toolbox l’elenco delle activity out-of-the-box, che ovviamente può essere esteso con activity custom.

Si possono quindi usare le activity classiche (quelle che hanno scelto sono quelle sensate rispetto a cosa si fa nella build) ed esiste una activity per richiamare i “vecchi” task di MSBUILD consentendo di mantenere task custom create per l’attuale versione di Visual Studio.

Inoltre alcune activity possono essere chiamate in causa in modo condizionale rispetto al tipo di build che si fa: quindi il processo disegnato può essere lo stesso con alcune activity enabled solo se si fa un certo tipo di build (se siamo in continous integration oppure in build schedulata o ancora manuale possiamo definire nello stesso flusso cosa è attivo in ogni configurazione).

E’ veramente semplice gestire il tutto rispetto ai file .xml a mano.

Esistono poi due nuove tipologie di Build: Gated Check-in e ShelveSet Check-in.

Gated Check-in: ci si assicura di tutto prima di fare il check-in reale. Si stoppa il tutto se non va. E’ una pratica consolidata che non è però supportata nell’attuale versione e che parte dall’idea di invertire l’operazione di check-in e successiva compilazione. Prima si compila, si verificano le regole del Code Analysis, si lanciano i test e solo se tutto va a buon fine si esegue effettivamente il check-in. L’obiettivo è chiaro: evitare di mettere sotto SCC sorgenti che possono introdurre problemi. Ad oggi è possibile solo impostare alcune regole per fare check-in, ma costringono lo sviluppatore ad effettuare una operazione di CodeAnalysis e successivo lancio dei test prima di poter fare check-in.

Shelvset Build è l’altra nuiova opzione di build. Simile al gated come obiettivo, ma l’idea è questa: Si mettono le modifiche attuale in uno ShelveSet (gli shelveset sono presenti anche nella versione attuale di TFS e anche nella versione 2005) e tutto il processo di build lavora con i sorgenti dello shelveset. Al termine si fa il check-in se il codice non “rompe” la build.

Questa la finestra di gestione della build con le nuove modalità

Nel caso di Gated Check-in o ShelveSet Check-in, a fronte di una operazione di check-in appare questa maschera con cui si può decidere se effettuare la compilazione e la validazione prima dell’effettivo check-in.

Un’altra novità molto interessante è l’integrazione con Debugging History : il tool (si veda la sezione apposita) consente di registrare una operazione di debug in modo da poter rieseguire tutti i passi effettuati e tornare al punto dove sono stati trovati i problemi) senza dover rieseguire tutto il percorso a mano. Lo strumento memorizza anche tutte le informazioni che riguardano lo stato dell’applicazione durante la sessione di debug in modo da ripresentare la situazione completa e reale per poter investigare il tipo di problema risconstrato.

Build Controller: oggi è possibile configurare un solo build agent, il che costringe l’esecuzione del processo di build ad una sola macchina. In 2010 sono stati introdotti gli Agent Pool, gestiti da un Build Controller. In pratica si associa il Controller alla Build e il tutto viene fatto girare dai vari Agent configurati nel Pool.

Il Build Explorer presenta una nuova interfaccia che consente di effettuare le operazioni più comuni in modo semplice: ad esempio è possibile vedere il log completo direttamente da questa interfaccia senza aprire il famoso file di log .txt. Dal log è possibile accedere al codice che ha creato ad esempio un problema di compilazione. E’ possibile vedere le precedenti build dello stesso build type per analizzare la storia di una particolare build.

Ecco alcuni screenshot che si commentano da soli

Log espnso con indicazione di eventuali problemi

Come accennato, se ci sono problemi di compilazione, per ogni riga in errore è presente un link nel log per saltare direttamente al codice che causa il problema. Ad oggi occorre vedere gli errori e poi cercare il problema manualmente. Inoltre, il puntatore al codice, ci porta alla versione dei sorgenti che è stata compilata, non a quella presente nel nostro workspace che nel frattempo potrebbe essere cambiata n volte.

Si può effettuare un Delete di una Build e decidere cosa fare rispetto a tutti i dati della Build:

Anche nella maschera di gestione dei retention period si può decidere cosa fare non solo a livello di build come nella versione 2008, ma anche rispetto alle singole categorie di informazioni:

In ogni caso, giustamente, anche se si cancella una build restano comunque alcune informazioni nel database marcate come deleted; questo per evitare di perdere le info legate ai work item. Si possono cancellare ma a riga di comando: deve essere una richiesta esplicita.

Si possono impostare permessi molto granulari su chi può vedere i dati a livello di Build.

Web Access

Con il SP1 del 2008 è uscito il prodotto ufficiale (dopo l’acquisizione di TeamPlain).

La versione 2010 fa un salto in avanti sulla user interface sfruttando AJAX: l’interfaccia risulta più user friendly e veloce da utilizzare.

Fra le novità, la visualizzazione della gerarchia di workitem che rispetta la gerarchia di TFS, la possibilità di fare bulk edit di una proprietà da applicare ad una query di work item o a una multi-selezione di work-item. Quest’ultimo punto è molto utile quando occorre ad esempio riassegnare una serie di task ad un altro membro del team. Questa interfaccia risulta più funzionale anche rispetto ad Excel che oggi è lo strumento principe per fare bulk load di informazioni. Ecco la maschera di gestione del Bulk Edit in cui si assegna l’Area Northwind\UI e lo Stato di Resolved ad una serie di work item eselezionati

Se ci sono errori nel bulk edit si vede può controllare il progresso e eventuali problemi sui singoli work item (ad esempio la modifica non può essere applicata perchè lo stato non consente quel tipo di modifica)

In Excel, seppur comodissimo, occorre invece eseguire la modifica item per item (o con un find/replace...sempre molto pericoloso).

Molte delle componenti del Web Access sono costituite da Web Part: questo consente di riutilizzare parti della user interface in applicazioni custom basate su SharePoint o ASP.NET. A proposito di SharePoint, quando si crea un nuovo team project si può fare anche provisioning su SharePoint di alcune feature per creare la dashboard da customizzare.

TFS Migration & Sync

Migration:l’obiettivo è portare un altro sistema in TFS. Gli strumenti effettuano una importazione dei dati da altri sistemi. Esistono già strumenti di questo tipo per TFS 2008, primo fra tutti, lo strumento di migrazione da Source Safe.

Nella nuova versione però, nascono nuovi strumenti nativi che consentono di sincronizzare il contenuto di TFS con altri prodotti (ad esempio ClearCase) per consentire l’utilizzo di entrambi gli strumenti in contemporanea. Si pensi ad esempio alla migrazione di cui sopra: sto utilizzando un sistema di bug tracking, decido di passare a TFS, ma per un periodo di tempo dovrò ancora usare il “vecchio” sistema e tenere allineate le informazioni.

Su CodePlex trovate alcuni toolkit per applicare alcune di queste funzionalità anche a TFS 2008.

Molte informazioni che trovate in questo mio articolo e alcuni screenshot arrivano direttamente dai video che sono stati pubblicati nella Team System Week Videos di fine settembre 2008: http://channel9.msdn.com/posts/VisualStudio/Visual-Studio-Team-System-2010-Week-on-Channel-9/.

Sono appena arrivato a Los Angeles per Microsoft PDC 2008: se ci saranno altre informazioni in questi giorni su VSTS 2010 le includo nel prossimo articolo già previsto per la prossima settimana.

Allego tutti i miei post sulla versione 2005 e 2008 di VSTS/TFS come puntatori che spero siano utili

Architect.

• http://blogs.devleap.com/rob/archive/2005/12/29/6428.aspx

• http://blogs.devleap.com/rob/archive/2007/10/15/visual-studio-team-system-2008-architect-power-tools.aspx

• http://www.devleap.com/document.aspx?id=3837

• http://blogs.devleap.com/rob/archive/2006/09/24/14243.aspx

• http://blogs.devleap.com/rob/archive/2006/01/27/6584.aspx

• http://blogs.devleap.com/rob/archive/2005/12/29/6428.aspx

• http://blogs.devleap.com/rob/archive/2005/09/12/5706.aspx

Developer e Tester

• http://blogs.devleap.com/rob/archive/2008/09/10/vsts-2008-sp1-web-test.aspx

• http://blogs.devleap.com/rob/archive/2007/08/21/visual-studio-2008-for-mobile-dev-e-non-solo.aspx