Hoe kun je succes bereiken met DevOps en continuous delivery? Tijdens een ontbijtsessie van Quint over dit onderwerp ging IT-consultant Erikjan Niejenhuis dieper in op het traject dat ABN AMRO doorloopt om de volledige CI/CD-keten te stroomlijnen en zo een goede basis te leggen voor de grootschalige adoptie van DevOps bij de bank, in 2019.

Softwareontwikkeling is volop in beweging. Gedreven door de eindgebruiker, die steeds meer en steeds vaker nieuwe functionaliteit eist, moeten organisaties softwareontwikkeling opschalen. Tegelijkertijd heeft IT-beheer vaak moeite om bij te blijven en mee te gaan met de steeds hogere eisen van de eindgebruiker als het gaat om snelheid, kwaliteit en beschikbaarheid. Alleen een integrale aanpak, waarbij het organiseren van de juiste processen, technologie en nieuwe manieren van werken vooropstaan, brengt succes.

ABN AMRO legt basis voor DevOps

DevOps biedt uitkomst, zo ontdekt momenteel ook ABN AMRO. Als grote, internationaal opererende bank, met wereldwijd zo’n 20.000 medewerkers en miljoenen zakelijke en particuliere klanten, is het bedrijf sterk afhankelijk van IT. Bij de bank werken intern zo’n 1.800 IT’ers; daarnaast is er sprake van zo’n 5.600 gecontracteerde IT-medewerkers. Vorig jaar begon de bank met agile transformatie en werden de public-cloudplatforms AWS en Azure geïntegreerd.

Ook werden er – als opmaat voor de introductie van DevOps, in het eerste kwartaal van 2019 – flinke stappen gezet op het vlak van continuous integration en continuous delivery (CI/CD), schetst Erikjan Niejenhuis, voorheen werkzaam bij ABN AMRO als IT-consultant. “Kijken we naar de volledige delivery-cycle van definiëren, ontwikkelen, testen, releasen en runnen, dan strekt DevOps zich over die volle breedte uit.

Eerder hebben we ons in het kader van agile gericht op het stroomlijnen van die eerste drie fases; met CI/CD hebben we de afgelopen periode benut om ook de releasefase te stroomlijnen, als basis voor de komende uitrol van DevOps.”

Om teams bekend te maken met DevOps ontwikkelde ABN AMRO een playbook: een document dat de uiteenlopende facetten van DevOps uitgebreid belicht. “In het playbook komt onder meer aan de orde wat DevOps betekent voor de manier waarop je team is georganiseerd. Teams zullen meer multi-skilled en T-shaped moeten gaan werken en meer teamoverstijgend gaan denken.

Hoe kun je zo’n cultuur bewerkstelligen? Welke werkprocessen horen daarbij? En: wat betekent DevOps voor je IT-landschap? Maar vooral de bijbehorende technologieën, zoals continuous testing, integration & delivery en system monitoring worden uitgebreid besproken. Wat betekent DevOps in technische zin voor je werkproces?”

Problemen

Op die enabling technologies gaat Niejenhuis graag dieper in. Lange tijd liep ABN AMRO tegen een aantal problemen aan, vertelt hij. “Het duurde heel lang voordat software, getest en wel, in productie belandde. De tijd tussen het eerste idee en de daadwerkelijke ingebruikname bedroeg soms wel zes maanden.

Ook de kwaliteit was af en toe ondermaats; er werd niet goed of heel laat getest, wat in de laatste fase voor productie of zelfs daarna weleens leidde tot grote failures. Ook bevatte het hele proces veel handmatige stappen en code werd pas heel laat in het proces samengevoegd. Dat is lastig als er tientallen teams tegelijkertijd aan dezelfde code werken, zoals bij ingewikkelde ketens als internet banking. Ten slotte vond Ops vaak ook nog allerlei dingen nadat software in productie werd genomen.”

Pipelines

In 2015 al begon de bank met het creëren van CI/CD-bewustzijn en werden er op zowel centraal als decentraal niveau zaken in gang gezet. “Op decentraal niveau organiseerden we onder meer strategische sessies, zetten we hackathons op, en nodigden we externe sprekers uit om meer over het onderwerp te vertellen.”

Op centraal niveau werd de weg geplaveid voor de invoering van CI/CD door het opzetten van de juiste tooling – zoals Nexus en Jenkins – en het bouwen van pipelines die de hele keten van bouw tot deployment automatiseren en zo de brug slaan tussen development en operations.

“De insteek van een pipeline is dat niemand er meer met zijn handen aan kan komen”

“De insteek van een pipeline is dat niemand er meer met zijn handen aan kan komen”, licht Niejenhuis toe. “Teams sturen aan de voorkant code de pipeline in, waarna er aan de andere kant volledig geautomatiseerd resultaten uitkomen. Uitgangspunt daarbij is dat fouten zo snel mogelijk worden gedetecteerd. Om te garanderen dat de software goed getest wordt, hebben we in het proces verschillende build breakers ingebouwd.

Zo wordt de codekwaliteit automatisch gescand en wordt er op afhankelijkheden gecontroleerd. Gaat er tussentijds iets fout? Dan krijgt het team automatisch feedback. Wordt de code goedgekeurd, dan gaat deze automatisch naar Nexus, van waaruit de code kan worden gedeployd.”

Shift left

De volgende stap was het meer ontzorgen van het Ops-deel. “We hebben nu ook het change-proces gestroomlijnd door ervoor te zorgen dat changes niet meer standaard kunnen worden ingeschoten. We maken nu onderscheid tussen patches, minor changes en major changes, wat de efficiency enorm heeft bevorderd.” Inmiddels heeft ABN AMRO een flink aantal CI-pipelines ontwikkeld voor onder meer FrontEnd, Java en Microsoft. Het gevolg: kortere feedbackloops en een betere codekwaliteit.

“De pipeline garandeert een ‘shift left’-werkwijze: tests vinden niet meer aan het einde van de keten plaats, maar aan het begin. Daardoor worden fouten snel ontdekt. En doordat de developer voortdurend feedback krijgt en ervan leert, gaat de kwaliteit over de gehele linie omhoog. Al met al een goede manier om software snel, goed getest in productie te krijgen. En een uitstekende opmaat voor de invoering van DevOps, komend jaar.”

‘Nog te weinig focus op security en operations’

Welke transformaties zijn er binnen Operations en qua technologie nodig om de overgang naar cloud en DevOps goed vorm te geven? Volgens Andreas Prins, VP product development bij XebiaLabs, is de transitie richting cloud een van de belangrijkste veranderingen die zich momenteel binnen het IT-landschap voltrekken.

“Die cloudtransitie heeft een veel grotere impact dan veel mensen denken. Zo zal de snelheid waarmee we veranderingen naar productie brengen enorm omhooggaan. De introductie van agile/scrum bracht ons van een cyclus van drie maanden naar een van twee weken; de cloudtransitie zal die cyclus nog verder verkorten. Dat heeft vooral te maken met de kleinere deploymentunit – die het makkelijker maakt om kleine veranderingen snel te releasen – en omdat de onderliggende infrastructuur, de cloud zelf, veel vaker aan veranderingen onderhevig is.”

Die drastisch toenemende snelheid heeft een enorme impact op operations, vervolgt Prins. “Als een team drie keer per dag een verandering naar productie wil brengen maar de change-approval board komt maar één keer per week bijeen, dan is daar sprake van een enorme disconnect.”

Een andere valkuil is volgens Prins de onevenredig grote nadruk die nu ligt op development. “De development-engineer bepaalt hoe de cloud eruitziet en heeft daardoor een enorme executiekracht. Je kunt in dit verband bijna spreken over DevDev. Terwijl we eigenlijk naar Dev-Ops, of misschien zelfs wel OpsDev toe zouden moeten groeien.”

“Teams groeien in 5 stappen naar een anti-fragile DevOps-cultuur”

Al met al is er binnen de hele delivery-cycle te weinig focus op security en operations, constateert Andreas Prins. “Als je als organisatie daadwerkelijk wil versnellen, zul je werk moeten maken van het automatiseren van die twee gebieden. Dat kan door bijvoorbeeld het hele changeproces te automatiseren en de approval al aan het begin van je pipeline te beleggen.

Dat klinkt in eerste instantie vreemd, maar het is – zo heb ik zelf bij ING ervaren – goed mogelijk. Alles wat er aan de voorkant ingaat, is goedgekeurd. In de pipeline wordt de code vervolgens volledig geautomatiseerd onderworpen aan tal van tests, waaronder een performance-test en een vulnerability scan.

Ook zijn er ingebouwde build breakers die alarm slaan als er fouten ontdekt worden, zodat je ervan op aankunt dat de uitkomst altijd goed is. Zo bezien leidt een OpsDev-aanpak tot ‘first time right thinking’ en daarmee tot goede software.”

‘Benoem gewenst gedrag zo concreet mogelijk’

Binnen DevOps-transformaties ligt er vaak veel nadruk op technologie. Maar cultuur- en gedragsverandering zijn minstens even belangrijk als het gaat om het smeden van high-performanceteams, betoogt principal consultant Dave van Herpen van Quint. Volgens Van Herpen gaat DevOps veel verder dan alleen maar het samen in één team zetten van Dev en Ops.

“Uiteindelijk gaat DevOps om het creëren van waarde door volledige verantwoordelijkheid in teams neer te leggen. DevOps-cultuur en DevOps-gedrag vormen de basis voor het creëren van high-performanceteams en het realiseren van de vier hoofddoelstellingen van DevOps-transformaties: een hogere tevredenheid onder gebruikers, klanten en medewerkers, een betere dienstverlening, een kortere time-to-market en time-to-value, en meer efficiency en kostenreductie.”

Volgens Van Herpen groeien teams in vijf stappen toe naar een anti-fragile DevOps-cultuur. Binnen zo’n anti-fragile team proberen teamleden te leren van fouten vanuit de gedachte dat die goed zijn voor het lerend vermogen en de veerkracht van de organisatie. Om daartoe te komen is het volgens Van Herpen essentieel om goed te definiëren welk gewenst gedrag daarbij hoort. Termen als ‘transparantie’, ‘samenwerking’ en ‘feedback’ horen gevoelsmatig allemaal bij een Dev-Ops-way-of-working, maar wat betekent dat nu concreet?

Van Herpen raadt organisaties die het optimale uit DevOps willen halen en ‘anti-fragile’ willen worden aan om te beginnen met een workshop, waarin het hele team gewenste gedragingen identificeert en benoemt. De belangrijkste gedragingen moeten vervolgens zo concreet mogelijk worden vertaald in kleinere, zicht- en meetbare eenheden.

Gedrag, zo stelt Van Herpen, is alles wat je iemand anders ziet doen of hoort zeggen. Zo kan een weinig specifiek containerbegrip als ‘verbeteren’ concreet worden gemaakt door de volgende concrete gedraging te formuleren: ‘Elk ernstig incident wordt gevolgd door een evaluatiebijeenkomst. Hier komt geen schuldvraag op tafel maar is iedereen vrij om verbeterideeën en -kansen aan te dragen.’

Door typische DevOps-waarden als ‘multidisciplinair’, ‘transparantie’ en ‘verbeteren’ op deze manier te operationaliseren in zicht- en meetbare gedragingen, ontstaat volgens Van Herpen een concreet instrumentarium om stapsgewijs een bepaalde cultuur te kweken en wordt het ook makkelijker om teamleden hierop aan te spreken.

Arnoud van Gemeren is hoofdredacteur van CIO Magazine, Boardroom IT en voormalig hoofdredacteur van TITM (Tijdschrift IT Management) en Outsource Magazine. Hij heeft een lange staat van dienst in de Nederlandse IT-mediawereld. Na een start bij een redactiebureau, was hij als hoofdredacteur van 1996 tot 2001 bij uitgeverij Array Publications verantwoordelijk voor diverse IT-vakbladen. In 2001 sloot hij zich aan bij een adviesbureau op het gebied van marketingcommunicatie, Beatrijs Media Group. Vanuit dit bureau bleef hij als hoofdredacteur actief, onder meer voor Sdu Uitgevers.

REAGEREN

Plaats je reactie
Je naam