Visual Studio 2005 Team System
Articolo da me pubblicato su Week.it a Marzo 2005, rivisitato in chiave Beta2.
In un mondo in cui la tecnologia si evolve ogni giorno, le applicazioni si fanno sempre più complesse e interconnesse, le aggiunte di funzionalità sono quotidiane e diventa sempre più complesso controllare le varie fasi dello sviluppo software. Anche perché le applicazioni «enterprise» hanno tanti piccoli componenti software che devono interagire fra loro su macchine e reti diverse. Un’applicazione deve essere pensata, progettata, sviluppata, testata e infine distribuita.
Per pensare l’applicazione occorre in prima battuta la testa, supportata da diversi strumenti per prendere appunti, condividere le idee, comunicare con i vari membri del team. La fase di progettazione può essere supportata da strumenti Uml per definire le varie componenti e la loro interazione.
Nello sviluppo di un’applicazione complessa occorrono perciò anche strumenti di pianificazione del lavoro all’interno del team; per eseguire unit test o delle varie componenti; diagrammi sulla topologia di rete a vari livelli; per definire i requisiti hardware e software. In base al ruolo di ogni membro del team occorrono, poi, informazioni con diversi gradi di dettaglio. Per fare un esempio banale, è probabile che la persona che effettua i test di ogni componente (unit test) non abbia bisogno di informazioni dettagliatissime sulla topologia di rete.
Oggi ci sono molti strumenti che aiutano il ciclo di sviluppo facendo da contorno al vero e proprio tool per scrivere e compilare il codice. In un team di medie dimensioni si può ipotizzare l’uso di Project per pianificare e assegnare le varie attività, un tool Uml per definire le classi applicative, uno per gestire workflow e flussi applicativi, Visio per le strutture dati e la topologia di rete, Visual Studio 2003 per sviluppare e debuggare la soluzione, uno per gestire test e stress test applicativi, Excel per gestire i report sui vari test effettuati, un performance monitor durante l’effettuazione dei test, una serie di documenti cartacei per definire regole, constraint, hardware, policy e così via.
L’obiettivo di Visual Studio Team System (VsTs) è proprio fornire, in un unico strumento integrato, il supporto per gestire l’intero ciclo di sviluppo software. L’edizione «2005» è in Beta2 (ad oggi è disponibile la versione CTP di Luglio 2005) e sarà rilasciata con Visual Studio 2005 e il Framework .Net 2.0. Ha funzionalità interpretabili secondo vari punti di vista: architetto, sviluppatore, tester e project manager. Anche se molte aziende italiane non hanno un gruppo di lavoro ben formato sulla filosofia di sviluppo in team e poche hanno personale dedicato a eseguire i test, secondo il mio personale parere il prodotto fornisce un grande aiuto nella gestione dei progetti di sviluppo anche a singoli sviluppatori.
Secondo Rick LaPlante, general manager Microsoft per i Visual Studio Enterprise Tools, «solo il 20% dei progetti di sviluppo è puntuale perché manca la pianificazione: spesso si inizia a scrivere codice senza definire l’intero progetto. Ma uno strumento informatico può aiutare la gestione delle varie fasi di sviluppo, ma non può “lavorare” se non usato con criterio». Si può fare un paragone: chi sa gestire un progetto e un team trova in Project un valido alleato, ma chi non ha queste doti è inutile che lo usi. VsTs è «integrato con Visual Studio, Excel, Project e Outlook per gestire tutte le fasi di sviluppo».
Sono previste tre edizioni distinte ma integrate: Team Architect per il software architect e la progettazione visuale di soluzioni service-oriented; Team Developer per lo sviluppatore e corredato di strumenti quali Code Analyzer, Code Profiler, Code Coverage; e, infine, Team Test per la creazione di Unit test, test manuale, Web test, stress test.
I tre strumenti si appoggiano a Team Foundation che centralizza le informazioni sul progetto e facilita l’integrazione con Excel, Project, SharePoint. Comunque le varie componenti non hanno un confine ben definito; è probabile infatti che gli strumenti di modellazione delle classi debbano essere condivisi fra i software architect e sviluppatori, così come il tool Code Coverage serva sia allo sviluppatore che al tester. È altrettanto vero però che, soprattutto in Italia, spesso i ruoli non siano così ben definiti: è facile trovare, anche in aziende di grandi dimensioni, sviluppatori che effettuano anche i test o architetti che generano l’infrastruttura delle classi e i componenti base con codice ottimizzato e uniforme per l’accesso ai dati.
L’Architect Edition
Questo software offre ai progettisti di soluzioni complesse una serie di designer per facilitare il disegno, lo sviluppo e il deploy secondo i canoni definiti nella Dynamic System Initiative (Dsi).
Il primo, l’Application Designer (AD), aiuta a definire e configurare le componenti che formano l’applicazione. Tramite una serie di prototipi predefiniti (eventualmente estendibili) è possibile disegnare Web service, Web application, Windows application, database. I diagrammi possono essere costruiti semplicemente trascinando e collegando i vari prototipi sulla «lavagna» oppure con un’operazione di reverse engineering su un’applicazione esistente. Con questo tool è possibile definire le operazioni esposte da ogni servizio indicando i vari metodi esposti o importando direttamente un file Wsdl esistente. Ogni blocco indicato solitamente corrisponde a un progetto distribuibile individualmente.
Le varie connessioni fra un componente e l'altro indicano i punti di contatto e il flusso applicativo. Si può generare lo scheletro dei servizi a partire dal diagramma che rimarrà sincronizzato rispetto alle implementazioni effettuate nel codice.
Durante il debug verranno rispettati i flussi definiti in questo schema. È possibile definire una serie di constraint per validare il modello prima di passare alla fase implementativa, così come indicare una serie di requisiti per il funzionamento di ogni componente (per esempio indicare che è necessario Windows 2003 Sp1 con .NET Framework 2.0 e Iis per far girare un particolare Web service). Questi constraint verranno anche validati rispetto a quanto indicato nel Logical Datacenter Designer e Deployment Designer.
Il Logical Datacenter Designer (LDD) serve, invece, per definire il diagramma dei server e ottenere importanti informazioni per la fase di deployment reale. Si possono specificare e configurare i vari server, le tipologie di comunicazione, i flussi e i tipi di servizi abilitabili su ognuno. Il designer è integrato in Visual Studio e quindi riutilizzabile da qualunque membro del team di sviluppo.
Si definiscono varie zone in cui posizionare logicamente i vari server e tracciare i flussi di dati. È prevista una serie di tipologie di server predefiniti che può essere estesa secondo le necessità.
Una volta definito il modello logico è possibile associare policy, constraint e settaggi applicativi a ogni server o comunicazione: per esempio è possibile definire i criteri di security che dovrà avere l’applicazione Asp.Net di front-end. Tali settaggi verranno poi impostati fisicamente nella fase di deployment.
Con il terzo, System Designer, è possibile comporre e configurare «sistemi» in base alle componenti definite nell'Application Diagram. Un «sistema» è l’unità di deployment e può essere aggregato ad altri sistemi per formare l'intera applicazione.
Si possono così definire varie aggregazioni di componenti applicative suddividendo il sistema in vari sottosistemi e prevedere diverse tipologie di installazione: per esempio si può definire un sistema «Soluzione Web» che raggruppa le varie applicazioni dell’interfaccia, un sistema «Servizi Spedizione», che raggruppa questo tipo di servizi, e un sistema «Servizi Ordini» per poi definire i macrosistemi «Installazione completa» che raggruppa i tre sottosistemi, «Installazione Spedizione» che raggruppa «Soluzione Web» e «Servizi Spedizione» per installazioni che prevedono solo questi componenti.
Con questo designer quindi si definiscono le varie pacchettizzazioni dell’applicazione che verranno poi distribuite in base a quanto definito nell’ultimo tool, ovvero Deployment Designer.
Questo, definisce il mapping fra un «sistema» e il logical datacenter. In poche parole vengono associate le applicazioni di un «sistema» definito ai vari server logici. In questa fase vengono validate tutte le regole e i constraint definiti nei vari modelli: vengono verificati quindi i constraint definiti con Acd rispetto al datacenter che dovrà ospitare l’applicazione, così come tutti i protocolli di comunicazione fra le componenti applicative. Si verifica per esempio che il protocollo necessario all’applicazione Web sia utilizzabile fra il Web server nella Dmz e il server che ospita i Web service nella zona definita come «Application Zone».
La Developer Edition
La Developer Edition, destinata agli sviluppatori, fornisce una serie di strumenti per analizzare il codice eliminando la necessità di strumenti di terze parti spesso poco integrati con Visual Studio. I tool si dividono in due categorie: Code Analysis e Performance Analysis. Entrambe facilitano l’individuazione di problemi durante la fase di scrittura del codice evitando perdite di tempo durante i test.
Due sono i tool per eseguire verifiche statiche sul codice: PreFast e FxCop. Il primo serve per prevenire alcuni problemi comuni nel codice C/C++ come buffer overrun, null pointer, resource leak, memory leak; il secondo analizza il codice managed e riporta informazioni su eventuali problemi di violazione delle regole definite a priori: per esempio la violazione di una regola di disegno di un blocco try/catch o una violazione delle convenzioni sui nomi delle variabili.
Altri strumenti particolarmente utili sono Code Coverage che, integrato con il modulo di testing, consente di verificare quali flussi di codice sono stati eseguiti e testati e quali sono rimasti appunto «non coperti» dal test. Diversamente dai software sul mercato, che iniettano codice di test all’interno del codice reale, questo strumento è integrato con l’ambiente di sviluppo e non richiede queste «iniezioni»: risulta così più aderente all’esecuzione reale nel caso di test di performance e carichi.
Code Profiler consente, invece, di profilare il codice, ossia analizzare cosa succede durante il runtime: call-stack, vista sulle funzioni, grafico su chiamante/chiamato, allocazione degli oggetti in memoria, vista sull’allocazione degli oggetti del Garbage Collector, thread in esecuzione e così via. Ancora una volta il tutto è integrato all’interno dell’ambiente. Sono disponibili due tipologie di Profiling: Sampling e Instrumentation. Nella prima l'ambiente esegue un poll a intervalli sull'applicazione in funzione per capire le funzioni richiamate, la quantità di oggetti allocati e consente di individuare i punti critici (ad esempio le funzioni lente). La seconda tipologia invece, inserisce codice all'ingresso e all'uscita di ogni metodo per effettuare analisi più accurate e complete sul codice in esecuzione: ovviamente l'esecuzione è "penalizzata" durante il test dal codice necessario a loggare le operazioni.
Una serie di wizard consentono di definire test sulle performance durante il profiling e ottenere dati o grafici sui risultati. Per esempio al termine di una profilazione è possibile sapere quante volte sono stati richiamati una funzione, un costruttore, un set di una proprietà.
Per generare Unit Test è sufficiente, dall’ambiente VSTS, premere il tasto destro su una classe o su un singolo metodo per far partire un wizard che genera un client in un progetto di tipo Test che consente di testare e controllare i valori di ritorno di un metodo. Questi strumenti sono integrati con la versione Team Test che consente di creare dei test di carico in base ai singoli Unit Test definiti e quindi analizzare il comportamento dell’applicazione (Code Coverage, Code Profiler, Performance) sotto stress. Con la Developer Edition possono anche essere definite una serie di regole per eseguire il check-in di un componente software. Per esempio è possibile forzare lo sviluppatore a eseguire uno unit test del componente prima di poter rilasciare una versione del componente stesso.
La Team Test Edition
Destinata a chi effettua test di funzionamento e carico delle applicazioni, questa edizione è pensata per creare Unit Test, analizzare Code Coverage e creare, gestire o analizzare stress test. È possibile creare stress test di un’applicazione Web, simulando le get e le post con parametri inseriti manualmente o recuperati da un database. Per esempio eseguire una post per tutte le province della relativa tabella verso una pagina .aspx.
Lo stesso ragionamento si applica per Web service o componenti che possono essere stressati passando parametri reali ai metodi esposti. È possibile creare un test che simuli la navigazione di un utente sul sito dalla scelta dei prodotti fino all’acquisto finale, indicando le percentuali degli utenti che, rispettivamente, si fermano alla prima fase e che proseguono fino all’acquisto finale. Si possono creare stress test partendo da Unit Test oppure definendo test completi da zero.
È anche possibile, come accade oggi con Application Center Test, simulare il carico di lavoro da più macchine client verso Web service, applicazioni asp.net oppure componenti invocati tramite remoting.
Terminato il test, si possono analizzare i risultati sulla copertura del codice, sulla profilazione dell’esecuzione e sui counter del performance monitor delle varie macchine coinvolte.
Team Foundation Server
L’obiettivo di Team Foundation Server è fornire una piattaforma aperta utilizzabile da Project, Excel, Visual Studio e prodotti stand-alone con tutte le informazioni sul progetto: dalle task alle assegnazioni ai vari membri del team, dai sorgenti sotto controllo alle regole per poter fare il check-in, dai test definiti ai rispettivi risultati.
Si parte creando un nuovo Team Project , che verrà esposto anche tramite Windows Sharepoint Services, in base a un template (per adesso il default è Msf v4 Agile, ma se ne possono creare di propri). Si prosegue aggiungendo tutto quello che serve per il progetto: definizione delle fasi, work items, tasks, owner di ogni task, documentazione, requisiti, richieste.
Questo repository può essere interrogato con Project dal project manager, con Excel per quanto riguarda task e reportistica, con Visual Studio per tutto ciò che riguarda le attività elencate.
Tutti i prodotti lavorano con la Foundation leggendo o memorizzando i dati all’interno di essa. Per esempio uno stress test effettuato con Team Test memorizza i dati all’interno della foundation; con Excel è possibile estrarre dei grafici sull’andamento dei bug risolti. La Foundation contiene anche le regole per i vari sviluppatori che verranno imposte ai vari membri del team per effettuare operazioni di check-in o verifica del codice. Tutte le operazioni di check-in e check-out vengono effettuate tramite la foundation che quindi rappresenta il nuovo motore di Source Control per l'intero team di sviluppo. TFS supporta Checkout multipli, Braching, Shelving.
Riepilogando Team Foundation tiene traccia dei vari work item, esegue il controllo dei sorgenti, consente di eseguire build schedulate, è la base per le analisi Olap e fornisce il portale (tramite Sharepoint) per tutti i membri del team di progetto. Microsoft rilasciò Visual Basic per tentare di facilitare la scrittura del codice riducendone la complessità. Con Visual Studio.Net sono state semplificate una serie di operazioni necessarie alla costruzione di applicazioni distribuite. Visual Studio .Net 2003 facilitò ancora la scrittura del codice ma non ha strumenti per gestire l’intero ciclo di vita del software.
Interessante è la possibilità di personalizzare praticamente tutto, dal tipo di regole da seguire, ai designer, alle componenti da ospitare nei disegner, ai template per i progetti: si utilizza il VSTS Extensibility Kit disponibile anch'esso in Beta.
Con VsTs 2005 si cerca di facilitare, grazie a uno strumento integrato con l’ambiente di sviluppo del puro codice, la progettazione, il disegno, il debug, il test e il deploy delle applicazioni. Visual Studio 2005 Team System non è quindi il nuovo strumento per scrivere il codice: per questo avremo le nuove versioni 2005 di Visual Studio con tutta una serie di novità (fra le quali il refactoring).
VsTs è il nuovo ambiente per gestire l’intero ciclo di vita di un’applicazione con un unico strumento integrato. È perciò uno strumento complesso che richiede un team «mentalmente» preparato a gestire il software.