Ontwikkelstraat voor .NET; inleiding

 
11 februari 2008

In een serie artikelen zal ik, samen met gastschrijvers, de opzet van een ontwikkelstraat voor .NET software behandelen. Het afgelopen jaar ben ik namelijk driemaal betrokken geweest bij het opzetten van deze voorzieningen. De bedrijven liepen uiteen van een bedrijf voor CNC machines, een wereldwijde speler in de kledingbranch en een klein registratiebedrijf met grote klanten die tot voor kort specials ontwikkelde voor kortstonding gebruik. Voor het artikel zal zoveel mogelijk gebruik worden gemaakt van open source tools die voor iedereen toegankelijk zijn. Enkele onderwerpen die aan bod gaan komen zijn het opzetten van het versiebeheer, de buildserver met buildscripts en de integratie met unittesting.

Inleiding

Een ontwikkelstraat is de basis van je softwareontwikkeling. Het gaat hier vooral om de middelen en richtlijnen die nodig zijn om software te kunnen ontwikkelen. Het bouwen van software is veelal een repeterende actie van code schrijven, bouwen en testen. Nadat de ontwikkelaar zijn code in een code archief wil plaatsen, begint het leuk te worden. De wijzigingen van mogelijke collega’s staan hier ook. De acties van bouwen en testen zullen dus weer plaatsvinden. Vaak is het zo dat als de ontwikkelaar zijn stukje ziet werken al snel weer denkt aan de verdere ontwikkeling. Hier begint het verhaal van de buildserver:

  • De buildserver haalt op een trigger op interval het project uit het versiebeheer en zal deze in een sandbox omgeving builden. Het geeft hiermee een feedback of de code in het archief dus bouwbaar is of niet. Code dat in het archief staat moet altijd bouwbaar zijn en bij voorkeur zelfs zonder extra tools. Het bijkomende punt is dat hiermee ook de invloed van een developers werkstation wordt weggenomen. Persoonlijk heb ik het vaak zien gebeuren dat software het op het ene werkstation wel deed, maar niet bij een collega ontwikkelaar.
  • Unittests zijn tests die garanderen dat de software modules de geleverde functionaliteit bieden die gevraagd wordt in requirements. Doort het opstellen van testcases kun je aantonen dat een functie werkt zoals verwacht. Mocht er een wijziging plaatsvinden waardoor software niet reageert zoals verwacht, zijn fouten vaak door het runnen van deze tests simpel te vinden. Voor afhankelijkheden in de code is het dus een essentieel middel. Daarom zal de buildserver ook deze tests runnen na elke build. Het geeft tevens een goede indicatie over de voortgang van het project.
  • De buildserver genereert bij voorkeur de setups en deployables voor een project.

Versiebeheer levert hierbij de onmisbare undo-functionaliteit aan de ontwikkelaars. Het moet een duidelijke inzage leveren in het verloop van de versies en het mogelijk maken dat meerdere mensen aan hetzelfde project kunnen werken.

Allereerst zal ik beginnen over het grootste obstakel dat je zult tegenkomen bij de invoering van een ontwikkelstraat. Dit is namelijk de menselijke kant. Misschien dat ik daarom eerst meer moet vertellen over de bedrijven waar ik een ontwikkelstraat heb geintroduceerd. Het eerste bedrijf waar ik een dergelijke ontwikkelstraat heb ingevoerd was een snel groeiende onderneming. Hun software bestond enkele jaren geleden uit het het maken van een custom-made oplossing van assembler programma’s. Er was een begin gemaakt om dit generieker op te lossen door een C++ applicatie te ontwikkelen. Al snel was duidelijk dat dit, net als de assembler oplossing, tijdrovend zou zijn. De oplossing werd uiteindelijk gevonden in Visual Basic. Toen volgde de introductie van het .NET framework. Hierdoor werd de basis herbruikt met een op basis van NET 1.0 ontwikkelde CNC applicatie. Deze integratie van VB componenten en .NET code zorgde uiteindelijk voor problemen die verdere ontwikkeling in de weg stonden. Het ontwikkelteam bestond vooral uit pas afgestudeerden die veelal geleerd hadden om in Java te ontwikkelen. Mijn taak was om het team op een hoger niveau te krijgen en de oude Visual Basic componenten te desintegreren om verder in .NET 2.0 te ontwikkelen. Wat mij vooral opviel was dat management, en deels ook wel het team zelf, niet betrokken was bij de ontwikkeling. Versiebeheer vond plaats middels SourceSafe en issues werden bijgehouden in spreadsheets. Er was een dringende behoefte om dit te wijzigen… er werden namelijk met de maand meer machines uitgerold met deze nieuwe software.

Het tweede bedrijf wilde juist graag de stap maken om een buildserver in te zetten. Alleen door de strikte deadline was het niet mogelijk gweeest dit op te zetten. Mijn taak was om manieren te vinden om de ontwikkeltijd te bekorten en bugfixes uit te voeren. Tijdens het schrappen van tijdrovende oplossingen heb ik een buildserver opgezet met unittesting. Het team bestond hier wel uit ervaren mensen die hiervoor in Delphi en Java hadden ontwikkelt. Het versiebeheer dat hier gebruikt werd was Subversion, maar dat was pas onlangs in gebruik genomen. De moeilijkheid was vooral het vinden van een manier om de huidige QA niveaus te ondersteunen.

Het laatste bedrijf groeit ook snel. Hierdoor komt er veel meer druk op de ontwikkelaars te liggen. Ze willen nu een generieke oplossing die voor de verdere ontwikkeling kan dienen. Het probleem is vooral dat het team zich niet betrokken voelt bij de nieuwe ontwikkeling. Ze weten dat de communicatie beter kan. Het probleem komt vooral uit de voorgaande situatie waarbij de ontwikkelaars vrijwel individueel werkten aan de applicaties, van aanpassing tot bugfixing. Wanneer de registratieprocedure voorbij was, was er nog maar voor korte tijd ondersteuning nodig. Issues werden eigenlijk niet bijgehouden en versiebeheer bestond uit het kopieren van files, waardoor een duidelijk versieverloop moeilijk te achterhalen was.

De eerste stappen

Het team moet zich duidelijk betrokken voelen bij de ontwikkeling. Mijn eerste oplossing die ik daarom aandraag is tot het instellen van een dagelijkse standup meeting. Het idee komt vanuit SCRUM en zorgt dat er een duidelijk overzicht in de taken die mensen uitvoeren. Het kan lastig zijn om dit goed voor elkaar te krijgen. Daarom dat ik er ook persoonlijk voor heb gekozen om dit voor het eerste bedrijf als een wekelijkse meeting voor te stellen. Bij deze meeting was ook de manager betrokken die op basis van de ondervonden problemen tijdig kon ingrijpen en afspraken maken met sales.

Management zal ook niet blij worden van woorden als ‘buildserver’. Veelal wordt de associatie gelegd met geld. Er wordt namelijk tijd verbruikt waarvan niet duidelijkis wat het oplevert, de extra hardware die het zou kunnen kosten, etc. Het is vergelijkbaar met het argument voor refactoring! Ik heb dit zelf ook ondervonden. De beste oplossing is om het dan maar te forceren. Ik heb een simpel systeem gepakt en voorzien van voldoende geheugen en een goede harddisk. De buildserver heb ik toen ook ‘BOB, the Buildserver’ genoemd. Een geeky acronym voor Build Operator BOB. Het bestond uit een Windows 2003 server, CruiseControl geintegreerd met Sharepoint en Virtual Server.

BOB the Buildserver

Als code was ingechecked werd deze gebouwd en als deployable in een Virtual Machine ingeladen. Hier werden dan unittests uitgevoerd en het resultaat kwam op een Sharepoint-site te staan. Op een LCD panel was te zien middels een stoplicht (kleine WPF applicatie) of de build geslaagd was. Binnen een twee weken vroeg management al een beetje gekscherend: ’staat het stoplicht nog op groen?’ Nog geen half jaar later werd BOB vergezeld van een ‘Wendy, the Virtual server’. Deze virtual server diende als een middel voor de support afdeling om klanten bij te staan. Het was merkbaar dat de gehele afdeling naar het scherm keek als er een commit plaatsvond. Zelfs management voelde mee als het stoplicht onverhoopt op rood stond! Hieronder staat een screenshot van het ontwerp van het stoplicht… en de code wordt in een later artikel vrijgegeven.

Ampel

Soms staat management er niet bij stil, maar de ontwikkelafdeling moet men zien als een klein bedrijfje binnen de gehele onderneming. Te vaak worden er geen duidelijke afspraken gemaakt met deze afdeling; ontwikkeling wordt gezien als een simpele taak. Tijdsplanning wordt dus veelal te krap genomen wat niet bijdraagt aan het uitvoerig testen van de deliverable. Om deze omslag voor elkaar te krijgen , zal verandering veel tijd kosten en binnen een enkele onderneming zal dat helaas gebeuren door vallen en opstaan. Het klinkt bijna als cliche; wanneer er requirements zijn, dan is het ook duidelijker waar de ontwikkeling aan toe is. Toch falen de meeste projecten bij een gebrek hieraan. De requirements bepalen naast de tijdsindeling ook de tests die er moeten zijn. Zoals je hierboven kunt lezen, maakt een buildserver de afdeling wel inzichtelijker voor juist mensen van het management. Indien de ontwikkelaars een duidelijk beeld hebben en hier ook in enige mate invloed op hebben, zullen ze zich meer betrokken voelen.

De invoering van een duidelijke structuur helpt bij het leveren van een kwaliteitsniveau. Zo kun je dus ook denken aan codingstyles. Een goede start kan zijn de Brad Abrams : Internal Coding Guidelines of SharpDevelop C# Coding Style Guide. Let op dat je keuzes maakt die het beste past bij de mensen. Deze documenten behandelen ook niet alles. Als het nodig mocht zijn voor de code, laat deze structuur dan ook blijken met een simpel document als een common practice. Zo heb ik ook beschreven over hoe om te gaan met Exception handling en interfaces. Het is dan aan het team te merken dat ze een houvast hebben.

Tijdens de rest van de artikelen zal ik ook aangeven wat voorkomende problemen zijn die optreden bij de invoering van bijvoorbeeld het versiebeheer, e.a. Ter afsluiting wil ik je ook nog wijzen op de beschrijving van Thomas Zeeman over de opzet van een Project Server voor Java ontwikkeling.

Links

SCRUM in five minutes


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development, Deployment, .Net

Tags: , , ,


Reacties (3)

  • Xavier Chamuleau schreef:

    Gerard, wij zijn inmiddels overgestapt van CruiseControl naar Hudson voor zowel Java als .NET projecten.

    Geplaatst op 14 maart 2008 om 10:39 Permalink

  • Gerard Braad schreef:

    Het probleem met de plaatjes was mij bekend en moet nu opgelost zijn…

    Geplaatst op 13 februari 2008 om 9:27 Permalink

  • Jaap Taal schreef:

    Ik ben benieuwd naar het vervolg van dit verhaal!
    De plaatjes laten het bij echter afweten.

    Geplaatst op 13 februari 2008 om 1:43 Permalink