Bij GENIUS — het project waar ik als DevOps Engineer werkte — was ik naast mijn technische rol ook Release Manager. Release Manager klinkt als iemand die op een knop drukt en zegt: “deploy maar.”
De realiteit: vijf klanttypes, elk met eigen eisen, eigen planningen, en een eigen idee over wat “klaar” betekent. En één release pipeline die iedereen tegelijk wilde gebruiken.
Vijf klanten, vijf werelden
De klanttypes waren fundamenteel verschillend:
- Interne ontwikkelteams — die wilden zo snel mogelijk kunnen deployen. Voor hen was “klaar” als de code op de testomgeving stond.
- Testteams — die wilden een stabiele omgeving met voorspelbaar gedrag. Voor hen was “klaar” als ze een week hadden kunnen testen zonder veranderingen.
- NAVO-oefenteams — die wilden een bevroren versie die gegarandeerd werkte tijdens een oefening. Geen updates, geen verrassingen.
- Externe algoritmeleveranciers — bedrijven die hun software op ons platform lieten draaien en hun eigen releasecyclus hadden.
- De operationele gebruiker — die wilde gewoon dat het werkte als hij het nodig had, zonder gedoe over versienummers.
Elke klant had gelijk. Maar ze konden niet allemaal tegelijk hun zin krijgen.
De oplossing: zichtbaarheid
Mijn aanpak was niet om slimmer te plannen of harder te werken. Het was om zichtbaar te maken wat eerst onzichtbaar was.
Ik bouwde een release-overzicht waar elke stakeholder kon zien:
- Wat staat gepland voor welke release?
- Wanneer wordt welke omgeving bijgewerkt?
- Wie is verantwoordelijk voor welk onderdeel?
- Wat is de status van de huidige release?
Dit klinkt triviaal — een planning maken. Maar het verschil was dat deze planning niet mijn planning was. Het was ónze planning. Elke stakeholder zag zijn eigen belang terugkomen. Elke klant begreep waarom de release op een bepaald moment gebeurde en niet eerder.
De OTAP-straat (Ontwikkeling, Test, Acceptatie, Productie) werd het ritme waarop iedereen danste. SITL en HITL (Software/Hardware in the Loop) werden geïntegreerd in de releasestraat zodat simulatie geen apart proces was maar onderdeel van de flow.
Wat ik leerde
Release management is verwachtingsmanagement. Het technische deel — de pipeline, de deploy, de rollback — is het minst interessante. Het echte werk is zorgen dat iedereen weet wat er gaat gebeuren en waarom.
Vijf klanten hebben vijf versies van “urgent”. Als je elke “dit moet nú live” serieus neemt, heb je geen releaseproces meer — dan heb je een doorgeefluik. Mijn taak was om urgentie te toetsen: is dit echt urgent, of is het ongemakkelijk dat het moet wachten? Meestal was het het tweede.
Een releasekalender is een sociaal contract. Zodra die kalender er staat en iedereen hem heeft gezien, wordt de vraag niet meer “wanneer kan dit live” maar “past dit in de volgende release.” Dat is een subtiele maar fundamentele verschuiving van reactie naar regie.
Voorspelbaarheid is waardevoller dan snelheid. De klanten die in het begin het hardst riepen om snellere releases, waren uiteindelijk het blijst met voorspelbaarheid. Als je weet dat er elke twee weken een release is, kun je plannen. Als je niet weet wanneer de volgende komt, ben je altijd aan het wachten.
Dit was het moment waarop ik snapte dat procesontwerp net zo’n echt engineeringvak is als infrastructuur bouwen. Het gereedschap is anders — maar de denkwijze is hetzelfde.