CI/CD pipeline: sneller en betrouwbaarder software opleveren

Een CI/CD pipeline automatiseert het traject van codeschrijven naar productie. Bij elke codewijziging draait de pipeline automatisch tests, bouwt de software en zet het live — zonder handmatige stappen. Teams die dit goed inrichten, releasen meerdere keren per dag in plaats van eens per maand. Zonder nachtdiensten. Zonder grote bangramomenten.

Maar een CI/CD pipeline is geen toverstaf. Een slecht geconfigureerde pipeline met halfbakken tests geeft een vals gevoel van veiligheid. Dit artikel legt uit hoe een goede pipeline werkt, welke tools je kunt kiezen, en waar het bij de meeste teams mis gaat.

Wat is CI/CD?

CI staat voor Continuous Integration. Het principe: iedere developer pusht meerdere keren per dag code naar een gedeelde branch. Bij elke push draait automatisch een reeks checks — bouwen, testen, analyseren. Als iets breekt, weet je het binnen minuten, niet weken later als er een grote batch code samenkomt.

CD staat voor Continuous Delivery of Continuous Deployment. Continuous Delivery: de software is na elke succesvolle build klaar om uitgerold te worden — maar een mens beslist wanneer. Continuous Deployment: die laatste stap naar productie is ook geautomatiseerd. Elke geslaagde build gaat live zonder menselijke tussenkomst.

Volgens het DORA-rapport (2024) presteren organisaties met volwassen CI/CD-praktijken 4× sneller in lead time for changes en hebben ze 3× lagere change failure rates dan teams die handmatig releasen. Het verschil is niet de tool — het is de discipline.

De pipeline stap voor stap.

Een volwassen CI/CD pipeline bestaat uit meerdere stages die elk één verantwoordelijkheid hebben. Hoe verder een probleem de pipeline doorloopt, hoe duurder het is om te herstellen. De meeste checks horen zo vroeg mogelijk.

1. Commit — developer pusht code naar de repository (GitHub, GitLab, Bitbucket). De pipeline start automatisch.
2. Build — de code wordt gecompileerd of gebundeld. Typisch de snelste stap: 1–3 minuten. Als de build breekt, stopt alles.
3. Unit tests — geïsoleerde tests die individuele functies en modules controleren. Moeten snel zijn: minder dan 5 minuten voor het hele project.
4. Statische analyse — code style checks, linting, typecontrole (TypeScript, mypy). Goedkoop om te draaien, duur om te negeren.
5. Security scans — SAST (Static Application Security Testing), dependency vulnerability checks (npm audit, Snyk, Dependabot). Geen excuus om dit over te slaan.
6. Integratietests — tests die meerdere componenten samen testen, inclusief database of externe services. Langzamer, maar noodzakelijk.
7. Build artifact — het resultaat wordt opgeslagen: een Docker image, JAR-bestand, npm-pakket. Dit artifact gaat naar alle volgende omgevingen — nooit opnieuw bouwen per omgeving.
8. Deploy naar staging — het artifact rolt automatisch uit naar een testomgeving die zo dicht mogelijk bij productie staat.
9. Acceptatietests / smoke tests — een minimale set checks om te bevestigen dat de applicatie draait in staging. Optioneel: handmatige goedkeuring hier.
10. Deploy naar productie — bij Continuous Deployment volledig automatisch, bij Continuous Delivery achter een handmatige trigger.

Een pipeline die tot en met staging loopt, kost typisch 10–20 minuten. Langer dan dat is een teken om parallelle stages te introduceren of zware tests naar een nacht-run te verplaatsen.

Tools vergeleken: GitHub Actions, GitLab CI en meer.

De toolkeuze hangt sterk af van waar je code staat en wat je infrastructuur doet. Hier een eerlijke vergelijking van de meest gebruikte opties:

De realiteit: voor de meeste Nederlandse bedrijven in de 50–500 medewerkers range is GitHub Actions de standaardkeuze. Werk je in een regulated environment met strenge eisen aan data-locatie of compliance, dan is GitLab CI/CD self-hosted het alternatief.

Best practices.

Een pipeline is nooit af. Deze principes zorgen dat hij betrouwbaar blijft naarmate je codebase groeit:

• Begin klein. Zet eerst alleen build en unit tests op. Voeg stap voor stap stages toe. Een eenvoudige pipeline die werkt, is beter dan een perfecte pipeline die niemand onderhoudt.
• Fail fast. De snelste en goedkoopste checks staan vooraan. Als een typo de build breekt, wil je dat na 2 minuten weten, niet na 25.
• Maak builds reproduceerbaar. Hetzelfde commit geeft altijd hetzelfde resultaat, ongeacht de datum of machine. Pin dependency-versies. Gebruik lock files.
• Bescherm de main branch. Niemand pusht direct naar main. Alles via pull requests, alles via de pipeline. Dit is geen bureaucratie — het is het fundament.
• Sla secrets nooit op in code. Gebruik environment variables of een secrets manager (GitHub Secrets, HashiCorp Vault, AWS Secrets Manager). Een gelegde secret in git-history is een blijvend beveiligingsrisico.
• Houd staging gelijkwaardig aan productie. Environments die fundamenteel anders zijn dan productie maken je pipeline nutteloos. Zelfde database-versie, zelfde configuratie, zelfde netwerkregels.
• Monitor de pipeline zelf. Als je pipeline vroeger 8 minuten duurde en nu 40, is dat een signaal. Meten hoort erbij — ook voor DevOps-infrastructuur.

Veelgemaakte fouten.

De meeste CI/CD-implementaties gaan niet mis door een verkeerde toolkeuze. Ze gaan mis door gedragspatronen die zich opstapelen:

• Flaky tests. Tests die soms slagen en soms niet trainen developers om failures te negeren. Één flaky test is een probleem. Tien zijn een cultuurprobleem. Fix ze — verwijder ze desnoods tijdelijk.
• Te weinig betekenisvolle tests. Een groene pipeline met 3 unit tests geeft een vals gevoel van veiligheid. De tests moeten de daadwerkelijke risico's van het systeem afdekken.
• Een trage pipeline als bottleneck. Als iedere commit 45 minuten wacht op de pipeline, vertraagt iedereen. Investeer vroeg in parallelle uitvoering en test-splitting.
• Geen rollback-procedure. Deployen is goedkoop als je rollback eenvoudig is. Wie dit niet van tevoren inregelt, heeft bij de eerste productie-fout een noodgeval.
• Vergeten dat staging niet productie is. Bugs die alleen in productie optreden zijn vaak configuratieverschillen. Pariteit tussen omgevingen is geen optioneel onderdeel.
• Handmatige stappen in een 'geautomatiseerde' pipeline. Eén handmatige goedkeuringsstap die iedere keer twee uur op iemand wacht, is geen CI/CD — het is een trage handmatige release met extra stappen.

Een goed team met een slechte pipeline releaset angstig en zelden. Een goed team mét een goede pipeline releaset meerdere keren per dag, ziet problemen direct, en herstelt snel. Dat verschil valt te maken — en het begint bij kleine stappen, niet bij een volledige tool-migratie.

Wil je weten waar jouw pipeline nu staat, of hulp bij het inrichten van een setup die bij jouw stack past? Vertel ons in een paar zinnen hoe jullie nu releasen. We reageren binnen één werkdag.