CI/CD-pipelines: van commit tot productie
Continuous Integration en Continuous Delivery/Deployment vormen de ruggengraat van moderne softwareteams. Dit zijn de fases en waarom snelle feedback zo belangrijk is.
CI/CD beschrijft een geautomatiseerde route die code aflegt vanaf het moment dat een ontwikkelaar iets commit, tot het moment dat het live draait. Het doel: fouten zo vroeg mogelijk ontdekken, en releases zo veilig en voorspelbaar mogelijk maken.
Continuous Integration (CI)
Bij elke commit draait automatisch een pipeline die de code bouwt en test. Het idee is dat kleine, frequente integraties van code veel makkelijker te controleren zijn dan grote, incidentele merges — conflicten en regressies worden vroeg gesignaleerd, niet pas na weken werk.
Continuous Delivery versus Continuous Deployment
Deze twee termen worden vaak door elkaar gebruikt, maar zijn niet hetzelfde:
- Continuous Delivery — elke wijziging die alle tests doorstaat, is klaar om naar productie te gaan, maar de daadwerkelijke release gebeurt nog met een menselijke goedkeuring.
- Continuous Deployment — gaat een stap verder: elke wijziging die de pipeline doorstaat, wordt automatisch naar productie uitgerold, zonder handmatige tussenstap.
De typische fases
- Build — code compileren of een container-image bouwen.
- Test — geautomatiseerde tests: unit-tests, integratietests, soms ook beveiligingsscans.
- Deploy — het resultaat uitrollen naar een omgeving (staging, productie).
Faalt een fase, dan stopt de pipeline direct — dit heet fail fast, en voorkomt dat een gebroken versie doorschuift naar productie.
Pipeline as code
Moderne CI/CD-tools laten je de pipeline zelf ook als code beschrijven (bijvoorbeeld in een YAML-bestand in dezelfde repository). Zo wordt ook de manier waarop je bouwt, test en deployt, versiebeheerd en reviewbaar.
Examentip: Twijfel je tussen "Continuous Delivery" en "Continuous Deployment" in een examenvraag: kijk of er een handmatige goedkeuringsstap wordt genoemd. Zo ja → Delivery. Zo nee, volledig automatisch → Deployment.