Onlangs heb ik een bezoek gebracht aan een conferentie met als thema 'configuration management for complex products'. Eén van de onderwerpen die de revue passeerden ging over het 'verkopen' van het vakgebied configuration management (cm) binnen je organisatie. Tijdens de discussies hierover bedacht ik me dat het vakgebied cm ook binnen de Computable-kringen zelden aan bod komt, met onderstaand artikel tot gevolg.
Veel van de lezers zullen configuration management wellicht kennen als onderdeel van ITIL of ITSM. Echter, ook binnen systems engineering kennen we de discipline configuration management. De historie van deze variant gaat terug naar halverwege de vorige eeuw, waar het Amerikaanse ministerie van defensie configuration management gebruikte voor het beheren van hun hardware configuraties.
Deze aanpak is in de loop der jaren verder uitgegroeid en wordt vandaag de dag ook veelvuldig toegepast bij het ontwikkelen van software. Dit klinkt misschien als een verrassing voor sommigen, maar bijna iedereen die wel eens software geschreven heeft, heeft hiermee (al dan niet bewust) te maken gehad.
Een heel simpel voorbeeld wat we allemaal wel kennen:
Programma_v0.0.cpp
Programma_v0.1.cpp
Inderdaad, de basis van configuration management ligt in het versiebeheer. Dit voorbeeld laat echter ook meteen het probleem zien van deze aanpak: voor iedere versie verandert de naam van het bestand. Niet handig dus omdat je dan telkens de verwijzingen aan moet passen.
Gelukkig zijn er diverse pakketten die ontwikkelaars hierbij kunnen ondersteunen. Met behulp van deze pakketten verwijs je altijd naar programma.cpp, en wordt op de achtergrond zorg gedragen voor versiebeheer. Deze tools bieden ook diverse extra's, zoals kunnen vergelijken met vorige versies, toevoegen van commentaar wanneer een nieuwe versie in het systeem gezet wordt et cetera.
De uitdaging komt echter pas als je gebruik gaat maken van functionaliteiten als branching en merging. Hiermee kun je onder andere parallelle ontwikkeltrajecten uitvoeren, maar deze technieken worden ook gebruikt wanneer men meerdere versies van eenzelfde product moet onderhouden (lifecycle management).
Configuration management gaat dan niet alleen meer over versiebeheer, maar ook over het maken van strategische keuzes hoe de diverse productlijnen te kunnen ondersteunen. Combineer dit met complexe producten (miljoenen regels code, verdeeld over meerdere subsystemen) en levensduur van software die de tien jaar met gemak overstijgen, dan begint vaak pas het besef te komen dat configuration management een vak apart is, waarbij reproduceerbaarheid voorop staat.
Wanneer ik dat uitleg, krijg ik vaak de vraag waarom je configuration management zou moeten doen. Hiervoor gebruik ik graag bijgevoegde illustratie. Dit heeft weliswaar niets met softwareontwikkeling van doen, maar laat heel simpel zien wat er kan gebeuren als diverse partijen met verschillende versies van een bestand (in dit geval een bouwtekening) werken.
Voor de meeste lezers zal het weinig moeite kosten deze parallel door te trekken naar softwareontwikkeling.
