Team System @ University Have you ever heard about Team Foundation Server?

Team Foundation Server: Build Automation

L’articolo di oggi parlerà dei servizi di Build Automation di Team Foundation Server.

Ma facciamo un passo indietro…cosa succede quando premiamo F5 in Visual Studio?

Uno script (.proj, .vbproj, .csproj, .btproj, ecc.) viene fatto processare ad MSBuild, che in una serie di task richiama il compilatore, gli passa i files, ecc. Il cuore della compilazione con Visual Studio si basa su MSBuild. Con Team Foundation Build le cose sono relativamente simili:

Come sempre al centro di tutto c’è il data warehouse SQL Server. Li vengono salvati tutti i dati, logs, vengono creati i reports. Una volta lanciata la Build, vengono scaricati i sorgenti dal data warehouse, inizializzati i compilatori, ed in generale vengono compiuti tutti i passaggi di una compilazione classica. Nel caso la build fallisse, viene aperto un Work Item di tipo Bug, quindi il concetto di tracciabilità è esteso anche qui.

Nella versione 2010 (che non tratto ora) verranno introdotte una serie di novità di cui la più importante riguarda il nuovo motore, basato su Windows Workflow Foundation. Per ulteriori informazioni vi rimando al mio blog su Ugidotnet, dove postai queste cose nel dettaglio.

Il fulcro della Build Automation è una coppia di entità che lavorano insieme: Build Definition e Build Agent. La definizione della build indica parametri come i triggers (ossia quando una build deve partire, se ad intervalli precisi oppure ad ogni check in, ad esempio) oppure le Retention Policies, cioè quando mantenere i risultati di build in base ai risultati.

 

Il Build Agent invece indica dove la build debba essere eseguita (questo perchè la Team Build è installabile anche su macchine dove non è presente Team Foundation Server), se è abilitato o meno e soprattutto la locazione dove debba essere lasciato il risultato di build. Attenzione a scegliere in maniera oculata la Working Directory, in quanto il limite di caratteri per il path è di 260.

Se abbiamo una batteria di test sul codice, Team Build li esegue in maniera automatica, oltre a Code Coverage (copertura percentuale del codice testato sul totale), Code Analysis (analisi del codice in relazione a delle regole di stile di Microsoft. Nella versione 2010 ci saranno tantissime novità nella Code Analysis, con diversi set di regole tra cui scegliere) e Code Metrics, ossia delle regole di aderenza a dei parametri come la manutenibilità, le dipendenze, l’ereditarietà, ecc.)

Per approfondire la conoscenza di MSBuild e Team Build non posso che consigliare quello che io reputo il miglior testo in assoluto, ossia Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build.

Nel prossimo articolo analizzeremo nel dettaglio la tracciabilità dei Work Item.

Team Foundation Server: Source Control

E’ il turno del Source Control

Come detto in precedenza, il Source Control di Team Foundation Server è basato su un data warehouse in SQL Server. Ciò elimina la problematica relativa al backup, in quanto basta un semplice backup plan in SQL Server per salvare tutto.

A livello di permessi, abbiamo due principali categorie (comunque è tutto customizzabile a piacimento): Contributor e Administrator. Il Contributor rappresenta l’utente. L’Administrator ha in più la possibilità di modificare policies, accessi, configurare l’ambiente e, soprattutto, di creare e cancellare progetti. Un progetto in TFS non è solamente il codice, ma è un contenitore nel quale si inseriscono anche i reports, le build, ed i portali.

Questo è il Source Control Explorer, ossia l’area del Team Explorer deputata alla gestione del sorgente. Notiamo il Local Path: quello è il percorso che associa il nostro Workspace al percorso locale. Questa associazione è molto importante, perchè sarà il punto di riferimento per TFS sulla “locazione” dei nostri files. Ovviamente può cambiare da macchina a macchina, in quanto cambia il workspace stesso.

Le operazioni principali sono:

• Get Latest (Specific) Version
• Check Out for Edit
• Check In
• Shelve (ed Unshelve)
• Branch
• Merge

Vediamo nel dettaglio ognuna di cosa si occupa.

Get Latest (Specific) Version
Questo è il comando che ci permette di ottenere i file del progetto. Il Get Latest Version scarica nel nostro Workspace l’ultima versione del file (o del progetto, della cartella, ecc.) selezionato. Invece il Get Specific Version, scarica una precisa versione della nostra selezione, in base ai seguenti parametri:

• Data / Ora
• Changeset (dopo vedremo di cosa si tratta)
• Label (un’etichetta che possiamo apporre ai sorgenti, ad indicare qualcosa di particolare)
• Workspace (l’ultima versione di un selezionato workspace, non necessariamente il nostro)
  

Check Out for Edit
Applica il permesso di scrittura sulla selezione, una volta mappata sul workspace ed esistente localmente.

Check In
Essendo il lavoro con TFS transazionale, ogni modifica che noi facciamo al codice, anche salvando, non viene inserita nel server, ma viene accumulata nei “Pending Changes”. Il Check In esegue il salvataggio dei files sul server. Ogni Check In può essere associato a dei task o dei bug, in modo da rendere tracciabile il lavoro svolto. Contribuisce molto a questo il concetto di Changeset: ogni Check In è composto da un gruppo di files con allegate delle informazioni, che vanno dal timestamp ai commenti del Check In, fino ad eventuali policies applicate (è possibile rendere obbligatori i commenti ad esempio). I Changeset rendono completamente tracciabile il lavoro svolto, specialmente se legato a dei task o meglio ancora, com una policy di commento obbligatorio.

Shelve (Unshelve)
Esegue il salvataggio dei files sul server, ma non sulla baseline di codice dei Check In. Sostanzialmente è (fedelmente al nome, “mensola”) una possibilità di mantenere sul server anche dei files su cui magari stiamo lavorando, o abbiamo fatto delle modifiche non testate, senza però toccare il codice stabile e testato. Ciò è molto comodo per evitare di perdere del lavoro a causa di danni all’hard disk della macchina di sviluppo, ad esempio. L’Unshelve è l’operazione opposta, recupera i files dallo Shelve e permette di lavorarli in locale.
Si introduce quindi il concetto di Shelveset, analogo a quello dei Changeset, solo che qui non c’è effettivamente una modifica del codice principale, ma solo un salvataggio temporaneo.

Branch
L’operazione di Branch permette di creare un ramo dalla baseline di codice sorgente. Un esempio è quello delle versioni di un software. Immaginiamo di avere una RTM, versione 1.0. Possiamo fare un branch per iniziare lo sviluppo della versione 2.0 e continuare la manutenzione sulla versione 1.0. Ma il Branch è comodo anche per degli scenari di prova, in cui si deve stravolgere la soluzione per un periodo di tempo più o meno lungo, oppure in uno sviluppo Alpha-Beta-RC cadenzato.

Merge
Operazione opposta del Branch. Applica le modifiche da un Branch ad un altro (o alla baseline)e li fonde insieme.

Quando andiamo ad eseguire il Check In, potrebbe capitare di avere dei dati in conflitto. Con l’aiuto del comparatore di Visual Studio abbiamo diverse opzioni, tra cui quella di farla risolvere al server stesso. Se non riesce, chiederà l’intervento dell’utente. I conflitti possono essere di più tipi, solitamente sono problemi di versione, di collisione dei nomi o di sovrascrittura locale.

Nella prossima puntata vedremo la seconda parte, ossia la sezione relativa alla Build Automation.

Visual Studio Team System: Team Foundation Server Overview

Dopo la prima puntata dedicata alle versioni client, vediamo ora la parte server.

Team Foundation Server è un prodotto dedicato allo sviluppo in team, e raccoglie al suo interno moltissime funzionalità.

 E’ basato su SQL Server, quindi la consistenza del dato è garantita, a differenza del suo predecessore Visual SourceSafe ed è transazionale.
SQL Server fa la parte del leone, in quanto parecchi dati (dal codice ai workitems) sono salvati in dei data warehouse. Altre componenti alla base di TFS sono Internet Information Services, che espone tutti i vari web services, e Windows Sharepoint Services (oppure Office Sharepoint Server) per la gestione documentale, i portali di progetto, ecc.

Per ogni sezione dedicherò un post, in modo tale da approfondire il più possibile gli argomenti.

Per accedere ai servizi di TFS è necessario installare in Visual Studio il Team Explorer, che abilita tutto il necessario.

Team Foundation Server non è legato in maniera esclusiva a codice o prodotti .NET, infatti è possibile accedervi usando, a seconda del tool scelto, il connettore corretto.

Per Visual Basic 6.0, Visual C++ 6.0, Visual Studio .NET 2003, Delphi, Visual FoxPro 9 e tanti altri esiste un provider MSSCCI, che si appoggia alle DLL del Team Explorer e si integra all'interno dell'IDE scelto.

Per quanto riguarda Java, TeamPrise ha sviluppato un'implementazione del Team Explorer totalmente fedele a quello Microsoft in tutto e per tutto, in modo tale da renderlo fruibile su Eclipse. Anche IntelliJ Idea ha in previsione un'integrazione con TFS, e lo stesso vale per Oracle JDeveloper 11g.

Ma TFS non è accessibile solo via client, infatti esiste un Team System Web Access, ossia un'interfaccia web che permette di visualizzare tutte le informazioni relative ai progetti, e limitatamente anche il sorgente. All'interno di TSWA è ora anche implementato Work Item Web Access, un'interfaccia web solo per i work items.

Infine, con la versione 3, anche Expression ha finalmente l'integrazione con TFS, assolutamente necessaria per lo sviluppo WPF e Silverlight, onde evitare di dover fare continuamente roundtrips al Team Explorer. Per ottenere questa integrazione è stato rilasciato un articolo di knowledge base, il 967483 con relativa patch da applicare.

Riguardando la figura del primo post, vediamo come ci sia un "blocchetto" chiamato Extensibility. Infatti è possibile avere l'integrazione con Project Server ad esempio, ed inoltre è disponibile un completo Object Model per integrare funzionalità a lui legate all'interno delle nostre applicazioni.

Ultimo, ma non meno importante (anzi tutt'altro, visto che rappresenta le fondamenta della piattaforma...) è il Lab Management.
Permette di avere a disposizione un completo laboratorio di test virtuale, basato su System Center Virtual Machine Manager, e testare le applicazioni. Differenze con un laboratorio tradizionale? Il fatto che ogni dato passante (dump della memoria, informazioni varie sull'OS, addirittura video di ciò che avviene) viene salvato e catalogato, a creare il cosiddetto "rich bug". In questo modo, unito alla funzionalità di Post Mortem Debug di Visual Studio, sparisce il bug non riproducibile, in quanto abbiamo davvero tutte le informazioni per risolvere crash o problemi.

Nei prossimi post analizzeremo i vari pilastri facenti parte di Team Foundation Server, partendo dal Source Control.

Visual Studio Team System: una grande famiglia…

Con questo post ho intenzione di inaugurare una overview di tutta la famiglia Visual Studio Team System.

Si, proprio una famiglia. Perchè oltre alle edizioni client, Team System consta anche di un altro fondamentale prodotto, lato server: Team Foundation Server. Il comune denominatore fra il client ed il server è rappresentato dal Team Explorer, un tool che si integra in Visual Studio e permette di accedere a tutti i servizi offerti da TFS.

Le edizioni client (escludendo la Standard Edition e la Express Edition) poggiano tutte su Visual Studio Professional Edition. Infatti le funzionalità offerte dalle versioni Team non sono altro che una "aggiunta" che viene fatta alla versione Pro, che contiene quindi tutto il necessario per lavorare.

Le versioni Team sono quattro: Architecture Edition, Development Edition, Test Edition e Team Suite. Non ho menzionato la Database Edition, perchè è entrata a far parte della Development Edition. Nella versione 2008 chi compera la Development Edition ha automaticamente accesso anche alla Database Edition, e viceversa. Visual Studio Team Suite è la versione che include tutte e tre le altre.

Architecture Edition
E' la versione di Visual Studio dedicata alle esigenze architetturali. Permette la creazione visuale di tutta una serie di diagrammi atti ad esplicitare l'architettura applicativa (dai Layers alle Activities, dalla logica fino al datacenter), la progettazione di architetture Saas (Software as a Service) e distribuite. Nella versione 2010 sarnno aggiunti Architecture Explorer, uno strumento visuale che permette di capire la struttura della soluzione in maniera WYSIWYG, l'integrazione con UML 2.0 ed ulteriori diagrammi. Inoltre i diagrammi che saranno creati con VSTS Architecture Edition 2010 saranno visualizzabili a chiunque, in sola lettura.

Development Edition
E' l'edizione per lo sviluppo puro. Abbiamo a disposizione una sterminata serie di strumenti per la Code Analysis, le metriche di aderenza alle best practices, il profiler, unit test con Code Coverage, molto utile per capire quanto effettivamente stiamo testando. Parte di questa edizione è anche la Database Edition, che permette di inserire il database all'interno del ciclo di vita dell'applicazione. Ovviamente non sono i dati ad essere inseriti, bensì lo schema del db. Il tutto è transazionale, e permette di usare gli oggetti del database quasi come se fosse codice normale: test, refactoring, eccetera. Si può effettuare Data e Schema Comparison, lavorare sul database offline, eccetera. Nella versione 2010 il supporto è stato esteso, ed ora include oltre all'ovvio SQL Server (2000, 2005, 2008) anche Oracle (di cui è uscito in beta il Database Schema Provider qualche giorno fa) e IBM DB2.

Test Edition
La versione dedicata al test e, a mio personalissimo avviso, la più adatta allo sviluppo web. Infatti oltre agli Unit Test tradizionali, abbiamo a disposizione anche Load Test, ma soprattutto tools di test per applicazioni web e web services per ogni tipo di scenario (browser, rete, ecc). Per questo penso che sia la più indicata per lo sviluppo web . Nella versione 2010 per quanto riguarda il testing abbiamo una strettissima integrazione con l'ambiente di test (Lab Management, che poi vedremo più in la), per avere la possibilità di ricreare in modo più fedele possibile il bug ed eliminare il bug non riproducibile.

Esistono poi altri componenti della famiglia, che sono Team Test Load Agent e Test Essentials. Il primo è uno strumento che permette di creare dei test in modo molto più massivo della singola Test Edition, indicato per grossi stress test. Il secondo invece è un tool per il tester funzionale, introdotto nella versione 2010, che rende il test facile a chi non deve usare Visual Studio. Si tratta fondamentalmente di un'applicazione WPF che permette l'accesso al laboratorio di test, basato su macchine virtuali, ed alla lista delle cose da testare. Ci sono tutta una serie di cose legate a Test Essentials, ma sono ancora non definitive e quindi non anticipo nulla .

Nel prossimo post vedremo nel dettaglio la parte server, ossia Visual Studio Team Foundation Server con tutti gli strumenti correlati.

Alla prossima.