René van den Eertwegh werkt als consulent voor Atos Origin Technical Automation. Daar is hij leider van de Atos Origin Performance Improvement-competentie en helpt hij organisaties bij het realiseren van procesverbeteringen.

11 September 2006

Softwaregroepen nemen nogal eens onjuiste beslissingen bij het inrichten van hun configuratiemanagement en zetten tooling verkeerd in. Het gevolg is dat de processen, gereedschappen en scripts de ontwikkelaars onvoldoende ondersteunen en te ingewikkeld en onderhoudsgevoelig zijn. René van den Eertwegh en Randy Marques van Atos Origin Technical Automation leggen uit hoe organisaties deze problemen kunnen voorkomen.

In een ideale wereld is er tijdens de softwareontwikkeling voor elke executable één bronbestand, beheerd door één ontwikkelaar. In de praktijk werken er echter meerdere programmeurs aan een softwareproduct en zijn er verschillende bronbestanden. Degelijk softwareconfiguratiemanagement (SCM) kan uitkomst bieden. Een SCM-systeem is als een steiger bij de bouw van een huis; het biedt niets extra‘s, maar is tijdens de bouw onontbeerlijk.

Ontwikkelaars willen de resultaten van hun collega‘s in een zo vroeg mogelijk stadium gebruiken zonder dat softwarefouten van anderen hen beperken. In de praktijk gaat dat vaak niet goed. Programmeurs in een team gaan uit van een gezamenlijke codebasis. Met deze baseline is het mogelijk een succesvolle build uit te voeren, wat wil zeggen dat alle broncode te compileren en te linken is. Op het moment dat een ontwikkelaar nieuwe of gewijzigde code incheckt en de systeembuild mislukt, staat de ontwikkeling stil totdat de fout gevonden is. Andere ontwikkelaars kunnen hun change-sets namelijk niet meer aan de baseline toevoegen (rebasen). De change-sets van alle ontwikkelaars die met die baseline bezig zijn, groeien zodat de kans groter is dat de volgende check-in faalt. Het proces zit dan in een vicieuze cirkel.

Een andere uitdaging is dat een productversie van een specifieke datum altijd te hergenereren moet zijn. Alleen dan kunnen ontwikkelteams problemen of afwijkingen achterhalen. Deze 100 procent reproduceerbaarheid is niet alleen afhankelijk van de bronbestanden, maar ook van alle make-files, procedures en handmatige instellingen. In de praktijk blijkt het archiveren hiervan lang niet altijd goed te gaan en is de reproduceerbaarheid niet gegarandeerd. In zo‘n geval zijn de SCM-gereedschappen gedegradeerd tot een uiterst kostbaar back-upsysteem.

Zero level promotion

Struikelblokken

Veel problemen met SCM-systemen ontstaan doordat ze de gebruikers verre van optimaal ondersteunen. Dit komt onder andere door het gebrek aan expertise bij de definitie en invoering ervan. Organisaties kiezen er vaak voor om de uitvoerder van het SCM ook in te zetten als consulent en implementeerder. Dat is goedkoper, maar deze persoon is vooral operationeel ingesteld en concentreert zich op de gereedschapsfunctionaliteit. Daarbij mist hij de stappen om een effectief en efficiënt systeem te definiëren vanuit de SCM-concepten. Het resultaat is dat veel mogelijkheden van het systeem elkaar tegenwerken en dat de gebruikers het SCM vooral als last ervaren en niet als ondersteuning.

Deze struikelblokken zijn te overkomen door een goede opzet en uitvoering van SCM. Om ontwikkelaars andermans resultaten zo snel mogelijk te laten gebruiken zonder de beperkingen van hun fouten, passen we een model toe voor baseline-promotie (zie kader). Dit model geeft aan hoe je van de ene naar de andere baseline overgaat. Een baseline definiëren we hierbij als een complete set van bestanden die allemaal correct compileren en linken. Dit geldt voor alle varianten ervan, zoals verschillende platforms of hardware. De baseline moet voldoen aan een minimale kwaliteit. Vaak kennen we aan de baselines vertrouwenslabels toe, zoals ’unit tested‘, ’system tested‘, ’beta tested‘.

Daarnaast volgt een goed SCM-systeem een degelijk release-promotiemodel (kader) om ervoor te zorgen dat de software altijd exact hergenereerbaar is. Een release is een baseline van voldoende kwaliteit voor externe levering.

Release promotion

Baseline- en releasepromotie zijn twee verschillende zaken die we goed uit elkaar moeten houden.

Voor beide concepten zijn er verschillende modellen. De geschiktheid hangt af van de karakteristieken van het product en de ontwikkelgroep. Pas als deze modellen goed zijn gedefinieerd komen keuze, aanpassing en gebruik van de tools aan de orde. Gereedschappen zijn immers alleen maar een manier om een gekozen model te implementeren, en niet andersom.

Naast het gebruik van deze modellen is strikt buildmanagement nodig. Een bewezen concept hiervoor is Generic Build Support (GBS). Het biedt absolute zekerheid dat wat je hebt gebouwd ook herbouwbaar is met hetzelfde resultaat. GBS is een simpele en transparante oplossing. Het is flexibel waar nodig en rigide waar flexibiliteit niet nodig is. Daarnaast is het applicatiegeneriek en onafhankelijk van het SCM-systeem en het targetplatform. Een aantal softwareontwikkelorganisaties gebruikt momenteel GBS, waaronder die van Atos Origin Technical Automation.

Rollen

Een goed SCM-systeem is te verkrijgen door bij de opzet, introductie en uitvoering onderscheid te maken in verschillende expertiseniveaus. We onderscheiden daarom drie verschillende SCM-rollen: de consulent, de implementeerder en de uitvoerder. De consulent analyseert de SCM-problematiek en komt met oplossingen, adviseert bij de toolkeuze en definieert hoe het gereedschap en de processen eromheen aangepast moeten worden aan de situatie. Verder begeleidt hij het veranderingsproces en assisteert hij de implementeerder.

De implementeerder snijdt de gereedschappen op maat. Deze persoon dient expert te zijn van de gekozen tool en gedegen kennis van programmeren in scripting-talen te hebben. Bij een goed opgezet SCM-systeem, dat gebaseerd is op eenvoudige en werkbare oplossingen, zijn de inzet van de consulent en de implementeerder na de invoering niet meer nodig.

De uitvoerder ten slotte houdt zich bezig met de dagelijkse SCM-activiteiten voor één of meerdere projecten. Hij integreert bijvoorbeeld de verschillende bijdragen en voert smoke-tests uit, maar geeft geen advies en wijzigt geen scripts.

Een goed SCM-proces kenmerkt zich door eenvoudige, werkbare oplossingen. Daarnaast is het bruikbaar bij alle projecten binnen een organisatie. Dat bespaart tijd bij de opstart van een project en minimaliseert het onderhoud van de tooling en de opleiding van de gebruikers.