(2/4) Pluk de vruchten van een goed ontwikkelproces met DORA-Metrieken: Change Failure Rate

DORA-metrieken zijn ontwikkeld door het DevOps Research and Assessment (DORA) team van Google, dat jarenlang onderzoek heeft gedaan naar de prestaties van de best presterende DevOps-teams. Op basis van dit onderzoek hebben ze vier metrieken opgesteld waarmee je de prestaties van een DevOps-team kunt beoordelen. In deze reeks lichten we steeds een van de metrieken nader toe.

In het vorige artikel gingen we dieper in op Deployment Frequency, deze keer gaan we echter kijken naar de Change Failure Rate.

Wat is Change Failure Rate

Change Failure Rate is een van de vier kernmetrieken van DORA. De naam zegt het eigenlijk al: het gaat over hoe vaak wijzigingen die naar productie worden gedeployed resulteren in fouten, denk aan incidenten, outages of rollbacks.

Waarom is dat belangrijk?

Zoals in het vorige artikel besproken, kun je bij een ICT-bedrijf code vergelijken met voorraad in een fruitwinkel.

Het is fantastisch als je snel nieuwe producten in het schap kunt leggen, maar als jij als klant telkens rot fruit koopt, dan stap je snel over naar een andere aanbieder. Bij software werkt het precies zo: als een applicatie vaak faalt of onbeschikbaar is, verliezen gebruikers al snel hun vertrouwen.

Als je als klant een ICT-oplossing afneemt die 10% van de tijd onbeschikbaar is of storingen vertoont, dan is de kans groot dat je op zoek gaat naar een alternatief. Vertrouwen in je product of dienst is dus van groot belang en dat bouw je alleen op door structureel kwaliteit te leveren.

Hoe verlaag je je Change Failure Rate?

Net zoals een fruitwinkel werkt met kwaliteitscontrole om te voorkomen dat bedorven producten in het schap terechtkomen, kun je als DevOps-team verschillende strategieën toepassen om de kans op fouten in productie te verkleinen:

1. Shift-left security
Vroeg in het ontwikkelproces aandacht besteden aan veiligheid en kwaliteit loont. Door securitychecks, codeanalyse en kwaliteitscontroles al in je CI-pipeline te integreren, voorkom je dat kwetsbaarheden pas in productie worden ontdekt. Zie het als een kwaliteitsinspectie in het distributiecentrum, nog voordat het fruit de winkel bereikt. Dat is immers goedkoper dan eerst het fruit vervoeren en dan erachter komen dat het rot is.

2. Automatische tests

Door unit tests, integratietests en end-to-end tests te automatiseren, kun je fouten sneller en consistenter detecteren. Net zoals een fruitwinkel een machine kan gebruiken om op kleur en vorm te sorteren, kun jij tooling inzetten om fouten eruit te filteren voordat ze schade aanrichten.

Hoe beter je testdekking, hoe kleiner de kans dat een bug “mee glipt” naar productie. Dit verhoogt niet alleen de betrouwbaarheid, maar ook het vertrouwen van developers in het deploymentproces, omdat ze weten dat alle tests slaagden voordat ze deployen.

3. Proactieve notificaties en alerting

Foutgevoelige code is vaak moeilijk te begrijpen, slecht gedocumenteerd of niet modulair opgebouwd. Door in te zetten op clean code, duidelijke documentatie en herbruikbare componenten, maak je je codebase stabieler én eenvoudiger aan te passen. Je voorkomt daarmee dat een kleine wijziging onbedoeld grote gevolgen heeft.

Onderhoudbare code betekent ook: sneller bugs oplossen wanneer ze zich wél voordoen, omdat je precies weet waar je moet kijken.

Conclusie

Een lage Change Failure Rate draait om kwaliteit, vertrouwen en continu verbeteren. Het is fijn als je snel kunt leveren, maar het is nog veel waardevoller als je klanten ook tevreden blijven met wat ze krijgen.

Door te investeren in preventie (shift-left), detectie (testen) en onderhoudbare code, creëer je een proces waarin fouten de uitzondering zijn.

Net als een goede fruitwinkel bouw je aan een reputatie waar mensen graag voor terugkomen, omdat ze weten dat ze elke keer kwaliteit krijgen.

En nu?

Benieuwd waar jouw team staat op het gebied van Change Failure Rate? Download dan onze whitepaper of neem contact op met het Gitlab expert service team. En blijf deze serie volgen, want in het volgende deel gaan we in op Mean Time to Recovery: hoe snel ben je weer online als het tóch misgaat?