Releasemanagementproces voor teams die vaak uitbrengen
7 min lezen
Een releasemanagementproces is de reeks stappen die een wijziging van “gemerged” naar “draait in productie en is uitgelegd aan de mensen die het raakt” brengt. Voor een team dat vaak uitbrengt komt het neer op zeven stappen: de scope plannen, de wijziging isoleren, bouwen en testen, goedkeuren, deployen en verifiëren, communiceren en terugblikken. Elke stap heeft één benoemde eigenaar en één exitcriterium nodig, anders stopt hij stilletjes.
Deze gids gaat uit van een team van 5 tot 50 engineers dat wekelijks of dagelijks deployt en wil dat het proces uit de weg blijft.
| Stap | Eigenaar | Exitcriteria |
|---|---|---|
| 1. De scope plannen | Product- of techlead | De lijst met wijzigingen in deze release is opgeschreven en alles wat riskant is, is gemarkeerd |
| 2. Branch of flag | De engineer die de wijziging bezit | Werk staat op een kortlevende branch of achter een flag, zodat main uitbrengbaar blijft |
| 3. Bouwen en testen | CI, met de auteur oproepbaar bij fouten | Pipeline groen op exact de commit die live gaat |
| 4. Goedkeuren | Reviewer, plus releasemanager bij riskante wijzigingen | Review klaar, rollbackpad benoemd, go of no-go vastgelegd |
| 5. Deployen en verifiëren | Releasemanager of on-call engineer | Gedeployd, smoke checks slagen, foutpercentage en latency komen overeen met de baseline van voor de release |
| 6. Communiceren | Wie de wijziging begrijpt, geredigeerd door iemand die dat niet doet | Release notes gepubliceerd waar gebruikers lezen, support en sales geïnformeerd |
| 7. Terugblikken | Releasemanager | Metrics gelezen, alles wat misging heeft een eigenaar en een fix |
Wat is het releasemanagementproces?
Het is het herhaalbare pad dat een wijziging volgt om gebruikers te bereiken: scope, bouwen, testen, goedkeuren, deployen, verifiëren, aankondigen en terugkijken. Het nut van opschrijven is dat elke release hetzelfde pad volgt, zodat iemand op vakantie, een nieuwe collega of een on-call engineer om 2 uur ‘s nachts het kan draaien zonder iemand te vragen hoe het werkt.
Wat zijn de verschillende soorten releasemanagement?
Er zijn drie praktische soorten: continuous deployment, geplande releases en gereguleerd change management. Ze verschillen in hoeveel er vóór een release gebeurt en hoeveel is geautomatiseerd. Continuous deployment brengt elke gemergede wijziging uit, geplande releases bundelen wijzigingen in een trein, en gereguleerd change management voegt formele goedkeuring en een audittrail toe.
| Continuous deployment | Geplande releases | Gereguleerd of ITIL-change management | |
|---|---|---|---|
| Releaseeenheid | Eén gemergede pull request | Een batch, wekelijks of tweewekelijks | Een wijzigingsverzoek |
| Scopestap | Impliciet, de merge is de scope | Releaseplanningsoverleg | Wijzigingsrecord met risicoscore |
| Goedkeuring | Codereview plus geautomatiseerde checks | Releasemanager keurt de batch goed | Change advisory board of gedelegeerde goedkeurder |
| Risicobeheersing | Feature flags, canaries, snelle rollback | Staging-soak, release candidate | Gedocumenteerd backoutplan, onderhoudsvenster |
| Gebruikelijke frequentie | Vele per dag | Wekelijks tot maandelijks | Bepaald door de wijzigingskalender |
| Zwak punt | Niemand vertelt gebruikers wat er veranderde | Grote batches verbergen de wijziging die iets brak | Procestijd overstijgt de wijziging zelf |
De meeste teams zijn een mix. Een SaaS-product deployt misschien continu terwijl de mobiele app op een wekelijkse trein gaat, en de ene betalingsservice waar auditors om geven een formeel wijzigingsrecord volgt. Kies het soort per service, niet per bedrijf. Waar wijzigingen maar geleidelijk zichtbaar worden, zijn de release en de aankondiging aparte gebeurtenissen, het geval dat wordt behandeld in release notes bij feature flags.
Wat zijn de verantwoordelijkheden van een releasemanager?
Een releasemanager bezit het pad dat een wijziging naar productie volgt. Hij houdt de releasekalender bij, beslist of een wijziging klaar is, draait of superviseert de deploy, neemt het rollbackbesluit, zorgt dat gebruikers worden geïnformeerd en leidt daarna de review.
Vóór de release bevestigt hij de scope en controleert hij dat elke riskante wijziging een rollbackpad heeft. Tijdens de release draait hij de deploychecklist, bekijkt hij de eerste minuten van de productiemetrics en roept hij vroeg een rollback uit. Daarna bevestigt hij dat de notes zijn uitgegaan en legt hij vast wat er in het proces moet worden verbeterd.
In een klein team rouleer je de rol wekelijks en schrijf je de checklist zo dat niemand impliciete kennis nodig heeft. Een monorepo met veel onafhankelijk uitgebrachte packages heeft meestal een releaseverantwoordelijke per package nodig, anders wordt de rol een bottleneck.
Wat zijn de belangrijkste KPI’s voor releasemanagement?
Volg de DORA-metrics voor softwarelevering en voeg er zelf een toe: hoe lang het duurt voordat gebruikers worden geïnformeerd. Het onderzoek van DORA onderscheidt vijf metrics, verdeeld in doorvoer (change lead time, deployfrequentie, hersteltijd na mislukte deployments) en instabiliteit (change fail rate, deployment rework rate).
De gids van DORA definieert ze in gewone taal (dora.dev, software delivery metrics):
| KPI | Wat het meet | Waar je op let |
|---|---|---|
| Change lead time | Tijd van commit in versiebeheer tot gedeployd in productie | Een stijgend getal betekent meestal wachtrijen in review of goedkeuring |
| Deployfrequentie | Hoe vaak je deployt, of de tijd tussen deployments | Dalende frequentie betekent dat batches groeien |
| Hersteltijd na mislukte deployment | Tijd om te herstellen van een deployment die direct ingrijpen vraagt | Problemen met rollback en alerting komen hier naar boven |
| Change fail rate | Aandeel deployments dat een rollback of hotfix vraagt | Stijgt als batches te groot zijn of testen te mager is |
| Deployment rework rate | Aandeel deployments dat ongepland is en door een productie-incident komt | Een teken dat fixes sneller live gaan dan lessen |
| Tijd tot gebruikers zijn geïnformeerd | Minuten van productiedeploy tot een gepubliceerde, voor gebruikers bedoelde note | Meet het zelf, geen framework levert het |
Oudere bronnen noemen vier sleutelmetrics en noemen herstel “time to restore”. De huidige gids gebruikt de vijf hierboven.
Dezelfde gids waarschuwt ertegen deze als doelen te behandelen. Een doel stellen als “alles deployt aan het eind van het jaar meerdere keren per dag” nodigt teams uit de cijfers te manipuleren, en de metrics zijn bedoeld om per applicatie of service te worden gelezen, niet gemengd over het hele bedrijf. Zijn praktische advies om ze allemaal te verbeteren is de omvang van elke wijziging te verkleinen, omdat kleinere wijzigingen makkelijker te reviewen zijn, sneller door de pipeline gaan en makkelijker te herstellen zijn.
Hoe past releasecommunicatie in het releasemanagementproces?
Het is stap zes, en heeft net als elke andere stap een eigenaar en een exitcriterium: notes gepubliceerd waar gebruikers lezen, en interne teams geïnformeerd. Teams slaan het het vaakst over, omdat deploytooling succes meldt zodra de code live is.
De goedkoopste manier om deze stap op schema te houden is de entry te schrijven wanneer de wijziging merget, niet wanneer de release live gaat. De pull request bevat al de titel, de auteur, de gekoppelde issue en de context. Een concept daaruit wordt bewerkt, niet een week later uit het hoofd geschreven. Dat is het idee achter changelog-automatisering: leid bij de merge een concept af, houd het vast voor goedkeuring door een mens en publiceer het dan overal vanuit één bron. Changeloop werkt zo: het stelt met AI entries op uit gemergede pull requests en houdt ze vast voor goedkeuring voordat er iets wordt gepubliceerd.
Twee varianten loont het vooraf te plannen. Support en sales hebben een andere note nodig dan klanten, en daar dienen interne release notes voor. Een door een incident gedreven release heeft geen tijd voor de normale conceptlus, dus houd een kort sjabloon klaar, zoals beschreven in noodrelease notes. De release notes template geeft je een startvorm voor de klantgerichte versie.
Hoe houd je het proces licht?
Automatiseer elk exitcriterium dat een machine kan controleren en bewaar mensen voor de afwegingen. Een groene pipeline, een deploymarker op de dashboards en een conceptentry voor elke gemergede pull request zijn controleerbaar. Of een rollbackplan geloofwaardig is, of de notes voor een klant te begrijpen zijn, vraagt een persoon.
Om het proces te testen kies je een release van vorige maand en vraag je of iemand buiten het team uit alleen het schriftelijke verslag kon opmaken wat er is uitgebracht, wie het goedkeurde, hoe het is geverifieerd en wanneer gebruikers zijn geïnformeerd. Elk gat is je volgende verbetering.
FAQ
Wat is het verschil tussen releasemanagement en change management? Releasemanagement zorgt dat een set wijzigingen wordt gebouwd, getest, gedeployd en aangekondigd. Change management, in de zin van ITIL, is het goedkeurings- en risicoproces rond elke wijziging. Teams die vaak uitbrengen vouwen goedkeuring in codereview en geautomatiseerde checks.
Hoe vaak moeten we uitbrengen? Zo vaak als je tests en rollbackpad toelaten, wat voor veel webteams dagelijks of vaker is. De richtlijn van DORA is de omvang van elke wijziging te verkleinen, omdat kleine wijzigingen makkelijker te reviewen en te herstellen zijn.
Hebben kleine teams een releasemanager nodig? Ze hebben de verantwoordelijkheden nodig, niet per se de titel. Rouleer de rol tussen engineers, geef degene aan de beurt een schriftelijke checklist en zorg dat iemand elk van de zeven stappen bezit.
Wat moet een releasechecklist bevatten? Scope bevestigd, pipeline groen op de commit die live gaat, rollbackpad benoemd, goedkeuring vastgelegd, smoke checks na de deploy, metrics vergeleken met de baseline, release notes gepubliceerd, support geïnformeerd en een review gepland. Houd het bij één pagina.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.