Configuratie­management voor software

01 · Definitie

Wat is software configuration management?

De definitie van NIST, uit SP 800-128:

De IEEE Computer Society past configuratiemanagement toe op programma's, scripts en documentatie. Voor een deliveryteam beantwoordt het vier vragen over een release: wat erin zit, wie het heeft gewijzigd en waarom, waar het draait, en of dat overeenkomt met wat er is vastgelegd.

Is SCM hetzelfde als versiebeheer?

Nee. Versiebeheer bewaart de geschiedenis van bestanden. SCM bepaalt wat onder beheer valt, welke versies samen een release vormen, wie ze mag wijzigen en hoe u aantoont wat er draait. Git is voor SCM wat het grootboek is voor de boekhouding.

Wat is het verschil met changemanagement?

Changemanagement beslist of en wanneer een wijziging in productie komt. Configuratiemanagement legt vast hoe het systeem is samengesteld, voor en na die wijziging. De twee komen samen in de wijzigingsbeheersing.

02 · Het model

Wat zijn de vier activiteiten van configuratie­management?

Het klassieke model kent vier activiteiten. IEEE 828 behandelt het identificeren van configuratie-items, het beheersen van wijzigingen en het rapporteren van hun status, en noemt configuratie-audit onder de trefwoorden. NIST SP 800-128 verdeelt het werk in vier fasen: planning, het identificeren en implementeren van configuraties, het beheersen van configuratiewijzigingen, en monitoring.

1. 1

   Configuratie-identificatie

   Bepaal wat onder beheer valt en geef elk item een identiteit. In een pipeline is dat meer dan code: pipelinedefinities, buildscripts, lockfiles, basisimages, omgevingsconfiguratie en infrastructuurcode.

2. 2

   Wijzigingsbeheersing

   Wijzigingen aan een item in een baseline worden beoordeeld en goedgekeurd voordat ze worden doorgevoerd. DORA stelde vast dat goedkeuring het best werkt als peer review tijdens de ontwikkeling, en vond geen bewijs dat een formelere externe beoordeling het percentage mislukte wijzigingen verlaagt.

3. 3

   Statusregistratie

   De registratie van elk item door baselines en releases heen. Die hoort uit systemen te komen: commitgeschiedenis, buildmetadata, deploylogs. Een spreadsheet die met de hand wordt bijgehouden, is bij de volgende merge al verouderd.

4. 4

   Configuratie-audits

   Het bewijs dat het product overeenkomt met de registratie. Het handboek van NASA onderscheidt er twee: een functionele audit toetst aan de hand van testresultaten of aan de eisen wordt voldaan; een fysieke audit toetst of het gebouwde product overeenkomt met de build-to baseline.

03 · Baselines

Wat is een baseline?

NIST definieert een baselineconfiguratie als een set specificaties voor een systeem of configuratie-item, op een bepaald moment formeel beoordeeld en vastgesteld, en alleen te wijzigen via wijzigingsbeheersing. Elke release is er een.

ClearCase UCM maakt het expliciet: een baseline identificeert één versie van elk element in een of meer componenten. In Git legt een commit elk bestand in de repository vast, dus verschuift het werk naar wat daarbuiten ligt: afhankelijkheden, basisimages, pipelines en configuratie.

• Markeer releases met geannoteerde of ondertekende tags, die volgens de documentatie van Git bedoeld zijn voor releases. Verplaats nooit een releasetag.
• Zet afhankelijkheden vast met een lockfile in de repository, en images op digest, niet op een tag zoals latest.
• Leg bij elke release de versie van de configuratie vast.

04 · Branching

Welke branchingstrategie kiest u?

Een branchingstrategie bepaalt hoe lang wijzigingen gescheiden blijven en waar een release wordt gestabiliseerd. De regel van Martin Fowler voor elke branch: bedenk hoe u hem gaat mergen voordat u hem aanmaakt.

Twee vragen geven in de meeste gevallen de doorslag. Hoeveel versies draait u in productie? Meer versies vragen om releasebranches. Hoe vaak integreert u? Het advies van Fowler: probeer uw integratiefrequentie te verdubbelen.

05 · Builds en artifacts

Hoe maakt u een build reproduceerbaar?

De strenge norm komt van het Reproducible Builds-project: met dezelfde broncode, buildomgeving en buildinstructies kan elke partij bit voor bit identieke artifacts opnieuw maken. De praktische norm komt eerst: bouw een release opnieuw vanaf zijn tag en krijg hetzelfde resultaat. Beide vereisen dat u alles vastzet wat de build inleest.

• Buildinstructies. De pipelinedefinitie en de buildscripts staan in de repository. Volgens DORA horen ook scripts voor packaging en deployment in versiebeheer.
• Afhankelijkheden. Een lockfile in de repository. npm beschrijft package-lock.json als de exacte boom die is gegenereerd, zodat latere installaties identieke bomen opleveren.
• Buildomgeving. Het buildimage, vastgezet op zijn digest: volgens Docker een onveranderlijke identifier. Het image krijgt geen beveiligingsupdates tot u die digest bijwerkt.

Bouw één keer, promoot hetzelfde artifact

Per omgeving opnieuw bouwen levert elke keer een ander artifact op. Fowler beschrijft de regel die veel organisaties hanteren: eenmaal gecompileerd, draait hetzelfde uitvoerbare bestand in elke omgeving. Semantic Versioning verbiedt de inhoud van een uitgebrachte versie te wijzigen. Bewaar van het artifact de digest en de provenance, die SLSA omschrijft als verifieerbare informatie over waar, wanneer en hoe het is geproduceerd.

06 · Omgevingen

Waar hoort configuratie per omgeving thuis?

Omgevingsconfiguratie is wat verschilt tussen test, staging en productie: endpoints, groottes, feature switches, credentials. Daarvoor gelden twee regels.

Houd configuratie buiten de build. De vuistregel van Fowler: u moet elke versie van het product kunnen uitchecken en in elke omgeving kunnen draaien, met de verschillen in configuratiebestanden of omgevingsvariabelen.

Houd configuratie onder wijzigingsbeheersing. Volgens DORA horen infrastructuur- en applicatieconfiguratie in versiebeheer, zodat u elke omgeving automatisch kunt inrichten en de geschiedenis ervan kunt opvragen. In de praktijk: een configuratierepository of inventory, net als code beoordeeld en door een pipeline toegepast, zoals bij infrastructure as code. Secrets blijven in een secrets manager; de configuratie verwijst er alleen naar.

Hoe detecteert u configuratiedrift?

Drift is het verschil tussen de gedeclareerde en de draaiende configuratie. NIST SP 800-128 geeft monitoring een eigen fase, om misconfiguraties en ongeautoriseerde wijzigingen op te sporen. De check mode van Ansible meldt wat een playbook zou veranderen, zonder iets te veranderen; diff mode toont de situatie ervoor en erna.

# Show drift, change nothing
ansible-playbook site.yml \
  --check --diff \
  --limit production

Modules zonder ondersteuning voor check mode melden niets, dus een run zonder bevindingen is een signaal, geen bewijs. Plan de run periodiek in en behandel bevindingen als defecten. GitOps gaat verder en reconcilieert continu.

07 · Traceerbaarheid

Hoe volgt u een wijziging van verzoek tot release?

Traceerbaarheid is statusregistratie die u kunt bevragen: van een draaiende versie terug naar het verzoek, en van een verzoek vooruit naar waar het draait. Elke stap moet het ID van de vorige stap vastleggen.

Een snelle test: neem een release van vorig kwartaal en meet hoe lang u over vier antwoorden doet. Welke commits? Wie keurde goed? Welke tests slaagden? Welk artifact draait nu? Als daar een vergadering voor nodig is, ontbreekt er een schakel.

08 · In de praktijk

Hoe ziet configuratie­management er op grote schaal uit?

Bij Nike werden de upgrades van Windows-servers in 900+ winkels met de hand uitgevoerd, verdeeld over vijf teams: 6 tot 8 uur per server, twee servers tegelijk. Eén self-service pipeline bracht dat terug tot ongeveer 3 uur per server, met 8 servers parallel, zoals de Nike-case beschrijft.

Vanuit configuratiemanagement bekeken is een upgrade van het hele serverpark één wijziging die honderden keren wordt toegepast. Vijf teams met een checklist houden vijf onvolledige registraties bij; één pipeline houdt één definitie en één rungeschiedenis bij. Herhaald herstelwerk is ook een signaal: bij Nike draaide een herstel van device-profielen 80 keer per week, telkens ongeveer 35 minuten. Dat werd een kwestie van één klik.

Bij ASML draaide self-service CI voor het domein Stage Position Measurement op Linux, in omgevingen met Git en met ClearCase, gestandaardiseerd voor meerdere teams en de eigen testomgevingen van ASML: dezelfde vier activiteiten op twee heel verschillende versiebeheersystemen. Meer daarover in de ASML-case.

09 · Tools

Welke tools heeft configuratie­management nodig?

Geen enkele tool doet configuratiemanagement in zijn eentje. Elke activiteit hierboven leunt op een ander soort tool, en de meeste teams hebben die al:

De tools zijn minder belangrijk dan de koppelingen ertussen: een ticketnummer in elke commit, een commit in elke build, een build in elk deploymentrecord.

10 · Zelftest

Is uw configuratie­management klaar voor een audit?

Loop deze punten na voor één recente productierelease. Elke regel is een ja of een nee.

Waar begint u?

Kies één releaseflow. Tag releases met geannoteerde tags, leg bij de deploy de digest van het artifact vast en laat de pipeline het change record schrijven. Dat dekt identificatie, statusregistratie en het meeste auditbewijs, nog voordat u een tool kiest.

11 · Begrippen

Begrippenlijst

Baseline

Een vastgestelde set versies op een bepaald moment, die alleen via wijzigingsbeheersing verandert.

Change control board

De groep die wijzigingen met grote impact goedkeurt.

Configuratie-item

Alles wat als één geheel wordt beheerd: een service, een library, een pipeline, een instellingenbestand.

Digest

Een hash van de inhoud die precies één artifact aanduidt. Anders dan een tag kan een digest niet verschuiven.

Drift

Het verschil tussen de gedeclareerde configuratie en de configuratie die werkelijk draait.

Functionele configuratie-audit

Controleert aan de hand van testresultaten of het product aan zijn eisen voldoet.

Fysieke configuratie-audit

Controleert of het gebouwde product overeenkomt met zijn build-to baseline.

Promotie

Hetzelfde artifact naar de volgende omgeving brengen zonder het opnieuw te bouwen.