Met de toenemende complexiteit van softwareprojecten wordt configuratiemanagement er niet makkelijker op. Frank Schophuizen van Topic betoogt daarom dat we CM niet meer in isolatie moeten zien, maar beter kunnen kijken naar het ontwikkelproces als geheel.
Oorspronkelijk bestond configuratiemanagement (CM) voornamelijk uit version control, gericht op het beheer van wijzigingen in individuele bestanden. Check-out en check-in, locking en version history waren gangbare concepten. Branches en work spaces kwamen later en maakten ontwikkeling in projectteams en parallelle ontwikkeling mogelijk, labels legden de basis voor baselines en databasereplicatie gaf de mogelijkheid van multisite ontwikkeling – internetconnectiviteit stond toen nog in de kinderschoenen.
Een belangrijke stap voorwaarts was de notie dat wijzigingen van individuele files niet onafhankelijk van elkaar zijn. Door gerelateerde aanpassingen te groeperen in change sets – ook wel tasks of activities genoemd – ontstond task-based CM. En door de change sets te koppelen aan change requests (CR‘s) en problem reports (PR‘s) werd change management een onderdeel van configuratiemanagement. Een CR/PR doorloopt verschillende stadia volgens een gedefinieerde lifecycle, waardoor we sturing kunnen geven aan de wijzigingen, in de vorm van planning, autorisatie, voortgangsbewaking en vrijgave.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.
