Continuous Integration, Continuous Delivery en Continuous Deployment (CI/CD) uitgelegd
Continuous Integration, Continuous Delivery, Continuous Deployment CI/CD, DevOps, Cloud-native en Site Reliability Engineering. De developmentwereld zit bomvol jargon die op het eerste oog soms moeilijk te doorgronden is. In dit artikel leggen we uit wat CI/CD is, wat de verschillen zijn, wat een CI/CD pipeline is en welke populaire CI/CD tools er zijn.
Wat is CI/CD?
CI/CD is een methode voor het frequent leveren van applicaties naar (eind)klanten waarbij vrijwel alle stappen geautomatiseerd zijn. CI/CD wordt vaak gezien als een oplossing voor grote ontwikkelteams die de zogenoemde ‘integration hell’ willen voorkomen.
Zo’n integration hell ontstaat wanneer ontwikkelaars en systeembeheerders los van elkaar samenwerken aan de ontwikkeling en levering van een applicatie, zonder dat processen op elkaar zijn afgestemd.
De CI in CI/CD staat vrijwel altijd voor continuous integration, terwijl CD voor zowel continuous delivery als continuous deployment kan betekenen. Deze inhoud van deze twee termen worden ook wel eens door elkaar gebruikt, wat extra verwarrend kan werken.
Wat is het doel van CI/CD?
Het uiteindelijke (technische) doel van CI/CD is dat code sneller en foutlozer terecht komt in een stabiele en hoogpresterende productie-omgeving. Dit verhoogt de productiviteit van ontwikkelaars en geeft een organisatie een voorsprong op de concurrent.
Door de hoge mate van automatisering in de gehele levenscyclus van een applicatie wordt CI/CD een essentieel onderdeel van organisaties die op de DevOps-manier werken of een Site Reliability Engineering (SRE) aanpak hanteren. CI/CD wordt ook gebruikt in teams die ontwikkelen met cloud-native technologie zoals Docker containers of Kubernetes.
Wat is Continuous Integration (CI)
Continuous Integration stelt ontwikkelaars in staat om code te contribueren en om samen te werken via een gedeelde codebase op een hele snelle manier. Zonder continuous integration (CI) bestaat het samenwerken van ontwikkkelaars uit veel handmatige taken wanneer zij nieuwe code hebben geschreven zou het samenwerken tussen ontwikkelaars veel meer bestaan uit handmatige taken en coördinatie wanneer nieuwe code wordt geüpdatet of samengevoegd.
Continuous integration is gebaseerd uit een aantal best-practices uit de softwaredevelopmentwereld. Denk aan automatische tests, versiebeheer, build automation en automated deployments. Voor elke disciplines bestaan er tools, al zijn er ook CI-tools die veel van deze functies samenvoegen. Meer over populaire CI-tools lees je bij populaire CI/CD tools.
Continuous Delivery (CD) vs. Continuous Deployment (CD)
De CD in CI/CD refereert naar continuous delivery of continuous deployment. De twee termen worden vaak door elkaar gebruikt, maar er zijn dus verschillend.
In beide gevallen zijn ze ervoor verantwoordelijk voor een verdere levering van de code in de CI/CD pipeline.
Wat is Continuous Delivery (CD)?
Continuous Delivery betekent meestal dat een ontwikkelaar aanpassingen heeft gemaakt aan een applicatie, en dat deze aanpassingen ook getest zijn op bugs en geüpload zijn via een code repository (zoals Gitlab of Github). Vanuit deze plek staat de code klaar om in een productie-omgeving te komen, maar het daadwerkelijk implementeren van de code is vaak nog een handmatige handeling door een systeemexpert.
Bij Continuous Delivery is het doel om vooral snel en zo foutloos mogelijke code te leveren die klaar is voor de productie-omgeving.
Wat is Continuous Deployment (CD)?
Bij Continuous Deployment komt er geen systeemexpert meer kijken, omdat de code automatisch in de productie-omgeving wordt geïmplementeerd zodra de ontwikkelaar de code ‘releaset’. Wel worden er eerst automatische tests en controles uitgevoerd om er zeker van te zijn dat er niets stuk gaat bij deployment.
Het voordeel van Continuous Deployment is dat de code rechtstreeks naar het eindproduct gaat (de software), waardoor ontwikkelaars er een enorme snelheidswinst mee kunnen behalen. De organisatie is hierdoor in staat om sneller software te leveren dan bijvoorbeeld een concurrent.
Wat is het verschil tussen CI en CD?
De verschillen tussen Continuous Integration, Continuous Delivery en Continuous Deployment zijn het best samen te vatten in onderstaande afbeelding:
CI/CD is vaak een lineair proces. Vandaar dat men vaak spreekt van een CI/CD pipeline. De code van de ontwikkelaar moet eerst door alle geautomatiseerde integratietests, om vervolgens door alle delivery-tests te gaan en als laatst door de deploymenttests.
Hoe werkt CI/CD?
Bij de ontwikkelingen van moderne applicaties zijn vaak meerdere ontwikkelaars tegelijkertijd bezig met de ontwikkeling van een applicatie. Eens in de zoveel tijd moet de code toegevoegd worden aan de productie-omgeving (dit wordt ook wel ‘mergen’) genoemd. Dit kan een vrij omslachtig en handmatig proces zijn omdat er bij elke wijzigingen problemen kunnen ontstaan.
Bijvoorbeeld als ontwikkelaars werken in een eigen lokale IDE in plaats van de IDE die binnen het team is afgesproken. Ook kunnen er problemen ontstaan op het gebied van versiebeheer.
Door CI toe te passen hoeven er geen speciale ‘merge days’ meer te zijn, omdat het committen van code frequent of dus continu kan gebeuren. Alle wijzigingen die de ontwikkelaar heeft doorgevoerd worden door automatisch gecheckt om er zeker van te zijn dat de nieuwe code de applicatie niet stukmaakt. Als er een fout wordt ontdekt dan is het vaak eenvoudiger om op te lossen, omdat CI-software goed aantoont waar de fout zit. Hierdoor zijn zelfs kleine stukken code toe te voegen. Teams kunnen dus ook sneller microservices ontwikkelen.
Bij Continuous Delivery wordt de geleverde code in de repository nogmaals gecheckt en op aanvullende zaken gecheckt voor de productie-omgeving. Denk aan de impact van de nieuwe code op het vlak van prestaties en stabiliteit in de productie-omgeving. Net als bij CI worden er diverse tests uitgevoerd en wordt er bij fouten automatisch aangetoond waar deze zitten.
Continuous Deployment is de laatste volwassenheidsfase van CI/CD. Omdat de code zonder menselijke tussenkomst direct naar de productie-omgeving gaat, is het belangrijk dat de automatische tests supergoed ontworpen zijn. In theorie kan een ontwikkelaar binnen minuten de wijzigingen zien in de productie-omgeving. In de praktijk is dit nog vrij zeldzaam. Bij grote bedrijven zoals Google gebeurt het misschien, maar die hebben vaak ook de mankracht en expertise op dit op grote schaal te verwezenlijken.
Populaire CI/CD tools
Er zijn diverse populaire tools voor ontwikkelteams die met CI/CD willen starten. Sommige van die tools richten zich alleen op CI, andere weer alleen op CD (zowel delivery als deployment). We pikken er een paar uit.
Jenkins
Jenkins is een populair op Java-gebaseerde opensource continuous integration (CI) server waarmee snel en automatisch code toegevoegd kan worden aan software zoals webapplicaties. Het is voor velen de de facto standaard voor CI. Een alternatief op Jenkins is CircleCI.
Gitlab CI/CD
Gitlab ken je misschien als code repository, maar binnen Gitlab zit ook een ingebouwde tool voor CI/CD. De tool is vrij uitgebreid. Gelukkig is de documentatie net zo uitgebreid.
Kubernetes
Hoewel het populaire containerorkestratieplatform Kubernetes geen CI/CD tool is, integreert het wel bijzonder goed met veel CI/CD workflows. Veel cloud-native ontwikkelteams die te maken hebben met grote hoeveelheden workloads gebruiken daarom Kubernetes.
Azure Pipelines
Een relatief nieuwe speler is Azure Pipelines. Deze software is onderdeel van de Azure DevOps stack en is in staat om zowel CI als CD onderdelen te automatiseren. Vooral geschikt voor ontwikkelaars die cloud-native applicaties naar Azure willen brengen.
Complex spel
In de praktijk blijkt dat CI/CD vaak een bijzonder complex spel is. De automatische tests moeten namelijk altijd geschreven worden door een of meerdere personen. Het kost veel tijd om na te denken over hoe je iets zo eenvoudig mogelijk kunt automatiseren met zo min mogelijk foutmarges.
Snelheid is vaak een wens vanuit het bedrijf en de ontwikkelaars, maar bij het schrijven van de test moet ook rekening gehouden worden met security en de stabiliteit van een productie-omgeving. Om die reden is het verstandig om de levering van applicaties een gedeelde verantwoordelijkheid te maken tussen ontwikkelaars en systeemexperts.
Beide IT-disciplines kijken met een eigen bril naar de gehele CI/CD-pipelines. Door samen een DevOps of SRE-werkwijze te hanteren bundel je elkaars krachten en kan de organisatie serieuze stappen zetten.
Over de auteur: Kilian Drewel werkt als content marketeer bij True.
Plaats een reactie
Uw e-mailadres wordt niet op de site getoond