Door Anthony Alberto

Software is er om het leven van gebruikers en processen makkelijker en efficiënter te maken. Automatiseren in het algemeen, en specifiek methodes als DevOps, zijn er om dit waar te maken. CI/CD (= Continuous Integration/Continuous Delivery) is hier een belangrijk onderdeel van: het opleveren van (software-)waarde volgens een geautomatiseerd proces. Vanaf de aanpassing door de Developer in code, tot het in gebruik nemen op de productie-omgeving. Er is niet één manier om CI/CD in de praktijk te doen. De software wordt namelijk in een uitgebreid scala opgeleverd. Wat betekent dat? Het wordt gebruikt door bedrijven die – niet eens bij wijze van – alles nog handmatig doen, én door een Amazon die maar liefst 12 keer per seconde een aanpassing oplevert. Maar, waarom moeten we eigenlijk CI/CD in de praktijk uitvoeren?

“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”

– Donovan Brown.

Snel schakelen

Laten we beginnen met een voorbeeld. We hebben de afgelopen jaren kunnen zien dat – door de pandemie – grote veranderingen op alle vlakken moesten plaatsvinden. Als je van de één op de andere dag bepaalde zaken niet meer fysiek kunt uitvoeren en snel moet kunnen schakelen, is het belangrijk dat je platform is ingericht op de nodige flexibiliteit. Zodat aanpassingen snel en met behoud van kwaliteit uitgevoerd kunnen worden. Processen die daar dagen (of zelfs langer) de tijd voor nodig hebben, willen we heel snel vergeten. En daar is CI/CD voor in het leven geroepen. Om snel te kunnen schakelen wanneer dit nodig is én om op die manier – zoals Microsoft dat op de laatste conferenties blijft herhalen – Digital Resilience te hebben als organisatie.

Sidenote: Met omgeving(en) in deze context worden test, acceptatie en productie bedoeld.

Developers en Operations

Veel Enterprise bedrijven zijn historisch zó gegroeid dat Developers en Operations gescheiden werken. Dat geldt ook voor Security. Een Developer die bijvoorbeeld software schrijft voor een bank, hoeft geen rechten voor geldoverschrijvingen te hebben. Vóórdat CI/CD werd gebruikt, was die voorbeeldsituatie heel anders. Developers maken een aanpassing en bouwden de software en plaatsen deze vervolgens in een pakket waarin de administratie van versie- en configuratiebestanden wordt bijgehouden. Het Operations team pakt dit vervolgens op en plaatst de Software op de desbetreffende omgeving en dan – fingers crossed – hopen dat alles werkt, inclusief de aanpassing.

Het probleem van deze aanpak? Operations weet feitelijk niks over de werking van de software en wanneer er dus een fout optreed, kunnen zij ook weinig betekenen om dit op te lossen. Dit maakt hen dan weer afhankelijk van de Developers. Developers kunnen – andersom – niet zien wat er eventueel fout gaat in een omgeving, omdat zij hier niet de rechten toe hebben (want, je raadt het al, dit heeft alleen Operations). Het resultaat? Een foutje levert alleen maar hordes en vertraging op. En zelfs al gaat de oplevering van de Software in één keer goed, is het een kostbaar proces qua tijd en resources. We zien namelijk vaak minimaal één dag tussen het moment dat Developers de software in het administratieve pakket zetten en de oplevering zelf.

CI/CD in de praktijk

Om precies dié uitdagingen te tackelen, is Dev (Developers) Ops (Operations) in het leven geroepen, met daarin het onderdeel CI/CD. Om een recent praktijkvoorbeeld te geven, gaan we het hebben over een livegang met gebruik van Azure Devops. Met het automatisch builden, code kwaliteitscontrole, testen en deployen van software en de voordelen die dat opleverde. In deze case moesten voor een project vijf (!) verschillende software-onderdelen live worden gezet.

Volgens het niet-efficiënte proces dat we hierboven hebben besproken, zou dat dus een behoorlijke opgave zijn geweest. Er moet dan constant afstemming worden gezocht met Operations, om vervolgens in een bepaalde volgorde – dan wel draaiboek – te werken, en er is constant overleg nodig om dit zo goed mogelijk te laten verlopen. Developers én Operations moeten namelijk beide duidelijk hebben wat er uitgevoerd moet worden, omdat er steeds meer plekken komen waar fouten kunnen ontstaan. En in de praktijk weten we allemaal: waar iets fout kán gaan, gebeurt het vaak ook.

CI/CD Pipelines

De oplossing? We bouwden CI/CD Pipelines voor deze software. Developers builden zelf de Software, deden de kwaliteitscontrole van de code, testten en transformeerden van configuratie per omgeving en leverden naar meerdere omgevingen op. Inclusief productie. Natuurlijk heeft dit voor zowel Developers als Operations inspanningen opgeleverd, om de eerdergenoemde hordes weg te nemen. Want het verhaal blijft dat Developers nog steeds geen toegang hebben tot omgevingen die zij niet direct nodig hebben voor hun werkzaamheden.

De CI/CD-Pipeline is in deze case het proces dat rechten heeft om om de software-oplevering uit te voeren. Developers hebben volgens hun draaiboek de software opgeleverd. Letterlijk minutenwerk. Nu trad er bij één stuk software een fout op in de configuratie. Eerder zou dit eerst door Operations gemeld moeten worden aan Developers, waarna ze samen gaan zoeken naar het precieze probleem. Met als gevolg dat Developers de oplossing gingen bouwen om dit weer opnieuw aan te bieden aan Operations. De boodschap is duidelijk: zonder CI/CD is dit een erg omslachtig, foutgevoelig en tijdrovend proces.

CI/CD in de praktijk geeft ons Developers en Operations grote voordelen in processen rondom livegang. In de case die we hebben besproken, konden Developers door het uitvoeren van de transformatie in de Pipeline (in plaats van via Operations!), fouten zelf herstellen én oplossen. In een paar minuten tijd. Het mooiste voorbeeld van waarom dit het leven makkelijker maakt? De opmerking van een gebruiker die door de jaren heen veel livegangen, en de daarmee gepaarde problemen, heeft meegemaakt. Deze zat naast mij tijdens de livegang en zei letterlijk: “Dit hadden we nooit zó snel en zó goed op de oude manier kunnen doen”.

Conclusie

Dit was een praktijkvoorbeeld van de voordelen van CI/CD en DevOps. Ik wil wél benadrukken dat zowel CI/CD als DevOps veel groter zijn dan wat ik op papier heb kunnen zetten. Wat ik in ieder geval voor mezelf kan zeggen, is dat de implementatie van de CI/CD in de praktijk meer verantwoordelijkheid bij de Developers heeft gelegd. En laat dat precies zijn waar wij moderne Developers blij van worden. Onze expertise kunnen we op die manier zo efficiënt mogelijk inzetten om mooie en goede oplossingen te bouwen. Hiermee kunnen we beter doen waar het bouwen van software, automatiseren in het algemeen, DevOps en CI/CD uiteindelijk om draaien. Het leveren van waarde voor de gebruikers.

OVER DE AUTEUR:

Anthony is wat wij noemen een ‘developer zonder poe-ha’. Nuchter, realistisch, mét een flinke dosis humor. Met zijn ruim 15 jaar development ervaring heeft Anthony zijn sporen ruim verdiend en deelt hij zijn kennis graag met iedereen die het horen wil.