Hoe beheer (en distribueer) je versies van software zo optimaal mogelijk, waarbij de meest recente versie van de software in gebruik is bij eindgebruikers en wordt onderhouden door ontwikkelaars. Dat is in grote lijnen het belangrijkste vraagstuk als we het over releasebeheer hebben.
Martin Michlmayr doet als student onderzoek naar de kwaliteit van gratis software en heeft zich daarbij met name gericht op releasebeheer. Doel van zijn onderzoek is het in kaart brengen van verbeterpunten die hij in het ontwikkelproces van gratis software traceert. Hij richt zich met name op de wat grotere en complexe projecten waarbij minimaal 100 personen zijn betrokken bij het moment van releasen. Daarbij focust hij vooral op de vraag hoe en waarom releasebeheer functioneert bij grootschalige gratis softwareprojecten, waarbij sprake is van vooraf afgesproken tijdslijnen (bijvoorbeeld iedere 6 maanden een nieuwe versie).
In zijn journal beschrijft Martin de resultaten van zijn onderzoek dat hij binnen zeven projecten heeft uitgevoerd. Per project schetst hij het soort software dat wordt onderhouden, welke problemen de projecten in eerste instantie ondervonden, hoe deze issues zijn opgepakt en welke huidige problemen er nog open staan.
Bij de meeste projecten zie je dat het releasebeheer in eerste instantie vrij ongeorganiseerd was opgezet. Tijdslijnen werden (ruimschoots) overschreden en het was vaak niet duidelijk wat nu exact de status van een release was (niemand had het overzicht). Ook valt te lezen dat bij de wat langere trajecten er veel wijzigingen in de code werd aangebracht waardoor deze moeilijk was te stabiliseren. Dat had vervolgens weer een negatieve invloed op de hoeveelheid testtijd die overbleef. Door inrichting van strak en georganiseerd releasebeheer, een betere planning met kortere doorlooptijden en het verbeteren van de documentatie en communicatie rondom releases valt af te leiden dat de meeste projecten genoemde problemen voor een groot deel hebben kunnen oplossen.
Als je de huidige, nog openstaande problemen bekijkt, zie je vooral het issue van regressie nog optreden. Regressie is het onbedoeld introduceren van fouten in software als gevolg van systeemaanpassingen. Populair gezegd: je past ergens in de software iets aan en op een andere plek valt er iets om. Doordat de focus zich in het testproces veelal richt op de betreffende aanpassingen, wordt vaak vergeten te controleren of het systeem in z’n geheel nog wel correct functioneert. Hier komt ook het tijdsaspect om de hoek kijken, doordat regressietesten (dus testen gericht op het traceren van regressie) nog wel eens veel meer tijd kosten dan het testen van de wijziging zelf. Zeker als een project niet de beschikking heeft over een bestaande regressietestset, een set van testgevallen waarmee een deel, of zelfs een geheel systeem kan worden getest.
De projecten die Martin beschrijft zullen dus tijd en energie moeten gaan steken in het samenstellen en onderhouden van een regressietestset. Zeker bij projecten waarbij meerdere releases op de planning staan, kan die tijd en energie worden terugverdiend. Het is en blijft echter een leuke uitdaging het projectmanagement van het nut van die inspanning te overtuigen.
Technorati Tags: Releasebeheer, regressie, regressietestset, regressietesten