CI/CD uitgelegd

Heb je ooit een deployment uitgerold en pas twee uur later ontdekt dat er iets mis was? Dan snap je precies waarom CI/CD zo aantrekkelijk is. Maar rondom de term zelf gaan nogal wat misverstanden rond. Sommige developers denken dat het alleen voor grote teams is. Anderen geloven dat je er een heel platform voor nodig hebt. En weer anderen zien CI/CD als één ding, terwijl het eigenlijk drie verschillende concepten zijn. Tijd om dat recht te zetten.

Mythe 1: CI/CD is hetzelfde als continuous deployment

Dit is veruit het meest voorkomende misverstand. CI/CD wordt vaak als één geheel gezien. Maar de twee termen staan voor drie afzonderlijke praktijken die je ook los van elkaar kunt toepassen. Continuous integration draait om het regelmatig samenvoegen van code. Ontwikkelaars werken in kleine stukken en pushen die naar een gedeelde branch.

Dit is veruit het meest voorkomende misverstand. CI/CD wordt vaak als één geheel gezien. Maar de twee termen staan voor drie afzonderlijke praktijken die je ook los van elkaar kunt toepassen.

Continuous integration draait om het regelmatig samenvoegen van code. Ontwikkelaars werken in kleine stukken en pushen die naar een gedeelde branch. Bij elke push start automatisch testen: unit tests, integratietests, een build-check. Zo weet je snel of een wijziging iets breekt. Continue integratie is dus puur gericht op het snel signaleren van fouten in de codebasis.

Continuous delivery gaat een stap verder dan automatisch alles live zetten. Na een geslaagde build en testfase is de software klaar om naar productie te gaan, maar dat laatste zetje geef je zelf. Een mens keurt de deployment goed. Zo weet je zeker dat je applicatie altijd in een stabiele versie verkeert die je kunt uitrollen, zonder dat je dat ook meteen hoeft te doen.

Continuous deployment haalt die handmatige goedkeuring weg. Elke wijziging die door alle geautomatiseerde stappen komt, gaat automatisch naar de productie omgeving. Geen handmatig proces meer, geen wachtrij. Dat klinkt spannend, maar het werkt goed als je testcoverage op orde is.

De drie concepten vormen samen de CI/CD-pipeline, maar je kiest zelf hoe ver je gaat. Veel teams beginnen met continuous integration en voegen continuous delivery later toe. Continuous deployment is een volgende stap die niet voor iedereen nodig is.

Mythe 2: CI/CD is alleen iets voor grote teams

Zelfs een klein team van drie personen profiteert direct van een CI/CD Je hoort het vaak: "Wij zijn maar met z'n drieën, CI/CD is voor ons te zwaar." Dat klopt niet. Juist kleinere teams profiteren van een goede pipeline, omdat zij minder capaciteit hebben om handmatige taken steeds opnieuw te doen.

Je hoort het vaak: "Wij zijn maar met z'n drieën, CI/CD is voor ons te zwaar." Dat klopt niet. Juist kleinere teams profiteren van een goede pipeline, omdat zij minder capaciteit hebben om handmatige taken steeds opnieuw te doen.

Stel je voor: je werkt aan een Laravel-applicatie voor een Nederlandse klant. Elke keer dat je een aanpassing doorvoert, moet je handmatig testen, handmatig deployen en handmatig controleren of alles nog werkt in verschillende omgevingen. Dat kost tijd die je liever steekt in het bouwen van nieuwe functies.

Met een eenvoudige CI/CD-pipeline op basis van GitLab CI of GitHub Actions automatiseer je die stappen. Bij elke push naar de main-branch draait automatisch testen, wordt de applicatie gebuild en gaat die bij succes naar de testomgeving. Dat is geen rocket science en je hebt er geen dedicated DevOps-team voor nodig.

De drempel ligt lager dan je denkt. GitLab CI werkt met een enkel YAML-bestand in je repository. GitHub Actions gebruikt een vergelijkbare aanpak. Zelfs Jenkins, dat wat ouder aanvoelt, is met de juiste configuratie snel op te zetten. De expertise die je nodig hebt, is bescheiden als je klein begint.

# Voorbeeld: eenvoudige GitLab CI/CD-pipeline voor een PHP-applicatie
stages: - test - deploy # Voer unit tests uit bij elke push
run_tests: stage: test image: php:8.2 script: - composer install - php artisan test # Deploy naar de testomgeving na geslaagde tests
deploy_staging: stage: deploy script: - ssh [email protected] "cd /var/www/app && git pull && php artisan migrate" only: - main

Dit voorbeeld laat zien hoe weinig er nodig is om te starten. Twee stages, een paar regels script en je pipeline staat. Developers die hier voor het eerst mee werken, zijn vaak verrast hoe snel dit laten werken lukt.

Mythe 3: CI/CD vervangt je teststrategie

Je pipeline voert tests uit maar bedenkt ze niet zelf voor jou. Een pipeline automatiseert het uitvoeren van tests, maar hij verzint ze niet. Dat is een belangrijk onderscheid. Veel teams zetten CI/CD op en denken daarmee klaar te zijn, terwijl hun testcoverage eigenlijk te laag is.

Een pipeline automatiseert het uitvoeren van tests, maar hij verzint ze niet. Dat is een belangrijk onderscheid. Veel teams zetten CI/CD op en denken daarmee klaar te zijn, terwijl hun testcoverage eigenlijk te laag is.

Automatisch testen in een pipeline is zo sterk als de tests die erin zitten. Heb je alleen unit tests die de happy path controleren? Dan geeft je pipeline een groen vinkje terwijl er in de praktijk van alles mis kan gaan in verschillende omgevingen. Geautomatiseerde tests zijn een middel, geen doel op zich.

In the development process is het slim om testomgevingen te gebruiken die zo dicht mogelijk bij de productie omgeving liggen. Draai je in productie op een specifieke versie van MariaDB met een bepaalde PHP-configuratie? Zorg dan dat je testomgeving dat spiegelt. Anders vind je fouten pas als het te laat is.

Een goede CI/CD-pipeline dwingt je juist om na te denken over testing and deployment als een geheel. Welke tests moet er draaien voor een deployment doorgaat? Welke fouten zijn acceptabel en welke blokkeren de pipeline? Dat zijn vragen die je team samen moet beantwoorden. CI/CD maakt die gedeelde verantwoordelijkheid zichtbaar en concreet.

Mythe 4: CI/CD en DevOps zijn hetzelfde

CI/CD is een praktijk. DevOps is een cultuur. Die twee hangen samen, maar zijn niet uitwisselbaar. DevOps draait om de samenwerking tussen development and operations. Het idee is dat developers en operations-teams niet als aparte eilanden werken, maar als één geheel. Betere samenwerking, gedeelde verantwoordelijkheid voor de hele levenscyclus van software, van code tot productie.

CI/CD is een praktijk. DevOps is een cultuur. Die twee hangen samen, maar zijn niet uitwisselbaar.

DevOps draait om de samenwerking tussen development and operations. Het idee is dat developers en operations-teams niet als aparte eilanden werken, maar als één geheel. Betere samenwerking, gedeelde verantwoordelijkheid voor de hele levenscyclus van software, van code tot productie. Verschillende teams die elkaar samenwerken in plaats van over de muur gooien.

CI/CD is een van de tools en methodes die je gebruikt om die DevOps-cultuur in de praktijk te brengen. Een pipeline automatiseert de stappen die anders handmatig en foutgevoelig zijn. Dat increase efficiency en geeft developers sneller feedback over hun wijzigingen. Maar zonder de juiste cultuur en samenwerking wordt CI/CD al snel een technisch trucje dat niemand echt omarmt.

In de Nederlandse praktijk zie je dit vaak bij bedrijven die CI/CD invoeren zonder de and operations-kant mee te nemen. De pipeline staat, maar de samenwerking tussen teams is niet veranderd. Dan haal je maar een deel van the benefits op.

Mythe 5: CI/CD is te risicovol voor productie

Dit misverstand komt voort uit een terecht gevoel: je wil niet dat een slechte commit automatisch naar productie gaat. Maar het risico zit niet in CI/CD zelf. Het zit in onvoldoende geautomatiseerde stappen voor de deployment. Continuous deployment naar productie werkt veilig als je pipeline goed is ingericht.

Dit misverstand komt voort uit een terecht gevoel: je wil niet dat een slechte commit automatisch naar productie gaat. Maar het risico zit niet in CI/CD zelf. Het zit in onvoldoende geautomatiseerde stappen voor de deployment.

Continuous deployment naar productie werkt veilig als je pipeline goed is ingericht. Dat vraagt om geautomatiseerde tests die de kritieke paden afdekken, een rollback-mechanisme als er iets misgaat, en monitoring die je direct waarschuwt zodra de applicatie zich anders gedraagt na een deployment. Met die drie elementen is continuous deployment op grote schaal betrouwbaarder dan een handmatig proces waarbij iemand op vrijdagmiddag een deployment doorvoert.

Continuous delivery is een goed tussenstation als je nog niet klaar bent voor volledige automatisering. Je bouwt het vertrouwen op door steeds meer stappen te automatiseren. Tegelijk je de uiteindelijke goedkeuring voor productie nog in eigen hand houdt. Zo groei je naar een hoge mate van automatisering zonder grote risico's te nemen.

Security is hierbij ook een punt. Een CI/CD-pipeline kan security-checks bevatten: dependency scanning, SAST-tools, controle op bekende kwetsbaarheden in je applicatie. Zo wordt security een geautomatiseerd onderdeel van elke deployment in plaats van een losse stap die je er achteraf bij doet. Dat is juist veiliger dan een handmatig proces.

# Security-scan toevoegen aan een GitHub Actions-pipeline
name: CI/CD Pipeline
on: push: branches: - main
jobs: security_scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 # Controleer dependencies op bekende kwetsbaarheden - name: Run dependency audit run: composer audit deploy: needs: security_scan runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 # Deploy naar productie-omgeving na geslaagde security-scan - name: Deploy to production run:./deploy.sh

Mythe 6: CI/CD werkt alleen met cloud-platforms

Veel artikelen over CI/CD gaan impliciet uit van een cloud-omgeving. AWS, Google Cloud, Azure. Maar CI/CD werkt net zo goed op een VPS of dedicated server. En voor veel Nederlandse developers en bedrijven is dat ook de meest logische keuze. Een pipeline die deployt naar een server in Nederland via SSH is volkomen valide.

Veel artikelen over CI/CD gaan impliciet uit van een cloud-omgeving. AWS, Google Cloud, Azure. Maar CI/CD werkt net zo goed op een VPS of dedicated server. En voor veel Nederlandse developers en bedrijven is dat ook de meest logische keuze.

Een pipeline die deployt naar een server in Nederland via SSH is volkomen valide. Je hebt controle over waar je data staat, wat relevant is voor de AVG. Je betaalt niet per deployment of per minuut build-tijd. En je bent niet afhankelijk van de beschikbaarheid van een extern platform.

De tools die je gebruikt, GitLab CI, GitHub Actions, Jenkins of Gitea CI/CD, werken allemaal met een eenvoudige SSH-verbinding naar je server. Je configureert een deploy-sleutel, schrijft een script dat de nieuwste code ophaalt en je applicatie herstart. En de pipeline doet de rest. Dat is in de praktijk voor veel projecten meer dan genoeg.

Softwareontwikkeling op grote schaal vraagt soms om meer: Kubernetes-clusters, container registries, blue-green deployments. Maar voor een webapplicatie of een WordPress-omgeving is een eenvoudige pipeline naar een goede VPS de meest directe en kosteneffectieve aanpak. Meer complexiteit voeg je toe als je die echt nodig hebt, niet omdat het er indrukwekkend uitziet.

Met een goede CI/CD-pipeline automatiseer je het testen en uitrollen van code, zodat je minder tijd kwijt bent aan handmatige stappen en fouten eerder worden gevangen. Zorg dat je pipeline ook rollback-scenario's afdekt, want een snelle deploy is pas echt waardevol als je net zo snel kunt terugdraaien bij problemen.

Wat je hier wel van moet onthouden

CI/CD is geen alles-of-niets-keuze. Continue levering en continue implementatie zijn stappen op een pad, geen verplichte eindbestemming. Begin met continuous integration: automatisch testen bij elke push. Dat levert al direct waarde op, ook als je team klein is en je pipeline nog eenvoudig is.

CI/CD is geen alles-of-niets-keuze. Continue levering en continue implementatie zijn stappen op een pad, geen verplichte eindbestemming. Begin met continuous integration: automatisch testen bij elke push. Dat levert al direct waarde op, ook als je team klein is en je pipeline nog eenvoudig is.

Continuous delivery voeg je toe als je testcoverage goed genoeg is om te vertrouwen op de pipeline. Continuous deployment is de volgende stap, als je ook de monitoring en rollback-mechanismen op orde hebt. Zo bouw je stap voor stap aan een werkwijze die past bij jouw situatie.

De kern van CI/CD is niet de tooling. Het is de discipline om kleine wijzigingen frequent te integreren, automatisch te testen en snel feedback te krijgen. Die discipline maakt software beter en deployments voorspelbaarder. De tools helpen je daarbij, maar de aanpak bepaal jij.

Wil je meer lezen over de onderliggende principes? De uitleg van Martin Fowler over continuous integration is een goed startpunt. Voor de officiële documentatie van GitLab CI kun je terecht op de GitLab CI/CD-documentatiepagina.

CI/CD en hosting bij Hostingway

Een goede CI/CD-pipeline is zo sterk als de omgeving waarop je deployt. Als je pipeline razendsnel builds uitvoert maar je server traag reageert, verlies je de winst die je hebt gemaakt. Wij zien dat in de praktijk regelmatig: de pipeline staat goed, maar de hostingomgeving is niet ingericht op snelle deployments.

Een goede CI/CD-pipeline is zo sterk als de omgeving waarop je deployt. Als je pipeline razendsnel builds uitvoert maar je server traag reageert, verlies je de winst die je hebt gemaakt. Wij zien dat in de praktijk regelmatig: de pipeline staat goed, maar de hostingomgeving is niet ingericht op snelle deployments.

Bij Hostingway werken we met NVMe-opslag, wat betekent dat bestanden snel worden geschreven en gelezen tijdens een deployment. Dat maakt een merkbaar verschil als je applicatie bij elke deployment assets compileert, caches leegt of migraties uitvoert. LiteSpeed zorgt voor snelle verwerking van requests, ook direct na een deployment als de cache nog opgebouwd wordt.

Onze senior engineers in Nederland kennen de praktijk van CI/CD-pipelines die deployen naar een VPS of Managed VPS. Als er iets misgaat in de configuratie, denken wij mee. Geen ticketsysteem dat je doorverwijst naar een FAQ, maar mensen met technische expertise die je direct verder helpen. Dat is wat je verwacht van een hostingpartner die al actief is sinds 2001.

Voor developers die werken met GitLab CI, GitHub Actions of Jenkins en deployen naar een server in Nederland: onze VPS-omgevingen zijn daar direct op in te richten. Je stelt een deploy-sleutel in, configureert je pipeline en de rest gaat automatisch. Wij zorgen dat de omgeving stabiel en snel is, jij zorgt voor de code.

Wil je dieper de techniek in? Bekijk de officiële Kubernetes-documentatie voor de actuele, technische details.

CI/CD vs. Handmatige Deployment

Veelgestelde vragen over CI/CD

Wat betekent CI/CD?

Kort gezegd: ci cd hangt direct samen met ci/cd. Wij leggen de samenhang in deze gids stap voor stap uit, zodat je de juiste keuzes maakt voor je omgeving.

Wat betekent ci&cd?

Kort gezegd: ci&cd hangt direct samen met ci/cd. Wij leggen de samenhang in deze gids stap voor stap uit, zodat je de juiste keuzes maakt voor je omgeving.

Wat betekent GitLab CI?

Kort gezegd: GitLab ci hangt direct samen met ci/cd. Wij leggen de samenhang in deze gids stap voor stap uit, zodat je de juiste keuzes maakt voor je omgeving.

Kun je CI/CD bij Hostingway draaien?

Onze managed hosting draait op snelle NVMe-opslag en LiteSpeed in een eigen netwerk in Nederland. Neem contact met ons op, dan kijken onze engineers samen met je welke opzet past bij ci/cd.

Is CI/CD geschikt voor kleinere organisaties?

Ja. Ook kleinere teams hebben baat bij ci/cd, mits de omgeving goed is ingericht. Wij adviseren je graag over een passende, beheersbare opzet.