Hoe zet je een goede CI/CD-pipeline op?

Een CI/CD-pipeline is een van die dingen die je pas echt mist als hij er niet is. Zodra je hem eenmaal hebt draaien, vraag je je af hoe je ooit zonder werkte. Maar een slechte pipeline is erger dan geen: trage builds, valse alarmen en een team dat de checks begint te negeren omdat ze toch niets betekenen.

Dit is een praktische gids voor het opzetten van een pipeline die daadwerkelijk werkt, gebaseerd op wat werkt in Laravel- en Vue.js-projecten bij Fantomu.dev.

Wat CI/CD eigenlijk betekent

Continuous Integration (CI) betekent dat elke push naar de repository automatisch een reeks checks uitvoert: tests, linting, typechecks, en eventueel een proefbuild. Het doel is om problemen te ontdekken voordat ze in de hoofdbranch terechtkomen.

Continuous Deployment (CD) gaat een stap verder: geslaagde builds worden automatisch naar een omgeving gedistribueerd. Dat kan een stagingomgeving zijn bij elke merge naar de ontwikkelbranch, of productie bij elke merge naar main.

Beide zijn waardevol. Je hoeft niet meteen te beginnen met volledige automatische deployment naar productie. Begin met CI, en voeg CD toe wanneer je vertrouwen hebt in je testdekking.

De basisonderdelen van een goede pipeline

1. Snelheid boven volledigheid

Een pipeline die tien minuten duurt, wordt omzeild. Ontwikkelaars pushen, wachten niet op de uitkomst, en beginnen aan iets anders. Streef naar een pipeline die in onder de drie minuten klaar is voor de meeste pushes. Langzame stappen, zoals end-to-end-tests of volledige integratietests, horen thuis in een aparte pipeline die alleen op specifieke branches of pull requests draait.

2. Linting en statische analyse als eerste stap

Linting mislukt snel en geeft onmiddellijk bruikbare feedback. Maak het de eerste stap in de pipeline, zodat je niet tien minuten wacht op tests om er achter te komen dat er een onjuist opgemaakt bestand is.

Voor Laravel: gebruik PHP CS Fixer of Pint. Voor Vue.js en TypeScript: ESLint met strikte regels. Beide kunnen lokaal worden uitgevoerd, wat betekent dat developers problemen kunnen oplossen voor ze pushen.

3. Tests in laagjes opdelen

Niet alle tests hoeven bij elke push te draaien. Een goede structuur:

• Bij elke push: unit tests en feature tests die geen externe services vereisen
• Bij pull requests naar main: volledige testsuite inclusief integratietests
• Nachtelijk of handmatig: end-to-end tests met Playwright of Dusk

Dit houdt de feedback-loop kort voor dagelijks werk, terwijl de volledige suite alsnog draait voordat code naar productie gaat.

4. Omgevingsvariabelen en secrets

Sla nooit secrets op in je repository, ook niet in versleutelde vorm als je dat kunt vermijden. Gebruik de secrets-functionaliteit van je CI-platform (GitHub Actions, GitLab CI, of Bitbucket Pipelines) en injecteer ze als omgevingsvariabelen tijdens de build. Maak een aparte testdatabase en testconfiguratie aan voor de CI-omgeving, nooit een verbinding naar productie.

5. Artefacten cachen

Composer-dependencies en npm-packages worden bij elke build opnieuw geïnstalleerd als je dit niet configureert. Gebruik cache-stappen op basis van de lockfile (composer.lock of package-lock.json) om dit te vermijden. Dit kan een pipeline van vier minuten terugbrengen naar minder dan een minuut.

Deployment: van staging naar productie

Voor de meeste projecten is een twee-omgevingen-model voldoende: staging en productie.

• Staging wordt automatisch bijgewerkt bij elke merge naar de ontwikkelbranch. Dit is de omgeving die je aan klanten laat zien voor akkoord.
• Productie wordt bijgewerkt bij elke merge naar main, of handmatig getriggerd via een goedkeuringsstap in de pipeline.

Voor Laravel-projecten op een VPS werkt een eenvoudige SSH-deploymentstap goed: pull de laatste wijzigingen, voer composer install uit, draai migraties en herstart de queue-workers. Tools als Deployer formaliseren dit patroon.

Voor containergebaseerde deployments (Docker, Kubernetes) bouw je een image als artefact in CI, sla je het op in een registry, en pull je het in de deploymentstap.

Veelgemaakte fouten

• Te veel in één job stoppen. Splits jobs op in parallelle stappen zodat linting en tests tegelijkertijd draaien.
• Foutmeldingen negeren. Als je team meldingen van de pipeline begint te negeren, zijn de meldingen niet goed ingericht. Maak ze betekenisvol of zet ze uit.
• Geen rollback-strategie. Automatische deployment naar productie vereist een plan voor als het misgaat. Een blauwe-groene deployment of een eenvoudige revert-stap in de pipeline is voldoende.
• Productie-credentials in de pipeline. Gebruik altijd aparte credentials per omgeving, met zo min mogelijk rechten.

Een eenvoudige GitHub Actions-workflow als startpunt

Voor een Laravel-project met MySQL ziet een basisworkflow er als volgt uit: een CI-job die Composer installeert, de testdatabase aanmaakt, migraties uitvoert en de testsuite draait, gevolgd door een deployment-job die alleen draait bij een push naar main en via SSH deployment uitvoert naar de productieserver.

Begin eenvoudig. Een pipeline die altijd groen is en snel draait, is meer waard dan een uitgebreide pipeline die niemand vertrouwt. Voeg stappen toe naarmate je vertrouwen in de automatisering groeit.