Continuous deployment: automatisch en veilig deployen.

Deployen mag niet spannend zijn

Bij veel bedrijven is deployen — het live zetten van een nieuwe versie van de software — een stressmoment. Iemand logt in op de server, kopieert bestanden, voert handmatig database-wijzigingen door, test snel of alles nog werkt en hoopt dat er niets kapot is. Liefst op vrijdagmiddag, als de meeste gebruikers offline zijn.

Dat is geen professioneel proces. Dat is hopen dat het goed gaat.

Continuous deployment draait dat om. Elke wijziging die door alle tests en checks heen komt, wordt automatisch naar productie gebracht. Zonder handmatige stappen, zonder stress, zonder vrijdagmiddagangst. Deployen wordt net zo gewoon als een commit pushen.

CI, CD en CD — de begrippen

De termen worden vaak door elkaar gebruikt, maar er zijn drie niveaus:

Continuous Integration (CI)

Elke keer dat een developer code pusht naar de repository, wordt die code automatisch getest. Unit tests, integration tests, code style checks, security scans — alles draait automatisch. Als er iets faalt, krijgt de developer direct feedback. Het doel: fouten vroeg ontdekken, niet pas bij de release.

Continuous Delivery (CD)

Een stap verder: na succesvolle tests wordt de code automatisch klaargemaakt voor deployment. De release is gebouwd, getest en gereed. Het enige wat nog nodig is, is een handmatige bevestiging: "ja, zet het live." Dat geeft controle zonder handwerk.

Continuous Deployment (CD)

De volledige automatisering: na succesvolle tests gaat de code automatisch naar productie. Geen handmatige stap meer. Dit vereist een hoog vertrouwen in je tests en je proces, maar het levert de snelste feedbackloop op.

In de praktijk werk ik met continuous delivery voor de meeste projecten — automatisch gebouwd en getest, met een bewuste klik om te deployen. Voor SaaS-producten met een volwassen teststrategie schakelen we soms over naar volledige continuous deployment.

Hoe een CI/CD pipeline eruitziet

Een typische pipeline voor een Laravel-project doorloopt deze stappen:

1. Code push

Een developer pusht code naar een branch in Git. Bij een feature branch triggert dit de CI-pipeline. Bij een merge naar de main branch triggert het de volledige CD-pipeline.

2. Automated tests

De teststrategie bepaalt wat er draait:

• Unit tests — Testen individuele functies en classes. Draaien in seconden.
• Feature tests — Testen complete features inclusief database en HTTP-requests. Draaien in minuten.
• Integration tests — Testen de samenwerking tussen componenten.
• Static analysis — PHPStan of Larastan controleert op type-fouten en mogelijke bugs zonder de code te draaien.
• Code style — Pint of PHP-CS-Fixer controleert of de code aan de stijlregels voldoet.

3. Build

Frontend assets worden gecompileerd (Vite), dependencies worden geïnstalleerd (Composer), en het deployment-artefact wordt gebouwd. Bij serverless deployment via Laravel Vapor wordt hier een Docker-image gebouwd.

4. Deploy

Het artefact wordt naar de doelomgeving gedeployed. Bij Vapor is dat een push naar AWS Lambda. Bij traditionele hosting is dat een release via Forge of Envoyer. Altijd met zero-downtime: de oude versie draait door tot de nieuwe volledig is opgestart.

5. Post-deploy checks

Na deployment draaien er automatische health checks. Reageert de applicatie? Draaien de queues? Is de database bereikbaar? Als er iets faalt, wordt automatisch teruggerold naar de vorige versie.

Wat dit oplevert

• Snellere releases — In plaats van wekelijks of maandelijks deployen, kun je meerdere keren per dag deployen. Kleine wijzigingen, snel live, snelle feedback.
• Minder risico — Kleine, frequente releases zijn veiliger dan grote releases met tientallen wijzigingen. Als er iets misgaat, weet je precies welke wijziging het heeft veroorzaakt.
• Geen handmatige fouten — Geen vergeten database-migratie, geen verkeerd gekopieerd bestand, geen "oeps, verkeerde server". Alles is geautomatiseerd en reproduceerbaar.
• Snellere feedbackloop — Bugfixes en verbeteringen zijn dezelfde dag live. Geen wachten op de volgende release window.
• Vertrouwen — Als je tests groen zijn en je pipeline werkt, weet je dat de code klaar is. Deployen is geen sprong in het diepe meer.

Deployen moet net zo saai zijn als het licht aandoen. Als het spannend is, is er iets mis met je proces.

Welke tools gebruik ik?

De specifieke tools hangen af van het project, maar dit is mijn standaard stack:

• GitHub Actions — CI/CD pipeline die draait bij elke push. Tests, builds en deployments gedefinieerd als code.
• Laravel Vapor — Serverless deployment naar AWS. Automatische zero-downtime deploys, rollbacks en environment management.
• Laravel Forge — Voor projecten op traditionele servers. Automatische deployments vanuit Git met zero-downtime.
• PHPStan / Larastan — Static analysis die bugs vindt voordat de code draait.
• Laravel Pint — Code style enforcement zodat alle code consistent is.

Veelgemaakte fouten

• CI/CD zonder tests — Een deployment pipeline zonder tests is als een veiligheidsriem zonder auto. Het ziet er goed uit, maar het beschermt je nergens tegen.
• Alles handmatig — "We deployen niet zo vaak, dus handmatig is prima." Tot er een kritieke bugfix nodig is en de enige persoon die kan deployen op vakantie is.
• Geen rollback-strategie — Wat als de deploy faalt? Als je geen automatische rollback hebt, sta je handmatig de boel te repareren terwijl je gebruikers wachten.
• Geen staging-omgeving — Rechtstreeks naar productie deployen zonder eerst te testen in een omgeving die productie nabootst. Lees het artikel over de OTAP-straat voor waarom je meerdere omgevingen nodig hebt.
• Te trage pipeline — Als je pipeline dertig minuten duurt, gaat niemand meerdere keren per dag deployen. Optimaliseer je tests en builds zodat de pipeline binnen vijf tot tien minuten klaar is.

Hoe ik het inricht

Bij elk project dat ik bouw, is CI/CD standaard onderdeel van de oplevering. Niet als nice-to-have, maar als basisvereiste. Concreet betekent dat:

• Een Git-repository met branch protection (code gaat alleen via pull requests naar main)
• Een CI-pipeline die bij elke push tests, static analysis en code style draait
• Een CD-pipeline die na merge naar main automatisch deployt naar staging
• Een gecontroleerde promotie van staging naar productie
• Automatische rollback bij falen
• Notificaties naar Slack of e-mail bij succesvolle of gefaalde deploys

Het kost een dag om op te zetten. Het bespaart jaren aan handwerk, stress en fouten.

Wil je dit voor jouw project?

Of je nu een nieuw project start of een bestaand project wilt professionaliseren — CI/CD is een investering die zichzelf direct terugverdient. Neem contact op als je wilt weten hoe het voor jouw situatie kan worden ingericht.