Q
terug

Alleen een integrale aanpak brengt succes met DevOps

Hoe kun je succes bereiken met DevOps en Continuous Delivery? Tijdens een recente ontbijtsessie, gereorganiseerd door Quint, werd vanuit het paradigma People, Process en Technology dieper ingegaan op de vraag hoe de transformatie naar DevOps echt succesvol te krijgen en hoe een goede basis gelegd kan worden voor grootschalige adoptie.

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 voorop staat, 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 cloud-platforms 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 Continous Integration en Continuous Delivery (CI/CD), schetst schetst Erikjan Niejenhuis, tot voor kort 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 multiskilled 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

Erikjan NiejenhuisOp die enabling technologies gaat Niejenhuis graag dieper in. Lange tijd liep ABN AMRO tegen een aantal problemen aan, schetst 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 tot wel zes maanden. Ook de kwaliteit was soms ondermaats; er werd niet goed of heel laat getest, wat in de laatste fase voor productie of zelfs daarna nog soms leidde tot grote failures. Ook bevatte het hele proces veel handmatige stappen. Code werd verder pas heel laat in het proces samengevoegd, wat lastig is als er soms wel tientallen teams tegelijkertijd aan dezelfde code werken, zoals het geval is bij ingewikkelde ketens als internet banking. En 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 development en operations. ‘De insteek van een pipeline is dat niemand er meer met zijn handen aan kan komen’, schetst Niejenhuis. ‘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, vanwaaruit de code kan worden gedeployd.’

Shift left

De volgende stap is 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 ontwikkelde ABN AMRO een flink aantal CI-pipelines 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 al van een cyclus van drie maanden naar een cyclus van twee weken; de cloudtransitie zal die cyclus nog verder drastisch verkortten. Dat heeft vooral te maken met de kleinere deployment unit – die het makkelijker maakt om kleine veranderingen snel te releasen – en omdat de onderliggende infrastructuur, de cloud zelf, veel vaker aan veranderingen onderhevig is.’

Andreas PrinsDie 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, 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 DevOps, of misschien zelfs wel OpsDev toe zouden moeten groeien.’

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 zijn die alarm slaan als er fouten ontdekt worden, zodat je ervan op aan kunt 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-performance teams, 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 goede waarden en andere functies en rollen. DevOps-cultuur en DevOps-gedrag vormen de basis voor het creëren van high-performance teams en het realiseren van de vier hoofddoelstellingen van DevOps-transformatie: 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.’

Dave van HerpenVolgens 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 DevOps 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: ‘Elke 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 ‘mutidisciplinair’, ‘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.

Tags
DevOps