Autore: Roberto Brunetti - DevLeap
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
• http://blogs.devleap.com/rob/archive/2007/07/16/workflow-custom-activity-e-vsts-unit-test.aspx
• http://blogs.devleap.com/rob/archive/2005/12/30/6434.aspx
• http://blogs.devleap.com/rob/archive/2005/09/12/5705.aspx
• http://blogs.devleap.com/rob/archive/2006/01/30/6608.aspx
Database Edition
• http://blogs.devleap.com/rob/archive/2007/08/20/vsts-for-db-pro-power-tools.aspx
• http://blogs.devleap.com/rob/archive/2007/07/28/vsts-for-db-pro-service-release-1.aspx
• http://blogs.devleap.com/rob/archive/2007/02/02/vsts-for-db-pro-aggiunta-e-successivo-refactor-di-un-campo.aspx
• http://blogs.devleap.com/rob/archive/2007/02/02/vsts-for-db-pro-schema-update-per-aggiunta-campo.aspx
• http://blogs.devleap.com/rob/archive/2007/02/01/vsts-for-db-pro-schema-update-con-merge-replication.aspx
• http://blogs.devleap.com/rob/archive/2006/12/25/15649.aspx
• http://blogs.devleap.com/rob/archive/2008/09/17/microsoft-174-visual-studio-team-system-2008-database-edition-gdr-august-ctp.aspx
TFS
• http://blogs.devleap.com/rob/archive/2008/09/09/tfs-2008-sp1-problem.aspx
• http://blogs.devleap.com/rob/archive/2008/09/09/tfs-2008-sp1-problem.aspx
• http://blogs.devleap.com/rob/archive/2008/09/06/visual-studio-team-system-web-access-2008-sp1-power-tool.aspx
• http://blogs.devleap.com/rob/archive/2007/11/20/team-foundation-server-2008-upgrade.aspx
• http://blogs.devleap.com/rob/archive/2005/09/03/5645.aspx
• http://blogs.devleap.com/rob/archive/2005/12/05/6330.aspx
http://blogs.devleap.com/rob/archive/2006/03/30/7085.aspx
Roberto Brunetti
Autore: Roberto Brunetti - DevLeap
Questo articolo ripercorre alcuni miei appunti e le prime impressioni di utilizzo di Visual Studio Team System 2010. Sto usando un progetto di esempio per analizzare il prodotto prima di portare la nostra famosa applicazione Estates Management sotto VSTS 2010.
Visual Studio Team System venti-dieci (come viene chiamato affettuosamente) porta con se molte novità sia per la versione Architect che per la versione Tester. Non meno numerose sono le nuove funzionalità della parte Team Foundation Server.
Da quello che si evince dalle conferenze stampa la parte più importante delle novità riguarda l’edizione Architect, sia per quanto riguarda le modalità di lavoro del team ovvero una maggiore singergia fra i componenti, sia per quanto rigurda l’introduzione di strumenti di modellazione UML che si aggiungono agli attuali DSL.
Democratize: everybody has a chance to play
Quello che accade spesso oggi, anche nei progetti che ho seguito personalmente, è la quasi totale divisione dei compiti fra architetti e gli altri membri del team: solitamente all’inizio della progettazione gli architetti si chiudono in una stanza e producono una serie di diagrammi architetturali. E’ vero che già oggi, se questi diagrammi sono prodotti con la Architect Edition, è possibile implementare le componenti applicative partendo dal diagramma e grazie alle estensioni dei power tools è possibile creare progetti di tipo ASP.NET, Windows e class library arrivando alla solution completa dei progetti e delle reference fra di essi. Per esempio, partendo dal diagramma seguente è possibile implementare con un solo colpo di mouse l’applicazione ASP.NET, l’applicazione windows client e le due dll rappresentate in questo estratto del diagramma completo.
Si veda il post completo sui Power Tools.
L’interazione fra il diagramma applicativo e il codice reale è presente anche nella configurazione delle applicazioni: sul client windows e sull’applicazione web, per proseguire con l’estratto del nostro esempio, la configurazione effettuata dagli architetti sui Settings & Constraint si riflette sulle effettive configurazioni presenti all’interno dei rispettivi file .config.
In Visual Studio Team System 2010 la sincronizzazione e quindi la collaborazione fra il “disegno” e il codice reale (e quindi fra Architect e Developer) viene effettuata a più livelli. Ad esempio il nuovo Layer Diagram consente di visualizzare le varie componenti applicative nei layer definiti per l’applicazione. L’architetto e/o il developer possono così avere una rappresentazione più concreta di quali elementi sono compresi in quali layer.
Ecco un esempio di Layer Diagram per una applicazione di esempio:
Nella toolbox ci sono solo Layer e Dependency che consentono di definire i layer applicativi e i flussi delle chiamate fra layer. Si può partire da zero oppure da una applicazione esistente (ad esempio da diagramma dei namaspace, più avanti) trascinando un namespace e portandolo sul layer effettivo. Si può fare poi Show Dependency per vedere le dependency fra le classi dei namespace rappresentati nel diagramma senza dover ricreare i percorsi. Con questo diagramma quindi possiamo rappresentare velocemente i vari componenti applicativi suddividendoli nei layer logici e verificare su una applicazione esistente quali sono le interazioni fra le classi.
Il flusso delle chiamate definisce anche le regole di chiamata fra layer: ad esempio, se il Presentation Layer ha un flusso possibile solo con il Business Layer, non dovremmo permettere allo sviluppatore di fare una reference verso il Data Access Layer e utilizzare direttamente le classi di accesso ai dati. Tramite la funzione Validate All è possibile eseguire questi controlli senza dover analizzare il codice. In pratica si controlla che le classi reali non facciano chiamate che non sono permesse dalle dependency: trovo questo strumento importantissimo per effettuare verifiche sulle applicazioni esistenti e per rappresentare graficamente una applicazione esistente ricavandone le idee architetturali che spesso non sono state documentate (forse ho avuto sfiga, ma nei progetti esistenti su cui ho messo le mani a posteriori, la documentazione è sempre stato un problema..non so se capita anche a voi J). Si possono anche impostare regole di compilazione per MSBuild per evitare una compilazione che non rispetti le corrette chiamate fra layer. E’ possibile fare queste verifiche anche sul Build Server (quindi anche senza Visual Studio) inserendo un tag <validate Include=”diagramma.Layer”> che punta al diagramma da controllare. E’ un FxCop per Architect J.
I diagrammi si possono Copy&Paste ovunque oppure esportare (stanno decidendo dove: sembra Visio di sicuro) per creare documentazione elettronica senza sforzo.
Il layer diagram è accessibile anche dal codice e vice versa, ovvero è possibile conoscere la posizione del codice che sto vedendo rispetto ai layer oppure scendere nel dettaglio di una classe (nel codice della classe) partendo dalla rappresentazione nel layer diagram.
UML
Un’altra novità di rilievo della versione Architect è il supporto a UML che in molti hanno lamentano nella versione 2005 e 2008 di Visual Studio Team System Architect Edition. L’idea è poter approcciare la definizione dell’architettura Top-Down oppure Bottom-Up.
Se si guarda la soluzione dall’altro, sono disponibili 5 designer UML (almeno secondo le previsioni attuali) per rappresentare il livello logico di una applicazione; se invece si guarda la soluzione dal basso, restano più che validi i DSL che, essendo più concreti e più specializzati, aderiscono meglio alla rappresentazione reale. L’idea è quindi non abbandonare DSL, ma creare la formula magica: UML + DSL == Better Code. La cosa interessante e che i diagrammi sono “agganciabili” ovvero si può partire dal diagramma logico in UML (ad esempio il sequence diagram) per scendere nel codice reale con un semplice click del mouse. Ad una modifica del codice reale, supponiamo per effettuare una chiamata ad una nuova classe, il sequence diagram si aggiorna per rappresentare questa interazione.
Per quanto riguarda UML (2.0 e 1.1) è importante comprendere la connessione rispetto ai DSL che stanno sotto. Addirittura, i designer UML sono stati creati con il DSK Toolkit. Quindi i DSL tool esistono ancora e anzi ne viene incoraggiato l’utilizzo per modellare il proprio dominio creando i DSL custom.
Hanno deciso di “tornare” a UML perchè è quello che la gente usa. La prima versione di VSTS puntava invece a rappresentare in modo aderente alla realtà del progetto l’applicazione, i logical datacenter e il deploy relativo. Probabilmente non saranno 100% standard perchè nessuno lo è: cercheranno di coprire i livelli (come sapete il supporto allo “standard” UML viene indicato come compliance ad un determinato livello)
Nella prima versione (2010) ci saranno questi 5 diagrammi UML:
1. Use Case
2. Component
3. Activity
4. Class
5. Sequence
Tutti questi strumenti hanno una migliore integrazione con il codice: ad esempio sto scrivendo o analizzando questo pezzo di codice e posso sapere in che punto mi trovo rispetto ai diagrammi.
Resta l’idea che non viene consigliata una modalità (fra top-down o bottom-up): ognuno si può muovere come preferisce rispetto al suo modo di lavorare.
Rapporto con Visio: Visio è il prodotto più usato al mondo per far modeling UML quindi sarà possibile importare i diagrammi.
Top Down Approach (parto con UML)
Il nuovo Model Explorer Windows consente di vedere e gestire i vari modelli. I diagrammi UML si aggiungono alla solution: ognuno ha una estensione diversa gestita anche da TFS per centralizzare i diagrammi e gestirne il versioning.
Ecco qualche screen-shot dei designer UML.
1) Use Case
a. Actor e i vari Use Case
b. Si connettono (association) gli actor ai vari use case
c. Si possono fare le include di un uc in un altro uc
2) Activity Diagram
a. Descrrive il flusso dei dati (i processi): si mettono gli step e si connettono in sequenza
b. Nel Model Explorer si vedono le componenti degli altri diagrammi per poter creare legami fra di essi.
3) Sequence Diagram
a. Si può fare reverse engineer dal codice
b. Si disegnano le seguenze
c. Il diagramma resta sincronizzato con il codice (come vedremo più avanti), quindi a fronte di una nuova chiamata scritta nel metodo, il diagramma presenta un nuovo passo all’interno della sequenza
4) Component Diagram
a. I Component non rappresentano elementi fisici (potranno poi essere DLL o EXE o composizioni di questi, ma a questo livello non ci interessa)
b. Si mettono poi le interfacce e si connettono i vari componenti sempre utilizzando le informazioni del Model Explorer.
5) Logical Class Diagram
a. Lavora con il Class Diagram .NET che rappresenta il fisico
b. Si trascinano gli elementi definiti negli altri diagrammi
c. Si definiscono le operazioni e gli attributi
d. Si torna nel .sequence e si legano le “cose reali”
e. Si possono fare “cose ereditate” (e il designer mostra il tutto)
In questo ultimo digramma si vede l’interfaccia di pagamento derivata nel sistema di pagamento specifico per l’applicazione.
Botton Up (parto dal codice)
L’idea è che quasi sempre ci sono cose già fatte: anche quando si parte con un progetto nuovo magari ci sono esempi fatti o pezzi già pronti realizzati per prova o altri componenti esistenti da utilizzare.
Il diagramma con estensione.dgml consente di iniziare a comprendere una applicazione esistente. Per creare il diagramma in modo semplice si utilizza l’Architecture Explorer che mostra tutte le classi nella solution divisi per componente e namespace. Ad esempio, partendo da questa situazione esistente nella solution
E trascindando le classi di un namespace (volendo anche tutte le classi della solution) si ottiene la rappresentazione delle classi e l’interazione fra di esse all’interno di questo
E si ottiene questo
A parte una inutile ragnatela, pensiero che colpisce subito appena il diagramma viene rappresentato, basta prendere una classe, cliccarci sopra e iniziare ad esplorare le interazioni fra le classi in modo semplice e intuitivo: pensate sempre a cosa vorrebbe dire entrare nel codcie di ogni classe e di ogni metodo per vedere quali sono le chiamate effettuate, e ancoara più difficile, sapere da quali componenti viene chiamata la classe in oggetto: da sempre l’object explorer ci può dare una mano, ma vedere graficamente “la ragnatela” è decisamente più semplice e intuitivo.
Da questo diagramma si possono far partire diversi Analyzer che analizzano appunto il diagramma stesso per individuare, ad esempio, i riferimenti circolari, piuttosto che le dipendenze fra le chiamate; quest’ultimo individua le classi (volendo raggruppatoe per namespace) e le chiamate effettuate. Ecco un esempio:
Diventa più semplice capire l’applicazione esistente, vederne i dettagli (da ogni classe si può andare a visualizzare il codice, vedi prossima immagine), analizzare le dipendenze e le eventuali anomalie sulle chiamate senza dover per forza vedere il codice (che magari è stato scritto in sanscrito J).
Il dettaglio di ogni classe dentro il namespace e il codice è visibile facendo un semplice doppio click.
Quest’ultima immagine non ha molto senso; era assolutamente chiaro cosa volesse dire andare a vedere il codice con un doppio click, ma averla inserita ci consente di capire che facendo ancora una volta una semplice operazione con il mouse possiamo generare il Sequence Diagram (a partire da qualunque metodo).
Questo il Seguence Diagram del metodo createNewOrderButton_Click
Se nell’approccio Top-Down il Sequence Diagram era la base di partenza per poi scrivere il codice, avendo una applicazione esistente è facile percorrere il percorso inverso.
E’ ottima questa sincronizzazione (e forma di reverse engineering) anche per imparare a creare Sequence Diagram: ad esempio metto una chiamata ad un’altra classe nel codice e vedo come avrei dovuto fare il Sequence Diagram. E’ ovvio che sarebbe bene fare il contrario, il sequence diagram nasce proprio per rappresentare i flussi in modo astratto dal codcie, ma avere entrambe le possibilità è sicuramente un plus.
Ovviamente dal sequence diagram si può tornare codice del metodo rappresentato.
Dal Sequence Diagram si può anche produrre il Class Diagram e sincronizzarlo oppure effettuare una Create Method per aggiungere un metodo reale alla classe rappresentata.
Per questa prima parte direi che è tutto. Ci sentiamo presto per vedere le novità sulla parte tester, build, manual testing e le novità della parte di gestione del progetto come work-item gerarchici.
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/.
Allego anche 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
• http://blogs.devleap.com/rob/archive/2007/07/16/workflow-custom-activity-e-vsts-unit-test.aspx
• http://blogs.devleap.com/rob/archive/2005/12/30/6434.aspx
• http://blogs.devleap.com/rob/archive/2005/09/12/5705.aspx
• http://blogs.devleap.com/rob/archive/2006/01/30/6608.aspx
Database Edition
• http://blogs.devleap.com/rob/archive/2007/08/20/vsts-for-db-pro-power-tools.aspx
• http://blogs.devleap.com/rob/archive/2007/07/28/vsts-for-db-pro-service-release-1.aspx
• http://blogs.devleap.com/rob/archive/2007/02/02/vsts-for-db-pro-aggiunta-e-successivo-refactor-di-un-campo.aspx
• http://blogs.devleap.com/rob/archive/2007/02/02/vsts-for-db-pro-schema-update-per-aggiunta-campo.aspx
• http://blogs.devleap.com/rob/archive/2007/02/01/vsts-for-db-pro-schema-update-con-merge-replication.aspx
• http://blogs.devleap.com/rob/archive/2006/12/25/15649.aspx
• http://blogs.devleap.com/rob/archive/2008/09/17/microsoft-174-visual-studio-team-system-2008-database-edition-gdr-august-ctp.aspx
TFS
• http://blogs.devleap.com/rob/archive/2008/09/09/tfs-2008-sp1-problem.aspx
• http://blogs.devleap.com/rob/archive/2008/09/09/tfs-2008-sp1-problem.aspx
• http://blogs.devleap.com/rob/archive/2008/09/06/visual-studio-team-system-web-access-2008-sp1-power-tool.aspx
• http://blogs.devleap.com/rob/archive/2007/11/20/team-foundation-server-2008-upgrade.aspx
• http://blogs.devleap.com/rob/archive/2005/09/03/5645.aspx
• http://blogs.devleap.com/rob/archive/2005/12/05/6330.aspx
• http://blogs.devleap.com/rob/archive/2006/03/30/7085.aspx
Roberto Brunetti