Utilizzare Team Foundation Server con Visual Basic 6.0, Visual Studio .NET e Visual Studio 2005

Da Lorenzo Barbieri

Team Foundation Server è il nuovo prodotto di Microsoft per la gestione del codice sorgente, il controllo del progetto, il tracking delle funzionalità e dello stato dei bug e più in generale per gestire il ciclo di vita del software.

Grazie a questo strumento è possibile cambiare il modo di gestire i progetti software passando da una visione in cui il Project Manager deve controllare tutte le attività e occuparsi di tenere traccia di quello che sta accadendo, ad una visione più reattiva, in cui il Project Manager assegna le attività e poi lascia che Team Foundation Server gestisca gli avanzamenti e raccolga le informazioni necessarie a capire l’andamento del progetto direttamente dal lavoro di sviluppatori, tester, analisti, etc...

Team Foundation Server fa parte della famiglia Visual Studio Team System, con cui si integra tramite l’installazione sulle macchine client del componente chiamato Team Explorer.

C’è molta confusione riguardo all’utilizzo di Team Foundation Server da parte di altri prodotti della famiglia Visual Studio, in quanto molte persone credono a torto che questo non sia possibile.

Team Explorer è installabile indipendentemente da Visual Studio Team System, e può essere utilizzato in modalità indipendente. All’atto dell’installazione di Team Explorer (che non è integrato in Visual Studio ma va installato a parte utilizzando il CD di Team Foundation Server) il setup installa una versione di Visual Studio 2005 chiamata Visual Studio Premier Partner Edition che contiene solo le funzionalità base di Visual Studio (senza compilatori, editor, etc... ma solo la possibilità di contenere plug-in). Team Explorer richiede la presenza del .NET Framework 2.0, e del Document Explorer, che vengono installati se non presenti.

Il setup poi controlla se esiste una versione di Visual Studio 2005 (Standard o superiore) nella quale integrarsi. Se non la trova, l’utente utilizzerà la versione Premier Partner con il plug-in del Team Explorer, altrimenti il Team Explorer verrà integrato nell’IDE di Visual Studio 2005.

Utilizzo di Team Foundation Server da Visual Studio 2005

Il Team Explorer utilizzabile con Visual Studio 2005 Professional o Standard è lo stesso che si usa nelle versioni Team System. Tutte le funzionalità di visione e editing dei Work Items, l’integrazione con Windows Sharepoint Services (cartella Documents), l’integrazione con SQL Server Reporting Services (cartella Reports), la gestione delle Team Build e il Source Control sono esattamente gli stessi.

Figura 1

Figura 1

La differenza tra l’uso in Visual Studio 2005 Professional o Standard e l’uso all’interno delle versioni Team Sytem è la presenza delle funzionalità di integrazione disponibili solo con queste versioni:

  • Check-In Policy per la Code Analysis (disponibile con le versioni Team Developer e Team Suite)

  • Check-In Policy per i Test (disponibile con le versioni Team Developer, Team Tester e Team Suite)

  • Possibilità di editare le liste dei Test da utilizzare con la Team Build (disponibile con le versioni Team Tester e Team Suite)

  • Possibilità di salvare i risultati dei Load Test su Team Foundation Server (disponibile con le versioni Team Tester e Team Suite)

Esistono poi alcune funzioni disponibili su tutte le versioni Team System che non sono disponibili sulle altre versioni e riguardano la possibilità di creare Work Item direttamente a fronte di errori di compilazione, Unit Test o altri test falliti, popolando direttamente il Work Item creato (tipicamente di tipo Bug, ma è possibile creare ogni tipo di Work Item) con le informazioni sull’errore verificatosi (errore del compilatore, file, riga, etc...). Il tutto semplicemente selezionando col tasto destro l’errore e selezionando “Create Work Item”.

Queste ultime funzionalità sono replicabili su Visual Studio 2005 Professional e Standard tramite la creazione manuale dei Work Item, inserendo a mano le informazioni direttamente tramite il Team Explorer.

Provider MSSCCI per Team Foundation Server

Il team che si occupa dello sviluppo di Team Foundation Server ha rilasciato un tool che permette di collegarsi al sistema di Source Control da tutti gli ambienti di sviluppo compatibili con l’interfaccia MSSCCI.

Questi ambienti includono Visual Basic 6.0, Visual C++ 6.0, Visual Studio.NET, Visual Studio.NET 2003, Sql Server 2005 Management Studio, Delphi, PowerBuilder, e altri.

Questo tool è disponibile esclusivamente in lingua inglese. La versione 1.1 è scaricabile da qui.

Originariamente questo tool era fornito senza supporto, ma in seguito alle richieste dei clienti a partire da Settembre 2006 il tool è supportato ufficialmente.

L’interfaccia MSSCCI (si pronuncia “misski”) non ha la stessa ricchezza di funzioni esposte dal Team Explorer ma consente comunque di effettuare le operazioni di Check-In, Check-Out, Get Latest Version, Get Version, etc... esattamente come per i vecchi tool (Visual SourceSafe e altri). Il provider MSSCCI per Team Foundation Server gestisce anche l’assegnazione di WorkItem, delle Check-In Notes e consente di verificare la Check-In Policy di obbligatorietà di almeno un Work Item all’atto del Check-In.

Come si vede dalla Figura 2 il plug-in si integra nell’ambiente corrente (in questo caso Visual Studio .NET 2003) e dalla finestra dei Pending Checkins permette di gestire i Check-In esattamente come farebbe il Team Explorer (però in questo caso in una finestra separata).

Figura 2

Figura 2

Le seguenti funzionalità sono pienamente supportate dal provider MSSCCI per Team Foundation Server:

  • Check-In atomici – i file che vengono inviati a Team Foundation Server vengono messi tutti in Check-In oppure l’operazione fallisce. In questo modo si evitano problemi di aggiornamenti parziali.

  • Check-In Policy – Team Foundation Server supporta la verifica di Policy all’atto del Check-In che permettono di monitorare la qualità e verificare l’adempienza alle regole aziendali. Le segnalazioni delle Check-In Policy possono essere ignorate, ma in questo caso verrà tenuto traccia della mancata aderenza. Il provider MSSCCI supporta solo la Check-In Policy che verifica la presenza di almeno un Work Item associato al Check-In

  • Integrazione con i Work Item – L’interfaccia è assolutamente identica a quella di Team Explorer, come si vede in Figura 3. I programmatori possono assegnare i Work Item direttamente all’atto del Check-In, scegliendo di cambiargli di stato (Resolve) o lasciandoli nello stato corrente (Associate).

  • Check-In Notes – Anche in questo caso l’interfaccia è identica a quella di Team Explorer (Figura 4). Le Check-In Notes sono campi di testo che possono essere definiti a livello di Team Project, e che possono essere resi obbligatori. Attenzione che in questo caso non potrà essere possibile il Check-In se questi campi non sono stati compilati.

Figura 3

Figura 3

Figura 4

Figura 4

Funzionalità non supportate direttamente dal provider MSSCCI in versione 1.1, per cui bisogna ricorrere al Team Explorer:

  • Shelving e Unshelving – il Team Explorer permette di salvare i file sul Team Foundation Server senza dovere fare Check-In. In questo modo è possibile conservare il lavoro della giornata anche se questo non è ancora stato completato, senza memorizzare sul server una versione non terminata.

  • Lock sui file diversi da Check-Out esclusivo – Team Foundation Server supporta sia la modalità di Check-Out esclusivo, sia la modalità senza Lock, che permette a più utenti di modificare un file contemporaneamente. Quest’ultima modalità attualmente non è supportata dal MSSCCI provider.

  • Branching e Merging – Team Foundation Server basa la sua strategia di condivisione del codice e di gestione delle release sull’uso di Branch multiple contenenti diverse versioni (ad esempio Produzione, Test e Sviluppo) del codice. Fornisce poi strumenti per riunire e gestire il codice sorgente (Merge). Questa strategia è supportata dal provider MSSCCI ma nella versione 1.1 non è possibile gestire Branch e Merge direttamente, bisogna crearli da Team Explorer.

Il MSSCCI Provider si appoggia agli oggetti .NET esposti dal Team Explorer per comunicare con il Team Foundation Server. Il Team Explorer deve essere installato al momento dell’installazione del provider.

L’obiettivo del team di Team Foundation Server è quello di migliorare ed estendere il provider MSSCCI con nuove funzionalità nel corso del tempo, anche andando a coprire le funzionalità attualmente non presenti. Al momento della scrittura dell’articolo la versione disponibile è la 1.1. Eventuali versioni future potrebbero supportare anche le funzionalità mancanti a questa versione.

Utilizzo del provider MSSCCI da Visual Basic 6.0

Per poter utilizzare il provider MSSCCI da Visual Basic 6.0 bisogna aver selezionato al momento dell’installazione di Visual Studio 6.0 anche l’installazione della parte client di SourceSafe.

Questo per abilitare i menù corrispondenti in Visual Basic. Una volta installato il provider MSSCCI questo prenderà il posto del vecchio provider.

Utilizzo del provider MSSCCI da Visual Studio .NET e Visual Studio .NET 2003

Visual Studio .NET inseriva le informazioni sul provider di Source Control direttamente nei vari file di progetto. Se il progetto era contenuto inaltri sistemi di Source Control conviene rimuovere tutti i binding al vecchio provider e poi fare “Add to Source Control” direttamente da Visual Studio.

Se si lavora con ASP.NET bisogna porre attenzione anche all’interazione tra il Source Control e il mapping dei Web Project in IIS, come mostrato da questo articolo.

Con Visual Studio.NET bisogna prestare attenzione anche in caso di Branching effettuati tramite il Team Explorer, perchè bisogna andare ad aggiornare i binding delle soluzioni e dei progetti coinvolti nel Branching. Per cambiare il binding del progetto si può far riferimento a questo articolo.

Andare oltre il provider MSSCCI per Visual Studio .NET 2003

Per Visual Studio .NET 2003 è anche possibile avere tutte le funzionalità del Team Explorer direttamente all’interno dell’IDE utilizzando un plug-in a pagamento (di terze parti e quindi non supportato da Microsoft ma direttamente dal produttore).

Il plug-in si chiama TeamPlain for Visual Studio 2003 ed è disponibile esclusivamente in inglese.

Figura 5

Figura 5

Come si vede dalla Figura 5 tutte le funzionalità di Team Explorer sono state replicate, ad eccezione della Team Build.

E’ possibile vedere, creare e cancellare Work Item, interagire con i documenti, con i Report ed è anche disponibile una gestione del Source Control.

Questo plug-in richiede la presenza del Team Explorer installato sulla macchina.

Una funzionalità molto interessante di questo plug-in è la funzionalità di ricerca, come si vede in Figura 6:

Figura 6

Figura 6

La ricerca avviene sia sui Report, sia sui Work Item, ed è una funzionalità molto utile, che si affianca alla ricerca disponibile sui documenti memorizzati all’interno del portale Sharepoint Services.

La gestione dei Work Item è leggermente diversa da quella di Team Explorer, non fornendo un’interfaccia sovrapposta ma due finestre separate, una per le liste e una per i dettagli, come si vede nelle Figure 7 e 8:

Figura 7

Figura 7

Figura 8

Figura 8

La funzionalità di Source Control è molto avanzata, permettendo di effettuare anche le operazioni non supportate dal MSSCCI provider, come il Branching e Merging, lo Shelve, etc...

Figura 9

Figura 9

Il Source Control non è però integrato direttamente nella finestra di Pending CheckIn. Per quelle funzionalità bisogna utilizzare il MSSCCI provider che è compatibile con questo plug-in.

Convivenza del provider MSSCCI con altri provider di Source Control

Visual Studio 2005 fornisce la funzionalità di selezione del provider di Source Control da utilizzare. Le versioni precedenti invece non fornivano questa scelta. L’ultimo provider installato diventa il provider di default. Per poter cambiare provider bisogna intervenire nel Registry a Visual Studio chiuso.

Per semplificare l’operazione di selezione, esistono diversi programmi gratuiti che permettono di scegliere tra i provider MSSCCI installati, come quello mostrato in Figura 10:

Figura 10

Figura 10

Se si cambia provider quando Visual Studio è aperto bisogna chiuderlo e riaprirlo, perchè la chiave di registry viene letta alla partenza di Visual Studio e memorizzata per tutta la sessione di utilizzo.

Attenzione che quando si cambia provider bisogna anche cambiare gli eventuali binding al sistema di Source Control, per evitare problemi.

In Visual Studio 2005 non è possibile selezionare il provider MSSCCI per Team Foundation Server, ma bisogna per forza usare il Team Explorer (la scelta è disabilitata per evitare problemi).

Migrazione da Visual SourceSafe a Team Foundation Server

Molto spesso chi deve utilizzare Team Foundation Server con versioni di Visual Studio precedenti alla Visual Studio Team System ha già Visual SourceSafe come strumento di Source Control.

Con l’installazione del Team Explorer viene installato anche un tool da riga di comando chiamato VSSConverter che permette di analizzare i database di Visual SourceSafe e di effettuare poi la migrazione.

VSSConverter richiede in input un file XML con la definizione dei percorsi dei progetti Visual SourceSafe da migrare e dei percorsi dei Team Project di Team Foundation Server in cui inserire i sorgenti con tutta la storia pregressa.

Il VSSConverter utilizza un database SQL Server 2005 per contenere i dati durante la migrazione. Si può utilizzare l’istanza locale di SQL Server 2005 Express (se presente), oppure specificare un’istanza di SQL Server 2005 già esistente. SQL Server 2005 Express ha un limite di 4Gb per i dati, quindi se la mole di dati da migrare è superiore bisogna usare una istanza di una versione Standard o superiore.

Maggiori informazioni sul processo di migrazione possono essere trovate qui

Un consiglio è quello di avere un Team Project che contiene i file migrati da Visual SourceSafe, e di utilizzare un Team Project nuovo per ognuno dei progetti che si continua a sviluppare appoggiandosi a Team Foundation Server. In questo modo si evita il rischio di fare un Get Version dei file di binding che puntano ancora al vecchio ambiente.

Se si sceglie di usare i file migrati da Visual SourceSafe senza usare un altro Team Project, bisogna modificare i binding al sistema di Source Control, come mostrato in questo post in lingua inglese.

Bisogna prestare attenzione ad una serie di differenze tra Visual SourceSafe e Team Foundation Server che hanno conseguenze sul processo di migrazione:

  • Shared Files – non esistono più in Team Foundation Server. I file vengono copiati in ogni punto dove erano condivisi. Mantengono la versione coordinata nel processo di migrazione, ma poi, all’interno di Team Foundation Server perdono il legame. Lo Sharing di Visual SourceSafe va sostituito con il Branching in Team Foundation Server.

  • Pinning – l’operazione di Pinning di Visual SourceSafe era legata a quella di Sharing e anche questa non è più disponibile. Il tool di conversione assegna una label “PINNED” alla versione, per aiutare nell’identificazione. Bisogna però poi capire caso per caso come procedere (Branching, rimozione dei permessi di Check-In per simulare il Pinning, etc...)

Un ultimo punto da considerare riguarda i TimeStamp della conversione. Tutti i TimeStamp dei file convertiti corrispondono alla data della conversione. Il TimeStamp originale del file viene inserito nei campo commento.

Utilizzo della Team Build per compilare codice Visual Studio 6.0 o Visual Studio .NET

E’ possibile sfruttare il servizio di Team Build di Team Foundation Server (che va installato a parte) anche pr compilare progetti sviluppati in Visual Basic 6.0, Visual Studio .NET, etc...

Per farlo bisogna creare una Team Build fittizia utilizzando il Team Explorer, eventualmente utilizzando una soluzione “vuota” fatta con Visual Studio 2005 per sfruttare il Wizard.

Una volta creati i file di Team Build (o una volta copiati dei file di Team Build già esistenti) è possibile modificare la gestione dell’evento AfterCompile per eseguire il task Exec di MSBuild e lanciare la versione di Visual Studio (o di un altro compilatore) che si vuole utilizzare.

Un esempio di customizzazione del file è il seguente:

…
<Target Name="AfterCompile">

<Exec Command=""$(VS2003_Devenv)"
 "$(VS2003_SolutionName)" /build $(VS2003_Configuration)"/>

<MakeDir Directories="$(BinariesRoot)\$(VS2003_Configuration)"
Condition="!Exists('$(BinariesRoot)\$(VS2003_Configuration)')" />


<Copy SourceFiles="@(VS2003_OutputFiles)" DestinationFiles="@(VS2003_OutputFiles->'

$(BinariesRoot)\$(VS2003_Configuration)\%(RecursiveDir)%(Filename)%(Extension)')" />


</Target>
…

Maggiori informazioni possono essere trovate in questo post in inglese.

Utilizzando questa tecnica è possibile richiamare i compilatori Visual Basic 6.0, Visual Studio.NET, etc...

Conclusioni

Abbiamo visto in questo articolo che utilizzando Team Foundation Server come repository per il codice e come strumento per gestire il ciclo di vita del software è possibile continuare a utilizzare anche le versioni di Visual Studio precedenti alla Visual Studio 2005 Team System.

Una nota particolare merita il licensing di Team Foundation Server, che richiede una licenza CAL per ogni utente che non possiede una licenza di Visual Studio 2005 Team System.

Questo significa che se uno sviluppatore deve sviluppare sia con Visual Studio 2005 Team System, sia con Visual Basic 6.0 non ha bisogno di una licenza CAL, in quanto è coperto.


Mostra: