Derk-Jan de Grood is senior testmanager en Agile-coach bij Valori. Hij is auteur van het boek ‘Agile in de echte wereld - Starten met Scrum’.

25 June 2018

In 2017 organiseerde Derk-Jan de Grood drie interactieve sessies waarin hij samen met de deelnemers analyseerde wat er nodig is voor een succesvolle implementatie van continue integratie en deployment (ci/cd). Twee van deze sessies waren tijdens de Software-Centric Systems Conference op 4 oktober, de andere op 11 oktober tijdens het najaarscongres van Testnet. Ci/cd blijkt meer dan een technische uitdaging; er zijn raakvlakken met veel aspecten in de systeemontwikkeling.

Continue integratie en deployment (ci/cd) is de discipline om het werk van verschillende ontwikkelteams regelmatig te integreren en uit te rollen naar een test-, acceptatie- of productieomgeving. Dit is een geautomatiseerd proces waarbij we een build klaarzetten die de buildserver vervolgens oppakt en installeert. Aansluitend draaien er geautomatiseerde tests, bijvoorbeeld functionele regressietests.

De deployment pipeline is een gefaseerd traject: als tests op de ene omgeving zijn geslaagd, gaat de build automatisch naar de volgende omgeving voor aanvullende tests, bijvoorbeeld performance- of ketenintegratietests. Gaat er iets mis, dan wordt het proces stopgezet en zoekt development uit wat de oorzaak is. Omdat we bij ci/cd vaak uitrollen, zijn er slechts beperkte wijzigingen ten opzichte van de laatste succesvolle testrun. De oorzaak is dan in de regel snel gevonden.

We maken onderscheid tussen continue delivery en deployment. Het grootste verschil is dat we bij continue deployment oplossingen naar productie zetten, en bij continue delivery niet. Continue delivery levert een totaal getest en potentionally shippable product op, bijvoorbeeld op de acceptatieomgeving. De laatste stap, deployment naar productie, is dan een handmatige beslissing.

Ci/cd biedt vele voordelen voor organisaties die adaptief en wendbaar willen zijn. De geautomatiseerde deployment pipeline maakt het mogelijk tests hoogfrequent te herhalen, wat resulteert in een hogere kwaliteit en minder rework. De snelle feedback reduceert de risico’s en de automatisering sluit handmatige fouten uit. Efficiënt en voorspelbaar dus. Geen wonder dat veel organisaties de practice omarmen. Het zorgt ervoor dat systeemwijzingen en -verbeteringen snel beschikbaar zijn voor organisatie en eindklant.

Foto_Buro_Brabant_collage
Buro Brabant

Samenwerking

De ervaring leert dat veel organisaties wel streven naar ci/cd, maar dat dit vaak een flink aantal uitdagingen met zich meebrengt. Om de uitdagingen in kaart te brengen en bespreekbaar te maken, heb ik acht randvoorwaarden geformuleerd (Figuur 1). Deze heb ik afgelopen oktober voorgelegd aan workshopdeelnemers op de en het Testnet-congres, met de stelling dat ze allemaal moeten zijn ingevuld voor een succesvolle ci/cd-implementatie. Mijn doel was om bewustzijn te creëren en de mensen kennis te laten delen, zodat ze de discussie in hun eigen organisatie kunnen voortzetten.

Een belangrijke randvoorwaarde is dat teams moeten samenwerken en hetzelfde doel moeten hebben – mits ze aan dezelfde producten (of systemen) werken; anders heeft het weinig voordeel om het werk te integreren en gezamenlijk naar productie te brengen. Bij samenwerken hoort het afstemmen van teamoverstijgende afhankelijkheden, het hebben van een effectief portfolio-overleg en het hanteren van dezelfde kwaliteitscriteria en codingstandaarden. Het helpt enorm als teams samenwerken aan hetzelfde minimal viable product, zodat er geen discussie is over de prioriteitstelling. Tijdens de workshops blijkt dat onderling vertrouwen en weten waar de andere teams aan werken uitdagingen blijven.

Uit de discussies komt ook naar voren dat we goed moeten nadenken over hoe vaak we nieuwe productieversies vrijgeven. Bij een webapplicatie levert een hoge frequentie weinig problemen op; toch heeft de gemiddelde eindgebruiker geen behoefte aan update na update. Dit geldt in sterkere mate bij embedded systemen. De gemiddelde bestuurder van een auto zal minder problemen hebben met de installatie van nieuwe kaarten tijdens het rijden dan met een update van zijn remsysteem.

Een goede architectuur maakt het mogelijk voor organisaties om een differentiatie aan te brengen. Door op dat niveau onderscheid te maken tussen systeemonderdelen die we regelmatig en minder vaak deployen, kunnen we de risico’s beperken. Het doel is om subsystemen te kunnen releasen met een minimaal risico voor het gehele systeem. Tijdens de workshops geven de deelnemers aan dat dit niet alleen goed configuratiemanagement vergt, maar ook commitment in de organisatie om voor een goede architectuur te kiezen en deze op de lange termijn te handhaven.

De_Grood_Figuur_1
Figuur 1: De randvoorwaarden voor een succesvolle ci/cd-implementatie

Testautomatisering

Continue integratie vereist dat we ingecheckte code meteen testen om te kijken of het systeem als geheel nog steeds werkt. Testautomatisering is een randvoorwaarde voor agile teams om in de sprint de noodzakelijke tests te draaien en om hoogfrequent regressie te kunnen uitvoeren. Hierbij gaan we ervan uit dat de tests automatisch starten vanuit de buildserver.

De workshops tonen een grote spreiding in de volwassenheid van de testautomatisering (Figuur 2). Enerzijds geven deelnemers aan tools zoals Jenkins te hebben ingericht, de tests automatisch te starten en hun resultaten te verzamelen in een dashboard. Anderzijds vormen legacy systemen een uitdaging. Deze zijn minder geschikt om te automatiseren, de bestaande tests zijn moeilijk te interpreteren, kostbaar om te onderhouden en testruns duren vaak te lang.

Daarnaast geven sommige deelnemers aan dat testen geen favoriete bezigheid is in hun organisatie. Ontwikkelaars vinden het eigenlijk niet leuk om tests te definiëren en als het project onder druk komt te staan, verschuift testautomatisering vaak naar de achtergrond. Hier is nog wat missiewerk te verrichten voor ingebouwde kwaliteit.

Een aantal organisaties heeft het hands-off deployment-proces technisch wel op orde. Deelnemers geven aan dat ze automatisch packages creëren, dat ze smoketests en automatische regressietests starten nadat de nieuwe software automatisch is geïnstalleerd, bijvoorbeeld op een virtuele omgeving, en dat ze nightly builds ondersteunen. Uitdagingen vinden ze in de snelheid van de deployment, het voldoen aan regelgeving, de architectuur en de combinatie tussen software- en hardwarecomponenten. Ook zijn enkele organisaties nog zoekende hoe ze de klantacceptatie kunnen integreren in dit verder technische proces.

Opvallend is dat veel deelnemers aangeven dat de acceptatiecriteria onvoldoende helder zijn. Het is een uitdaging om deze ‘smart’ te krijgen en de stakeholders goed in kaart te hebben. Acceptatie in ci/cd-context wordt bemoeilijkt als het systeem componenten bevat van externe leveranciers die niet agile werken en dus niet meelopen in hetzelfde ritme.

De_Grood_Figuur_2
Figuur 2: Workshopresultaten tonen een flinke spreiding in de mate waarin de verschillende randvoorwaarden bij de verschillende organisaties zijn ingevuld. Er zijn organisaties waar bijvoorbeeld de testautomatisering, het hands-off deployment-proces en de feedbackloop op orde zijn, maar gemiddeld scoren veel deelnemers hun organisatie beduidend lager.

Meer dan een technisch kunstje

De daadwerkelijke vrijgave zorgt ervoor dat de organisatie voordeel of omzet haalt uit het nieuwe/verbeterde product. Tegelijkertijd levert het belangrijke klantfeedback op over de werking en waardering van het product. Tijdens de workshops geven enkele deelnemers aan dat ze nieuwe features beschikbaar stellen voor een selecte groep klanten (A/B-testing), zonder ze commercieel te lanceren. Vrijgave is een uitdaging in streng gereguleerde omgevingen of omgevingen waar de systeembeschikbaarheid belangrijk is. Hoe upgrade je een systeem als frequente downtijd onacceptabel is?

Klantfeedback kunnen we gebruiken om het ontwerp, de roadmap en de tests aan te scherpen en de kwaliteit van het product verder te verbeteren. De acceptatie komt ook hier als een issue naar boven. Teams hebben niet altijd contact met de eindklant en soms is de feedback tegenstrijdig met het doel van het ontwikkelprogramma.

Ci/cd blijkt meer te zijn dan een technisch kunstje. De organisatie moet goed portfoliomanagement hebben ingericht om de roadmap te kunnen definiëren en werkzaamheden te prioriteren. Goede governance, inzicht in waar de teams mee bezig zijn, is hiervoor noodzakelijk. Maar juist dat is een uitdaging voor veel organisaties.

Om effectief te kunnen werken, is het ten slotte belangrijk dat alle skills in het team aanwezig zijn. Tijdens de workshops hebben we het over de muur tussen beheer en ontwikkeling en over het belang om zowel ontwikkel- als testskills te hebben. Deelnemers zijn het erover eens dat de juiste mindset en het juiste gedrag ook belangrijk zijn. Dit betekent dat medewerkers zich zullen moeten ontwikkelen.

De adoptie van ci/cd heeft organisatorische impact. Misschien moeten organisaties zich voorbereiden op een herziening van de teamsamenstelling en een herschikking van afdelingen. Dit om ervoor te zorgen dat de skills goed verdeeld zijn over zelfstandige teams die binnen een doordachte architectuur features zelfstandig live kunnen zetten en gericht klantfeedback kunnen verzamelen om de volgende increment nog waardevoller te laten zijn.

Edited by Nieke Roos