In gesprek met Marcel de Vries
Visual Studio Team System - Part I

Dit is het eerste interview in een serie van een aantal interviews die Mark Blomsma zal voeren met Marcel de Vries. Het onderwerp is Visual Studio Team System (VSTS). VSTS is een enorme uitbreiding van de Visual Studio toolset.

Mark : Op de SDE heb je een sessie gedaan over Visual Studio Team System (VSTS). VSTS is nu nog in beta. Hoe komt het dat jij er dan toch al zoveel van weet?

Marcel : Vanuit Info support zijn wij als één van de 40 partijen wereldwijd gevraagd mee te doen aan het zogenaamde Technical Adoption Program(TAP) programma. Wij hebben de afgelopen jaren zelf een ontwikkelstraat opgezet die we inzetten bij onze klanten. Vanuit onze ervaringen met deze ontwikkelstraat konden wij vanaf het begin Microsoft waardevolle feedback geven over hun product waarbij ze een belangrijk deel van onze visie op het gebied van ontwikkelstraten invullen. Vanuit Info Support zijn we nu vanaf juni 2004 aan de slag met Team System. We hebben de eerste tijd voornamelijk besteed aan het onderzoeken van de afzonderlijke onderdelen van Team System en het geven van feedback op de beschikbare bits. Na het verschijnen van Whidbey Beta 2 zijn we begonnen onze ontwikkelstraat om te bouwen naar een versie die gebruik maakt van Visual Studio Team System.

Mark : Aha... dus jij bent eigenlijk zo'n beetje de Nederlandse VSTS guru! Mooi.
Dan duiken we er meteen diep in. Ik heb begrepen dat VSTS een vervanging is voor Visual Sourcesafe.
Klopt dat of is VSTS nog meer?

Marcel : Je kunt wel stellen dat Team System iets meer is dan alleen een vervanging van Visual SourceSafe. Team System zal zodadelijk op de markt komen in een viertal onderdelen te weten Team Architect, Team Developer, Team Test en Team foundation. Het belangrijkste fundament zit zoals je al wel zult raden in Team Foundation. Team foundation bevat zoals men dat noemt een Unified Change Management omgeving dat bestaat uit Work Item tracking en een nieuwe sourcecode repository. In workitem tracking kun je alle informatie opslaan die betrekking heeft op werk dat moet worden gedaan. Een work item kun je dus simpel gezegd vertalen in een stukje werk dat moet wordne uitgevoerd door iemand in het team. Dat werk sla je op als een bepaald type. Denk hierbij aan het type: Bug, Taak, Scenario, Requirement, Feature, etc. De type work items die beschikbaar zijn worden afhankelijk van het type proces dat je kiest bij het aanmaken van een project in de team foundation server geladen. Deze processen en bijbehorende work item types zijn zelf aan te passen naar behoefte. De Source Repository is een volledig nieuw SCC systeem die SQL server gebruikt als data store. Bij het inchecken van de sources kun je aangeven op welke work items een check-in bijvoorbeeld betrekking heeft. Daarnaast wordt bij het inchecken gecontroleerd of de code voldoet aan vooraf gedefinieerde policies. Denk daarbij aan minimale code coverage of het verplict aanzetten van xml comments in het project. Naast deze onderdelen bevat team foundation ook zaken voor het uitvoeren van een dagelijkse build, het opzetten van een project portaal en functionaliteit voor het genereren van rapportages uit het team foundation datawarehouse. Gedurende een ontwikkel project is er eenb schat aan informatie beschikbaar die allemaal in het datawarehouse wordt geladen. Over al deze informatie kunnen rapportages worden gegenereerd.

 Dit was dan alleen nog maar team foundation ….

Team architect bevat functionaliteit voor het ontwerpen van gedistribueerde systemen. Team developer bevat allerlei toevoegingen voor het vroegtijdig opsporen van fouten in de software en biedt ondersteuning voor test driven development. Team test heeft diverse onderdelen die helpen bij het uitvoeren en managen van test scenario’s. Dus zoals ik al zei is het wel iets meer dan de nieuwe versie van SourceSafe J

Mark: Je hebt het over policies. Maar ik begrijp het nog niet helemaal. Hebben die iets te maken met mijn Windows Domain Policies? Of is het iets heel anders?

Marcel: Policies zijn aparte assemblies die door Microsoft worden aangeleverd en die in de Visual Studio omgeving zaken kunnen controleren bij het inchecken van code in de team foundation server. Deze policies controleren of je bijvoorbeeld alle testen wel gedraaid hebt en dat je coverage percentage boven een bepaalde voor ingestelde waarde ligt. Deze policies kun je ook zelf maken. Door een tweetal interfaces te implementeren (IPolicyDefinition en IPolicyEvaluate) en de assembly te regisreren kan deze worden toegevoegd aan de lijst met checkin policies die gelden voor een project. Met deze policies kun je vervolgens voorkomen dat mensen bijvoorbeeld de build breken of code inchecken die niet voldoen aan van te voren afgesproken richtlijnen voor het project waar aan ze werken. Er worden door Microsoft standaard een aantal policies aangeleverd. Bijvoorbeeld dat je verplicht bent aan te geven dat de sources die je inchecked horen bij een speciefiek work item in de work item database. Op die manier kan men bijvoorbeeld zien nadat er een build is geweest in welke build een bepaalde bug is opgelost. Dus deze policies hebben totaal niets te maken met Domain policies enzo. Het is echt een specifiek iets van Team System.

Mark: Ok. Dus bij het inchecken van code moet ik aangeven bij welke taak of bug die code hoort. Ik begrijp dat default het MSF Agile proces met bijbehorende taken en bugtracking meegeleverd wordt. Is het makkelijk om zelf mijn eigen procesinrichten aan te brengen? Wat ik zag in beta 1 was dat dit toch wel een beetje 'gehackt' moest worden. Het is toch wel fijn als ik mijn eigen 'RUP met waterval combo' als proces kan invoeren. Wordt het met beta 2 beter? Wat zijn ongeveer de stappen die ik moet doorlopen om mijn eigen proces in te voeren?

Marcel: Het is maar net wat je hacken noemt J. Het aanpassen van de process guidance zoals dat zo mooi wordt genoemd bestaat uit ruwweg twee zaken. Ten eerste de process guidance website. Deze website wordt gegenereerd uit een xml file die alle informatie bevat over het proces dat je wilt gaan toepassen. Daar staan dus bijvoorbeeld de iteraties, stappen, artifacts e.d. in. Deze XML kun je aanpassen met InfoPath en er is een manier om deze op nieuw uit te genereren naar een website. Daarnaast heb je de xml files die de methodologie template beschrijving bevat. Deze template wordt gebruikt bij het inrichten van een project met de Create project wizard. In deze xml file staat de beschrijving van de stappen die moeten worden uitgevoerd voor het aanmaken van het project in de team foundation server. Dit is informatie over bijvoorbeeld het inrichten van het sharepoint portal, de source code repository settings, de rechten structuur, je project structuur in termen van componenten etc. Dus als hacken betekend XML files aanpassen, dan is het antwoordt dat dit in deze versie van Team System zo zal blijven. Er zullen bij de eerste versie geen additionele tools worden geleverd voor het aanpassen van de templates.

Mark: Dit klinkt als een redelijke klus. Wat denk je, zullen er partijen in de markt opstaan die aanvullende processen als een produkt gaan opleveren?

Marcel: Er zijn op dit moment wel een aantal partijen bezig met het maken van een methodologie template die in Team System integreert. Zo zijn wij bij info support bijvoorbeeld bezig met een template gebaseerd op onze best practices uit onze ontwikkelstraat Endeavour dat is gebaseerd op RUP. Daarnaast zijn er ook andere partijen bezig met dit soort templates. De verwachting is dat met betrekking tot deze methodologie templates er binnen korte tijd templates zullen zijn met daarin de meest bekende processen.

Mark : Ok, ander onderwerp. Stel ik heb een team van 4 a 5 developers.
Hoe zou ik VSTS dan deployen binnen mijn team?

Marcel : Dat is een zeer goede vraag waar ik niet een eenduidig antwoordt op kan geven. Dat hangt er namelijk van af wat je wilt bereiken. Als je het belangrijk vindt dat er iedere dag een build wordt gemaakt, dat je bij houd welk werk moet worden gedaan en hierover rapportages wilt hebben dan moet je kiezen voor een installatie inclusief team foundation server. Heb je al deze functionaliteit niet nodig maar wil je bijvoorbeeld alleen gebruik maken van de unit test functionaliteit dan kun je volstaan met alleen een versie van team developer. Zoals je waarschijnlijk wel weet heeft microsoft een volledig nieuwe lijn aan producten opgezet. Variërend van de express producten voor de hobbyist tot en met Team System voor de enterprise developer. Vanaf het professional product zal Visual sourcesafe 2005 worden meegeleverd. Dit is dus ook prima in te zetten in een klein team. Zelf denk ik wel dat als je een team hebt dat meer dan een man of acht aan developers het de aanbeveling verdient om gebruik te gaan maken van Team Foundation. Als je maar een feature uit team foundation server wilt toepassen zul je wel altijd de volledige server moeten installeren. Je kunt dus niet zeggen: Ik wil alleen de nieuwe SCC repository. Deze zal altijd gelinkt zijn met de rest van Team Foundation.

Mark : Heeft VSTS ook functionaliteit die nuttig is als ik in mijn eentje aan het ontwikkelen ben?

Marcel : Ik denk van wel. Voor de individuele ontwikkelaar bieden de test tools bijzonder veel nieuwe mogelijkheden de code kwaliteit aanzienlijk te verbeteren. Dus als je gebruik maakt van bijvoorbeeld Team Developer kun je met o.a. de code profiling tools en static analisys tools bijzonder veel winst behalen in schonere betere code waar je zelf de performance bottlenecks uit kunt halen voordat de klant met de klacht over performance komt.

Mark : Je hebt het over code profiling tools. Wat is code profiling eigenlijk?

Marcel: Code profiling is eigenlijk het monitoren van de applicatie terwijl deze actief is. Dit bekijken van de applicatie kan op twee manieren worden ingesteld te weten Sampling of Instrumentation. In het geval van Sampling wordt er op een vast timer interval (in de nano seconden) gekeken welke methode op dat moment actief is. Dit wordt vast gehouden in een lijst en aan het einde van het profiel kan dan deze lijst worden gebruikt als indicatie welke methodes het meest worden gebruikt en eventueel het traagst zijn. Hoe meer keren de sampling detecteert dat een zelfde functie executeert hoe groter de kans is dat deze methode ook een bottleneck vormt voor de applicatie. In het geval van Instrumentation profiling worden er zogenaamde probes geïnjecteerd in je assembly. Daarna start je de applicatie op en kun je na afloop van de applicatie de probes laten uitvragen. Dit levert een nauwkeurig beeld op van welke code blokken de applciatie allemaal heeft geraakt. Het voordeel van instrumentation is dat het altijd een 100% beeld geeft van de methodes die worden aangeroepen. Echter doordat er probes actief in je applicatie worden bijgehouden heeft dan een significante impact op de performance van de applicatie. Als je Sampling gebruikt dan zal de applicatie verder niet worden gehinderd tijdens executie. Er is dus geen performance impact. Echter je krijgt alleen een lijst met meest geraakte functies en niet een lijst met alle geraakte functies. Dus met profiling kun je het dynamische gedrag van de applicatie analyseren en daarmee performance bottlenecks ontdekken in de applicaties.

Mark: Wat is dan static analysis? Waarom heet het niet dynamische analysis?

Marcel: Static analysis is eigenlijk FXCop zoals we dat nu kennen. Static analysis gebruikt de huidige assembly en “bekijkt” deze op regels die zijn vast gelegd in rule assemblies. Bij static code analysis wordt dus alleen naar de assembly zelf gekeken maar niet naar het runtime gedrag. Vandaar er in team developer er ook twee smaken zijn. Static code analysis dat dus de geïntegreerde FXCop bevat en de dynamic code analysis dat op basis van instrumentation of sampling het runtime gedrag van je applicatie analyseert.


Mark: Ok. Bedankt voor al deze info. In onze volgende sessie zullen we verder de diepte in duiken.

- Wordt vervolgd...


Marcel de Vries heeft tegenwoordig ook een weblog. Surf naar http://blogs.infosupport.com/marcelv/  voor zijn laatste ervaringen met Visual Studio Team System.