Are you ready for CI/CD? 

Ruben Smits - Stel je voor: een software development proces dat als een geoliede machine werkt, waarbij innovaties naadloos en zonder haperingen in de handen van gebruikers belanden. Dat is de belofte van Continuous Integration en Continuous Deployment (CI/CD).  

 Maar pas op, achter deze ogenschijnlijk eenvoudige afkorting schuilt een complexe reis vol valkuilen en uitdagingen. Laat me je meenemen door het doolhof van CI/CD en ontdek hoe het juiste kompas je organisatie kan leiden naar snelheid, kwaliteit en succes in een altijd veranderend landschap van softwareontwikkeling. 

Deze statements heb ik in mijn carrière al vaak gehoord. Kloppen ze ook echt? Helaas niet, in veel organisaties is CI/CD verworden tot een buzz-word en weten maar weinig medewerkers waarom ze CI/CD implementeren. CI/CD kan wel degelijk klantwaarde sneller naar productie brengen, het kan voor hogere kwaliteit van je product zorgen en bijvoorbeeld spoed-releases (die vaak chaos en paniek veroorzaken binnen een ontwikkelafdeling) geheel voorkomen. Het kan zeker, als CI/CD op de juiste manier wordt opgepakt binnen je organisatie en hier niet te licht over gedacht wordt. Richt je je als organisatie vooral op de aanschaf van een toolset om CI/CD te implementeren, dan is de kans groot dat je over een jaar een investering armer bent en de tools niet meer gebruikt worden. Richt je je organisatie niet in op CI/CD, dan haal je nooit je rendement. Kweek je niet de juiste mindset bij je medewerkers dan loopt de machine niet geolied. Is je product een grote monoliet, pak dat dan snel aan. Geen volwassen geautomatiseerde regressieset, vergeet het dan maar! Leer van het verleden om de juiste stappen te nemen naar een succesvolle toekomst met CI/CD. 

Test automatiseren 

Even een stapje terug. Zo’n 20 jaar geleden werd in vele organisaties geroepen dat alle testen geautomatiseerd moesten worden, want daarmee zou het allemaal veel sneller en beter worden. Ik werkte zelf in die tijd als tester aan een medisch software-project en hier werd Quicktest-Pro gezien als tovermiddel dat de test-uitdaging zou oplossen. 
Inmiddels weten we dat dat absolute onzin was. Nu weten we dat we vooraf een degelijke risicoanalyse uitvoeren en op basis daarvan de bekende situaties kunnen automatiseren. Kortom: Het resultaat van het automatiseren zal nooit beter zijn dan de risico’s die we vooraf inzien. We beseffen dus dat onze risicoanalyse niet perfect is, en om die gaps op te vangen voeren we op grote schaal exploratory testen uit. De kans is zeer groot dat zaken die in de risicoanalyse gemist zijn, op die manier alsnog aan het licht komen. 

Les 

Nu, 20 jaar verder, lijkt het alsof we niets geleerd hebben. In vele organisaties voeren we CI/CD in, puur vanwege het feit dat iedereen roept dat dat de heilige graal is. En nog sterker: Bij die invoering richten we ons vooral op de tool-chain. Net zoals er 20 jaar geleden tools als QuickTest Pro werden aangeschaft om het testproces te versnellen. Of een framework dat alle problemen met de agile werkwijze gaat oplossen… Hebben we dan niets geleerd van de test-automation hype? 

5 Perspectieven 

De eerste vraag die iedere organisatie zich zou moeten stellen is: “Waarom willen we CI/CD invoeren, wat willen we bereiken?” Zonder visie kom je niet verder. Zorg dat die visie ook alom bekend is in je organisatie, zodat iedereen aan hetzelfde doel werkt. 
We moeten beseffen dat de implementatie impact zal hebben op de gehele organisatie, inclusief een groot aantal bestaande processen. Ik gebruik vaak het CI/CD Maturity Model, waarbij je vanuit 5 perspectieven kijkt naar CI/CD en voor ieder perspectief een niveau kan bepalen voor een organisatie. Een groot voordeel van het gebruik van een dergelijk model is dat iedereen in je organisatie dezelfde taal gaat spreken. 

Cultuur en organisatie 

Als we willen versnellen via CI/CD, dan moet daar allereerst de cultuur van een organisatie bij passen. Om een voorbeeld te geven: De “CI” in dit begrip staat voor Continuous Integration. Als een ontwikkelaar aan zijn oude patronen vast houdt en de code die hij ontwikkelt pas commit op het moment dat de functionaliteit op zijn systeem ongeveer klaar is (vaak pas na meerdere weken), dan is dat verre van “continue”. We willen ieder moment van de dag weten of het totale product goed integreert, dus of alle losse componenten van het product probleemloos samenwerken en de juiste klantwaarde opleveren. Dit willen we continue doen, om direct actie te kunnen nemen als iets niet goed integreert. Zelfs als de wijziging nog niet klaar is, de enige voorwaarden is dat het de build en andere functionaliteit niet breekt. Regelmatig (minimaal dagelijks) je code committen zorgt voor transparantie. Die mindset moet dus veranderen.  
Daarnaast is het van belang dat er een platte overlegstructuur is tussen ontwikkelaars, testers en beheerders. Als een ontwikkelaar bijvoorbeeld iets bouwt dat een hele zware query gebruikt op een webserver, dan voelt zijn beheerder daar de pijn van als het in productie staat. We hebben dus echte multidisciplinaire DevOps teams nodig waarbij beheerders voor dergelijke inzichten kunnen zorgen bij ontwikkelaars. De organisatie kan zeker geraakt worden door de invoering van CI/CD. Vaak kom ik in de praktijk tegen dat organisaties wel de agile tools gebruiken en een aantal ceremonies uitvoeren, maar de echte agile mindset ontbreekt dan nog. Teams halen bijvoorbeeld weinig uit de retrospectives en verbeteren maar beperkt, vooral omdat de intrinsieke motivatie om te verbeteren (de mindset) ontbreekt. Vaak bereik je een betere agile mindset door te werken met goede voorbeelden. Heb je een team in je organisatie waar de zaken goed lopen, zet dat team dan vooral in de spotlight. Ook zou een bezoek aan een andere organisatie kunnen helpen om ideeën op te doen voor teams. 

Architectuur 

We kunnen ons product in een big-bang iedere dag naar productie brengen. Als iets niet blijkt te werken, moet het gehele product opnieuw gebouwd worden. Dat levert een logge monoliet op die voor verstopping zal zorgen in onze pipeline. Het bouwen van grote applicaties kan lang duren. Beter is om te werken in kleine, afgebakende modules die individueel getest en naar productie gebracht kunnen worden. Iedere module heeft daarbij een eigen, goed omschreven taak. Een services-landschap is een goed voorbeeld om je product op te zetten voor CI/CD. 
Ik heb bij een auto-fabrikant een grote transformatie meegemaakt. Hier kwam voorheen vrijwel alle software bij verschillende leveranciers vandaan en bestond er veel overlap tussen componenten. Na de transformatie is er veel overlap uitgehaald en is voor een meer modulaire opzet gekozen. Het aantal klachten van klanten is sterk afgenomen na die transformatie en het oplossen van bugs werd sterk vereenvoudigd door de modulaire opzet. 

Build en Deploy 

Hier kijken we naar de manier hoe we ons product bouwen, testen en uiteindelijk naar productie brengen. Dit is dus eigenlijk de pipeline met de tools die daar gebruikt worden. Vaak helpt het om hier een goede Value Stream Mapping (VSM) op te maken, om te zien waar de knelpunten zitten en hoe we de pipeline meer kunnen stroomlijnen. Ik heb in een organisatie gewerkt waar vele duizenden mensen aan hetzelfde product werkten. We hebben daar eerst op kleinere schaal delen van de pipelines geoptimaliseerd door middel van VSM’s, en later ook naar het grote plaatje gekeken met zo’n VSM. Mijn ervaring is dat een VSM net andere knelpunten inzichtelijk maakt dan je vooraf verwacht.  
En of je nu uiteindelijk product A of product B inzet bij de bouw van je pipeline interesseert mij minder. Vaak is deze keuze bepaald door grote contracten die organisaties al hebben voor hun inkoop van software tools, of het wordt historisch bepaald. Interessanter is het om de hele keten goed in een schema te zetten en bij iedere opstopping of ongeplande downtime in de pipeline een verbeter-actie door te voeren. 

Test en verificatie 

Nadat een product gebouwd is, moet het in dezelfde pipeline ook automatisch getest worden, zonder enige tussenkomst van een mens. Hier is een goed dekkende integratietest vanzelfsprekend belangrijk. Maar misschien nog wel belangrijker: Iedere test die uitgevoerd wordt, moet een eigenaar (agile team) hebben. Dat betekent dat wanneer een test faalt, de eigenaar direct gaat onderzoeken wat er mis is, en de juiste actie initieert. Omdat bij een integratietest soms niet snel de kern van het probleem achterhaald kan worden, moet deze eigenaar een mandaat krijgen om hulp van andere teams te vragen. De eigenaar is dus niet altijd degene die al het werk zelf oplost, soms kan ook gedelegeerd worden. Ik heb gewerkt in een organisatie waarbij ik grote kwaliteits- en snelheidsverbeteringen heb gezien nadat eigenaarschap van testen duidelijker werd, omdat direct duidelijk was wie er actie moest ondernemen bij falende testen en mensen dus niet afwachtend achteroverleunden.  

Naast een groot aantal snelle integratietesten kan je overwegen om ook een beperkt aantal E2E testen toe te voegen. Om snelheid te houden valt te overwegen om de langdurige testen in een aparte pipeline te plaatsen. En voor de duidelijkheid: Wanneer je een grote integratieset hebt opgebouwd, ga dan niet helemaal wild op allerlei dashboards met kleurtjes en grafieken. Iedere falende test heeft onderzoek nodig en kan worden uitgelegd met een verhaal, maar een dashboard geeft meestal geen goede status van je product weer en kan een vals beeld naar management geven. 
In het algemeen zal het eenvoudig zijn om een aantal testen van een eigenaar te voorzien, omdat die teams nu al dagelijks met dat onderwerp bezig zijn. Daarmee wordt het concept van eigenaarschap beter bekend in de organisatie en daarna zullen ook E2E testen, die vaak grote delen van het landschap bedekken en daarmee team overstijgend zijn, een eigenaar krijgen. 

Informatie en rapportage 

Als we daadwerkelijk CI/CD willen gaan doen, dan moeten we zeer snel in staat zijn om te antwoorden op vragen over afhankelijkheden en versies die in productie staan. Daarom is een grondig informatiemodel belangrijk om te hebben. Daarmee krijg je controle over interfaces en kan je de lifecycle van individuele componenten gaan beheren. Je kan op deze manier bijvoorbeeld bepaalde componenten uitfaseren, of zelfs meerdere versies in parallel in productie draaien, zolang het informatiemodel maar voldoende ondersteuning biedt. Dit betekent dat we veel meer proactief en voorspelbaar gaan worden, en ook toekomstbestendig.  
Om hier een voorbeeld bij te geven: Iedereen herinnert zich waarschijnlijk nog wel de security issue in Log4j. Wanneer er een goed informatiemodel bestaat, kan vrij eenvoudig worden opgezocht waar deze bibliotheek wordt gebruikt en daarmee wat de risico’s voor je product in het veld zijn. Dat maakt het dus eenvoudiger om je klanten te adviseren of heel snel een fix naar productie te brengen. 

Complete plaatje 

Ik verwacht dat we allemaal wel de voordelen kunnen bedenken van CI/CD, zoals een verkorte Time-To-Market, verhoogde kwaliteit en klantwaarde, en meer wendbaarheid voor je organisatie. Het lijkt mij een no-brainer dat iedere organisatie daar oren naar heeft.  

Al de perspectieven op CI/CD zoals hierboven vermeld hebben aandacht nodig als we daadwerkelijk onze software releases willen versnellen met hoge kwaliteit van het product. Bedenk dat de as waar we het slechtste scoren in het Continuous Delivery Maturity Model meteen de belemmerende factor is om verder te komen met CI/CD. Pas als we àl deze zaken onder controle hebben kunnen we zeggen dat we “ready” zijn om CI/CD te implementeren en gebruiken.  

Terwijl we de horizon van CI/CD verkennen, wordt één waarheid onmiskenbaar duidelijk: de drie pijlers van succes - 'people, process en technology' - zijn onafscheidelijk verbonden als de drijvende kracht achter elke stap. Als een goed geoliede machine werken ze samen om obstakels te overwinnen, innovatie te stimuleren en een vlotte reis naar CI/CD-verfijning te verzekeren. De juiste 'people' die de visie delen, de doordachte 'processes' die de weg banen en de geavanceerde 'technology' die de motor aandrijft - dit trio vormt de kern van jouw succesverhaal. Dus, met 'people, process en technology' in harmonie, sta je klaar om de revolutie van CI/CD vol vertrouwen en vastberadenheid tegemoet te treden. Jouw reis naar CI/CD-excellentie begint hier, met de kracht van samenwerking die het fundament vormt voor een glansrijke toekomst. 

Dus daar heb je het: de uitdagende reis van CI/CD onthuld, van de veelbelovende start tot de cruciale laatste stap. Net zoals een ervaren ontdekkingsreiziger die zijn koers bepaalt en obstakels overwint, kun jij jouw organisatie leiden naar de bestemming van naadloze softwareontwikkeling. Onthoud dat het doolhof complex kan zijn, maar met de juiste visie en toewijding kunnen snelheid, kwaliteit en succes binnen handbereik liggen. Dus, ben jij klaar om de sprong te wagen en de reis via CI/CD te beginnen? De koers is uitgezet, de keuze is aan jou!

 

---

Over de auteur: Ruben Smits

Ruben is al vele jaren werkzaam in de IT en heeft zich vooral gericht op aspecten als testen, CI/CD en software ontwikkeling. Hoewel Ruben is ingestroomd in een waterval-wereld is hij al vroeg in aanraking gekomen met agile werken. Ruben heeft in diverse organisaties gewerkt, waaronder domeinen met zeer hoge kwaliteitseisen zoals gezondheidszorg en automotive. Momenteel werkt Ruben bij QualityAccelerators, een bedrijf dat organisaties ondersteunt om hun software ontwikkeling te versnellen zonder concessies te doen aan de kwaliteit van hun producten. Ruben is zeer gepassioneerd over CI/CD vanwege de kracht die erin schuilt, en omdat het vereist dat vele werkgebieden waar Ruben ervaring mee heeft opgedaan goed samenwerken. Ruben ziet CI/CD als een grote militaire operatie, met vaak een geweldige uitkomst als het goed wordt aangepakt. 

Naar het overzicht