Als Team Foundation Server gebruikt wordt in een mondiale omgeving, brengt dat een aantal bijzondere aspecten met zich mee voor de inrichting en het gebruik van de tool. In dit artikel belichten we de belangrijkste aandachtspunten hoe TFS ingezet kan worden in een internationale omgeving met meerdere domeinen, tijdzones en culturen.
Modern software ontwikkelen wordt gekenmerkt door multi-disciplinaire teams, integrale tools, snelle procescycli en/of geautomatiseerde activiteiten. Vanuit de business drivers zijn het logische elementen, want stuk voor stuk beloven ze een bijdrage te leveren aan de effectiviteit en efficiëntie van het ontwikkelen en samen, in balans, maken ze die belofte ook waar.
Toen Microsoft in 2004 Visual Studio Team System (VSTS) introduceerde op de Tech-Ed in San Diego, was al snel duidelijk dat zij precies de juiste snaar ging raken door niet alleen de meeste disciplines samen te brengen in een enkele toolsuite, maar ook middelen te bieden voor geautomatiseerde integratie (denk aan het unittest framework, teambuild en de systemdiagrams) en dit alles te integreren met het ontwikkelproces. Dit levert precies die combinatie van aspecten die kunnen leiden tot productiever ontwikkelen. En nu vier jaar later, met alle ervaringen sindsdien, weten we dat de ‘belofte’ van VSTS
destijds ook waargemaakt kan worden, mits uiteraard de omgeving juist wordt
gebruikt en ingezet, in balans en met een configuratie die past voor de specifieke
situatie van de ontwikkelinspanningen.
Spil in het web van VSTS is Team Foundation Server (TFS) die de rol van issue tracker, change manager, process manager, reporter en repository keeper op zich neemt (figuur 1) en daarmee in feite de
belangrijkste bijdrage levert aan de integraties en de benodigde balans. Sleutel daarbij is uiteraard dat TFS op een juiste manier wordt geconfigureerd voor de situatie waarin het gebruikt wordt. Schaalgrootte, infrastructuur, organisatorische randvoorwaarden en de cultuur zijn daarin belangrijke factoren.
In een wereld van vervagende grenzen, internationalisering, outsourcing en hoge ambities richting standaardisering van tools over verschillende domeinen, wordt het ontwikkelen van software steeds meer een activiteit met een internationaal karakter. Hierdoor krijgt ook een omgeving als TFS een extra dimensie, die van Global Repository. Speciale aandacht is dan nodig voor de opzet van de infrastructuur, de communicatie binnen het ontwikkelproces, het ontwikkelproces zelf en de ‘governance’ van het ontwikkelen. De bijzonderheden van deze aspecten in relatie tot de globalisering van TFS, zijn hier het onderwerp. Samengesteld uit de ervaringen en toekomstplannen van zo’n omgeving in productie, waar meerdere internationale partijen de schaalvoordelen van standaardisatie, centralisatie en samenwerking te gelde willen maken.
figuur 1: Positionering van VSTS en TFS in een Development Tool Landscape.
Globale TSF-infrastructuur
Het technisch belangrijkste bijzondere aspect van het inrichten van TFS in een internationale of mondiale omgeving, is die van de infrastructuur. In de meeste gevallen moeten meerdere domeinen worden overbrugd, moeten firewalls worden doorstoken en krijgen latency en bandbreedte een significante rol. Hiervoor moeten
goede afspraken gemaakt worden met de beheerders van de infrastructuren en
moeten speciale uitzonderingen worden toegestaan om TFS bereikbaar te maken voor de gehele omgeving. Zelfs met de juiste business case blijft dit niet eenvoudig, maar het is wel uitvoerbaar. Dit stelt echter geen speciale eisen aan de inrichting van TFS zelf. Het is dan mogelijk om wereldwijd met een standaard single tier configuratie van TFS het beoogde doel te
bereiken. Anders wordt het als meerdere internationale partijen gebruik gaan maken van de globaal bereikbare TFS. Je krijgt dan direct te maken met de tegenpool van internationalisering: nationalisatie. Software broncode mag niet altijd zomaar over een landsgrens worden getransporteerd. Dit beïnvloedt de bereikbaarheid van TFS zodanig dat hiervoor structurele maatregelen moeten worden getroffen. Met behulp van de mogelijkheid van TFS om alleen work items te synchroniseren tussen
verschillende TFS instanties, kan een
infrastructuur opgezet worden met zogenaamde satelliet servers (figuur 2). In deze opzet kan broncode decentraal worden
beheerd in de nationale repository en gaat dus de landsgrenzen niet over.
figuur 2: Mondiale infrastructuur met satelieten.
Work Item Synchronization tussen TFS servers wordt ingesteld door middel van de Codeplex-tool ‘TFS-to-TFS migration tool’. Dit moet voor iedere satelliet worden uitgevoerd.
Als de landsgrenzen beperking niet geldt, wordt de centrale Global TFS ingezet. Hierdoor kan gebruik gemaakt worden van de integratie met tools waarin TFS (nog) niet voorziet, zoals program
management, functionele testtools en
requirements management (die in die
omgeving ook een globale scope hebben). De integratie met test- en build-omgevingen vindt vaak weer wel plaats via de satellieten, vooral omdat in veel gevallen bij
testen en builden ook externe systemen
betrokken moeten zijn die niet per sé een internationale scope hebben.
figuur 3: Work item synchronisatie tussen TFS servers met behulp van een TFS2TFS server en de Codeplex tool.
De deployment van TFS kan uitgevoerd worden als single tier (figuur 4) en als dual tier (figuur 5). Alleen de laatste is interessant voor een mondiale setting. Enerzijds omdat een internationale schaal in praktisch alle gevallen te groot is voor een
single tier uitvoering van TFS, maar ook vanwege de mogelijkheid bij dual tier
uitvoeringen om TFS redundant uit te voeren op de applicatielaag, waardoor bij calamiteiten de ‘reserve’ server het snel kan overnemen. De dual tier uitvoering biedt de datalaag alle voordelen die SQL server kent bij het opschalen van de omgeving.
Voor locaties die verder van de centrale servers af liggen of die te maken hebben met minder bandbreedte, loont het de moeite om TFS proxy servers in te richten. Deze proxy servers kunnen gedownloade sources cachen waarmee veel minder internationaal netwerkverkeer nodig is en binnen de locaties sneller gedownload kan worden.
Internationale collaboratie
Instant Messaging
Als een project door een klein team in dezelfde ruimte ontwikkeld wordt, is het eenvoudig om van alle details op de hoogte te blijven. Wanneer er echter op meerdere locaties ontwikkeld wordt, is er al snel behoefte aan overleggen, voortgangsrapportages, quality checks etcetera. Vooral als de locaties geografisch ver uit elkaar liggen, blijkt het gebruik van Instant Messaging onontbeerlijk.
Er zijn legio IM systemen beschikbaar en die hebben nut voor een internationaal team, als ze ook beschikken over filesharing en het overnemen van de desktop van een peer. MSN en Office Communicator zijn voorbeelden van dergelijke tools. Nadeel is dat ze ook over de (internationale) domeingrenzen moeten kunnen opereren en door firewalls moeten worden toegelaten.
Met de nieuwste release van de TFS Power Tools (October 2008) is het gebruik van een IM tool nog toegankelijker geworden in TFS. In één oogopslag is in de Team Explorer van Visual Studio de IM status te zien van de teamleden en zijn de IM functies beschikbaar. De Power Tools gaan zelfs nog een stap verder, door ook andere TFS functies met betrekking tot het teamlid beschikbaar te stellen. Volop redenen dus om ze zo snel mogelijk operationeel te maken in de productie-omgeving.
Global Process Authority
Naast directe samenwerking dat onder andere door middel van IM mogelijk wordt gemaakt, bestaat er ook een indirecte
samenwerking. Dit behelst het elkaar
informeren van de uitgevoerde en nog uit te voeren werkzaamheden. TFS biedt
hierin een heel scala aan hulpmiddelen, met als belangrijkste de check-in policies. Door middel van deze policies kunnen aspecten van het ontwikkelen verplicht gesteld worden, zodat de gebruikers gestimuleerd worden informatie te verstrekken over hun werkzaamheden.
Consensus over welke policies wel of niet moeten worden ingevoerd is al lastig binnen een team, laat staan in een internationale omgeving met verschillende culturen en een heel scala aan stakeholders. Het opzetten van een Global Process Authority in de organisatie is hier onontbeerlijk gebleken. Deze groep, ook wel SEPG (Software Engineering Process Group) genoemd, bepaalt welke policies in de process template moeten worden opgenomen en zo dus internationaal helpt zorgen voor de indirecte collaboratie.
Internationaal ontwikkelen
In TFS wordt een ontwikkelproces vastgelegd in een zogenaamde process template. Deze template bevat alle informatie voor de procesondersteuning van een team: definities van de workflows (figuur 7), positie van de project portal (zie ook verderop), de check-in policies, de positie van eventuele templates en de Process Guidance, het geavanceerde proces-help-systeem in TFS. Nu is het mogelijk om meerdere process templates in TFS op te nemen. Dit is enerzijds erg handig voor het kiezen van het meest geschikte proces voor een team, maar impliceert anderzijds ook het grote risico dat er een wildgroei aan templates beschikbaar komt die nauwelijks meer te beheren is. De kans op wildgroei stijgt exponentioneel als TFS internationaal beschikbaar komt, vooral door de taal- en cultuurverschillen van de verschillende partijen.
De wildgroei van process templates kan getemperd worden door expliciet en exclusief het mandaat voor de procesdefinities bij de internationale SEPG te beleggen. Om tegen te gaan dat de SEPG in een ivoren toren wordt geduwd, moet dit vergezeld worden door een zeer laagdrempelige ingang voor de ‘werkvloer’ om wijzigingen en verbeteringen voor te stellen.
De eerste taak hierin voor de SEPG is het internationaal vaststellen van een mondiaal proces op metaniveau. Dit is essentieel om er voor te zorgen dat alle process templates op hoger niveau consistent zijn en biedt tevens het voordeel dat de procesinstanties op essentiële punten dezelfde artefacten (templates, guidelines etc) kunnen hergebruiken.
Distributie van templates
In een situatie met TFS satellieten is het helaas niet zo dat er een eenvoudige distributie van de centrale process templates kan plaatsvinden. Dit heeft vooral te maken met het feit dat de process template naast de procesdefinities, ook gedeeltelijke informatie over de projectomgeving bevat en dat TFS hier (nog) niet dynamisch mee om kan gaan. Hierdoor moet iedere satelliet TFS een eigen set van process templates hebben voor de projecten die in de satelliet TFS omgevingen worden uitgevoerd. En dit betekent weer dat ook de centrale TFS beschikken moet over de satelliet process templates omdat dat nodig is voor de work item synchronisatie. Zie Figuur 8.
Een stringente houding van de SEPG is hier onontkoombaar. In de praktijk blijkt het gelukkig ook werkbaar, omdat alle partijen de voordelen van deze aanpak zien.
figuur 4: TFS als een single tier.
figuur 5: TFS als dual tier.
Governance
Als Team Foundation Server wordt gebruikt in een mondiale omgeving, waarbij zoals eerder beschreven, niet alles een mondiale scope heeft, moet ook speciale aandacht besteed worden aan de governance van het geheel en de delen. Niet alleen vanwege de dynamiek van de scopes, maar ook vanwege het grote aantal stakeholders, de toegankelijkheid van de stuurgegevens, en uiteraard de waarde en onwaarde van de rapportages die TFS kan leveren.
figuur 6: Power Tools in actie voor de schrijvers.
figuur 7: Voorbeeld van een workflow definitie.
Project portals inrichten
Bij het aanmaken van een Team Project wordt ook de mogelijkheid geboden om een project portal toe te voegen. De Sharepoint server waarop dit landt is een instelling van de betreffende TFS. Het is mogelijk om alle satellieten te laten wijzen naar een centrale portalserver, maar dat is onwenselijk om dezelfde reden waarom er überhaupt satellieten zijn. Bij iedere TFS wordt daarom een Sharepoint Server geïnstalleerd die haar lokale projecten ontsluit. Bij de global TFS bestaat een Sharepoint Server die toegankelijk moet zijn voor de gehele omgeving. De te gebruiken Sharepoint template zit ingebakken in de process templates en dat zou betekenen dat alle satellieten de beschikking moeten krijgen over alle Sharepoint templates, net als de process templates zelf. Deze situatie maakt het onoverzichtelijk, zelfs als Team Projects alleen door beheerders worden aangemaakt. Een goede oplossing is om de beschikbare process templates af te schermen van de eindgebruiker. Dit is mogelijk door in de ‘Project Creation Wizard’ pagina’s toe te voegen waarin het gewenste ontwikkelproces en de gewenste portal template apart geselecteerd kunnen worden. Aan de hand van deze gegevens wordt dan onder water de juiste process template geselecteerd.
De URL van de Sharepoint Server is een attribuut van TFS, waardoor het niet mogelijk is om dynamisch een sharepoint server te kiezen voor de portal. Maar met bovenstaande aanpassing is het wel mogelijk om meerdere portaldefinities te ondersteunen bij een gelijke procesdefinitie. Iets dat onontbeerlijk is gebleken in de mondiale setting.
figuur 8: Distributie en synchronisatie van proces templates.
Rapportages op alle niveaus
Om appels met appels te kunnen vergelijken moeten de gegevens van alle TFS satellieten aggregeerbaar zijn. De gegevens worden inherent door het synchroniseren van de work items tussen de TFS satellieten en de globale instantie al netjes bij elkaar geplaatst. De rapportdefinities moeten echter, net als de procesdefinities en de portaldefinities en om dezelfde redenen, over alle satellieten gedistribueerd worden. Ook hier is het weer onontbeerlijk dat een stringent beheer plaatsvindt over de distributie en synchronisatie van de rapportdefinities. Het risico wordt anders snel te groot dat rapportages niet meer consistent zijn en dus hun waarde verliezen.
De belangrijkste rapportage voor het mondiale management is de globale relatieve productiviteit gebleken: uit ieder project wordt de bereikte productiviteit periodiek gemeten en afgezet tegen de voorspelde productiviteit. Dit levert zeer interessante bedrijfsinformatie op.
Integratie met mondiaal
projectmanagement
Een logisch gevolg van het mondiaal positioneren van TFS is dat ook de tooling voor project management mondiaal gepositioneerd wordt. Dit staat op de planning om in 2009 te realiseren. Dit is vooral het gevolg van de afhankelijkheid van de inrichting van de mondiale project management omgeving en ook van de nog minieme integratie tussen TFS en EPM. Het belangrijkste echter is gebleken dat alle projecten zich conformeren aan het werken op basis van work items. Voor teamleden die niet expliciet met Visual Studio werken, zoals project managers, kan de Team System Web Access ingezet worden om het werken met work items een lagere drempel te geven en met het uitkomen van de Shell Extensions bij de TFS Power Tools wordt die drempel nog lager voor het in- en uitchecken van artefacten. Goede ontwikkelingen die gaan bijdragen aan de zo gewilde hogere productiviteit.
Tenslotte
Het inrichten en uitvoeren van een mondiale omgeving voor het ontwikkelen met VSTS is een hele uitdaging, maar zeker niet onmogelijk. Er moet een aantal belangrijke stappen worden gezet op strategisch niveau, maar als die eenmaal geslecht zijn, dan kan een organisatie die TFS kamerbreed wil inzetten, hier over de hele linie veel schaalvoordeel mee halen.
Peter Mazereeuw, is zelfstandig Software Development Consultant en Enterprise Architect bij Archyon IT
Thijs Gerrits, is TFS technology specialist SDMC Factory Support Center bij Atos Origin