Beheer

Software-ontwikkeling
beheerder

Stop de terreur van de releaseweekenden!

Dan maar geen taart

© CC0: Pixabay.com,  Geralt
4 februari 2021

Je kent ze wel. Maandagochtenden, met gebak op de afdeling. Het releaseweekend is namelijk weer succesvol geweest. Zonder kritische incidenten nog wel. Dat moet gevierd worden! Maar vieren we dan wel het juiste resultaat? Belonen we dan het juiste gedrag? Hebben we dan het juiste probleem opgelost? Nee, nee en nee.

Zelfs IT’ers hebben een leven. Ze willen op zaterdagavond (post-Corona) ook gewoon de kroeg in. Of in het weekend bij de kinderen langs de lijn staan. En dus niet 24x7 doorwerken om die cruciale, nieuwe release live te zetten. Iedere dag groeit het aantal mogelijkheden om applicaties, data en infrastructuur te migreren naar modulaire en flexibele oplossingen.

Architectuur moderniseren

Organisaties die ervoor kiezen hier niet in te investeren, riskeren daarmee het verlies van hun beste engineers. Er zijn namelijk genoeg werkgevers die wél oog hebben voor het welzijn en een gezonde werk-privébalans van hun IT-professionals. Die respect tonen voor hun medewerkers door hun architectuur te moderniseren via immutable infrastructure of microservices. Onder de vlag van DevOps- of Continuous Delivery-trajecten wordt het zo steeds eenvoudiger de gewenste functionaliteiten volledig geautomatiseerd, gevalideerd en op ieder gewenst tijdstip in productie te zetten.

Autonome teams kunnen binnen hun eigen scope vaak al veel verbeteringen doorvoeren en technische schuld wegwerken. Door hun code structureel te rationaliseren en tijd in te ruimen voor refactoring. Ook hier is het relevant dat de klant (vaak in de vorm van een product owner) door het team wordt meegenomen in de waarde (business value) van dit soort onderhoudswerkzaamheden.

Fundamentele keuzes

Echter, substantiële en ketenbrede modernisering van de architectuur vraagt om meer dan het bovenstaande team zelf aankan. Dit vraagt om fundamentele keuzes op breder (portfolio)niveau, die vaak leiden tot een volledig herontwerp van de infrastructuur en platformen. Net als bij het team, willen we ook hiervoor de waarde kunnen aantonen. Dit is nodig om, samen met de business, expliciete keuzes te kunnen maken. Even minder aandacht (lees: capaciteit) voor nieuwe functionaliteit, en wat meer voor hervorming van het landschap.

Zolang organisaties er niet in slagen om voldoende capaciteit vrij te maken voor deze organisatiebrede modernisering, komen we nooit af van het fenomeen releaseweekenden. We houden heldengedrag hiermee in stand. Als onze architectuur niet is ingericht voor deployments gedurende werkdagen, zullen de  teams hun avonden of weekenden hieraan blijven spenderen. En door die taart op maandagochtend, waarin we laten zien hoezeer we dit waarderen, blijft onze aandacht afgeleid van de échte grondoorzaak. Deze terreur moet stoppen. Dan maar geen cake op maandag.

 

Reactie toevoegen
1
Reacties
Hans Bezemer 05 februari 2021 09:50

Nooit een release weekend meegemaakt dat 24/7 duurde. Doe een test op je A-omgeving, maak een goed PvA en je bent in een morgen klaar. Immers, het meeste werk was (in die tijd) het overzetten van de grote hoeveelheden gegevens.

En ja, vaak was dat gewoon in de avonden. Op werkdagen. Immers, de dienstverlening moet over gaan. Het werd al een stuk eenvoudiger met de invoering van webtechnologie. Dan was het een uurtje werk. Eten we even wat later. Kleinere (bug)patches deden we gewoon overdag.

We hadden een heel stelsel van samenhangende applicaties, gebouwd rond de "Wiel-architectuur". Een framework hielp ons bij de ontwikkeling. De meeste apps maakten we in een of twee weken - echt Agile, niet SCRUM.

Wat anders is, is de technologie. Ja, door middel van containers kan je nog sneller releasen en ben je in een half uurtje klaar. Maar het allerbelangrijkste is de werkwijze. Gestructureerd, gedocumenteerd en uitgekiend.

Dat veel bedrijven dit nog steeds niet beheersen, ligt aan hun eigen onprofessionaliteit en cowboymentaliteit. We zien dat terug in de CMMI cijfers. Het aantal bedrijven dat "the bare minimum" op dat gebied heeft ingericht wordt nog steeds gemeten in "single digits". Daar gaat DevOps niks aan veranderen.