Uitgangssituatie
Een snelgroeiend SaaS-bedrijf liep vast op zijn releases. Ze duurden lang, gingen geregeld mis en hingen af van een paar mensen. Dat remde de productontwikkeling.
- Traag: een release was een project op zich.
- Risicovol: handmatige scripts, en configuratie die per omgeving uit de pas liep.
- Belastend: deployments buiten kantooruren.
Aanpak
Continue integratie
Elke commit startte een build, unittests en een securityscan.Automatisch testen
Per featurebranch een tijdelijke testomgeving (via Terraform) voor integratie- en end-to-end-tests.Veilig uitrollen
Blue/green-deployments naar productie: de nieuwe versie draaide naast de oude en nam het verkeer pas over als ze werkte. Bij fouten automatisch terugdraaien, en feature flags voor een gecontroleerde uitrol.
Wat het opleverde
Pipeline
Testomgevingen
Uitrol
Deze case heeft geen eigen, publiceerbare cijfers over het effect. Wel wat we ervan leerden.
Lessen uit de praktijk
- Begin bij het proces: value stream mapping (de keten van idee tot productie stap voor stap in kaart brengen) liet de grootste knelpunten zien. Eerst het proces, dan de techniek.
- Cultuur boven tools: tools zijn het makkelijke deel. Wat telde, was dat het team verantwoordelijkheid nam voor “zijn” code in productie.
- Feature flags: deployment (techniek) en release (business) stonden los van elkaar, zodat het team zelf bepaalde wanneer een functie live ging.
- Meetbare voortgang: de afspraak was de voortgang te volgen met DORA-metrics, zoals de doorlooptijd en het percentage mislukte wijzigingen.
Wat onderzoek zegt
Het DORA-onderzoek van Google Cloud volgt al jaren hoe softwareteams leveren. In het Accelerate State of DevOps Report 2024 is het verschil tussen de best en de slechtst leverende teams groot. Deze cijfers komen uit dat onderzoek, niet uit deze case:
- Doorlooptijd van een wijziging
- 127 keer zo kort
- Deployments per jaar
- 182 keer zo veel
- Mislukte wijzigingen
- 8 keer zo weinig
- Herstel na een mislukte deployment
- 2293 keer zo snel
Het gaat om een enquête onder de teams zelf, en om samenhang, niet om oorzaak en gevolg. Wel wijst het onderzoek al jaren dezelfde kant op: vaker en kleiner leveren gaat samen met minder fouten, niet met meer.