Wat is CI/CD? Continuous integration en delivery simpel uitgelegd

CI/CD is een manier van software uitleveren waarbij elke codewijziging automatisch wordt gebouwd, getest en — als ze slaagt — klaargemaakt voor release of uitgerold. CI (continuous integration) betekent dat wijzigingen vaak worden samengevoegd en elke keer door geautomatiseerde tests worden gecontroleerd. CD (continuous delivery of deployment) betekent dat de wijzigingen die slagen worden verpakt en met weinig of geen handmatig werk naar je gebruikers worden gebracht.

Het doel is simpel: fouten minuten nadat ze zijn gemaakt vangen, niet weken later wanneer een klant ze ontdekt.

Waarom CI/CD ertoe doet als je met AI bouwt

AI-bouwers maken codewijzigingen snel. Eén prompt kan tien bestanden raken. Die snelheid is prima totdat een wijziging aan de afrekenpagina stilletjes de inlogpagina breekt, en niemand het merkt tot een gebruiker je een e-mail stuurt.

CI/CD is precies het vangnet hiervoor. In plaats van te vertrouwen dat elke wijziging goed is, voert een pipeline elke keer dezelfde controles uit:

• Bouwt de app nog steeds zonder fouten?
• Slagen de geautomatiseerde tests nog?
• Volgt de code de regels van het project (types, opmaak, beveiligingscontroles)?

Als een controle faalt, wordt de wijziging tegengehouden voordat hij gebruikers bereikt. Hoe sneller je code verandert, hoe waardevoller een controle die nooit moe wordt of een stap overslaat.

Een alledaagse vergelijking

Denk aan een bakkerij die elke ochtend brood aan winkels levert.

• Zonder CI/CD werkt elke bakker een week lang aan zijn eigen receptaanpassingen, en vrijdagavond combineert iedereen alles en hoopt dat het brood nog rijst. Als dat niet gebeurt, weet niemand wiens wijziging het veroorzaakte.
• Met CI wordt elke kleine receptwijziging meteen in een proefbrood gebakken en gecontroleerd — smaak, gewicht, vorm. Een slechte wijziging wordt dezelfde dag gevangen, en je weet precies welke het was.
• Met CD gaan broden die de keuring halen direct op de bezorgwagen, op dezelfde manier verpakt en gelabeld, in plaats van dat iemand om 05.00 uur met de hand dozen inpakt.

De keuring maakt de bakkers niet beter. Ze maakt hun fouten goedkoop.

Hoe een CI/CD-pipeline werkt

Een pipeline is een lijst stappen die een CI/CD-dienst automatisch uitvoert wanneer er iets gebeurt — meestal wanneer iemand code naar een repository zoals GitHub pusht. Een typische pipeline ziet er zo uit:

Elke stap draait op een schone machine, niet op iemands laptop, dus ‘het werkt op mijn computer’ is geen excuus meer. Als een stap faalt, stopt de pipeline en laat hij de maker van de wijziging weten wat er mis is.

De stappen staan in een configuratiebestand dat bij de code hoort. In GitHub Actions is dat bijvoorbeeld een YAML-bestand in de map .github/workflows van de repository.

Continuous delivery vs continuous deployment

De ‘CD’ is dubbelzinnig, en mensen gebruiken het op beide manieren:

Continuous deployment werkt alleen goed als de tests goed zijn. Als je tests de afrekening niet dekken, zal continuous deployment vrolijk een kapotte afrekening uitrollen.

Een uitgewerkt voorbeeld: een boekingsapp met een pipeline

Stel dat je een boekingsapp voor een salon hebt, met de code in een GitHub-repository. Je vraagt een AI-bouwer om ‘een korting van 10% voor nieuwe klanten toe te voegen’.

1. De wijziging wordt naar een nieuwe branch gepusht en er wordt een pull request geopend.
2. De pipeline start. Hij installeert pakketten en bouwt de app — dit slaagt.
3. Hij draait de tests. Eén test, ‘een terugkerende klant betaalt de volle prijs’, faalt: de korting wordt op iedereen toegepast.
4. De pull request toont een rood kruis. De wijziging kan niet worden samengevoegd.
5. Je vraagt de AI het te repareren. Hij pusht een correctie; de pipeline draait opnieuw en alles slaagt.
6. De wijziging wordt samengevoegd. De pipeline rolt hem uit naar een stagingomgeving, waar je een testboeking maakt.
7. Je keurt goed, en hij gaat naar productie.

Zonder de pipeline was stap 3 gebeurd in de portemonnee van je klanten.

Belangrijke begrippen

Veelvoorkomende misverstanden

• ‘CI/CD betekent dat mijn app getest is.’ Een pipeline draait alleen de tests die je hebt. Zijn er geen tests, dan bewijst CI alleen dat de app bouwt — meer niet. Vraag je AI om tests te schrijven voor de stromen die het meest tellen.
• ‘CI/CD is alleen voor grote bedrijven.’ Gehoste tools zoals GitHub Actions hebben een kort configuratiebestand nodig om in te stellen, en kleine teams gebruiken ze de hele tijd. Het zijn de tests, niet de tools, die moeite kosten.
• ‘Automatisch uitrollen betekent dat niemand iets controleert.’ Goede pipelines voegen controles toe, ze halen ze niet weg. Veel teams houden een menselijke goedkeuringsstap vóór productie.
• ‘Als de pipeline groen is, werkt de app.’ Het betekent dat de geautomatiseerde controles slaagden. Probeer de wijziging zelf nog steeds, bij voorkeur in een preview of op staging.
• ‘CI/CD vervangt back-ups.’ Dat doet het niet. Een slechte databasemigratie die de tests doorstaat, kan nog steeds echte gegevens beschadigen. Houd back-ups en een manier om terug te draaien.

Wat je aan je AI-appbouwer kunt vragen

• ‘Schrijf geautomatiseerde tests voor aanmelden, inloggen en afrekenen, en laat me zien hoe ik ze draai.’
• ‘Stel een GitHub Actions-workflow in die bij elke pull request de afhankelijkheden installeert, de app bouwt en de tests draait.’
• ‘Voeg een typecontrole en een linter aan de pipeline toe, en laat hem falen bij fouten.’
• ‘Leg in gewone taal uit wat elke stap van de pipeline doet.’
• ‘Wat gebeurt er als een deploy halverwege mislukt? Hoe draai ik terug?’
• ‘Controleer dat er geen geheimen in de repository zijn vastgelegd of in de pipeline-logs worden afgedrukt.’

Als je app API-sleutels gebruikt, heeft de pipeline die ook nodig — opgeslagen als versleutelde geheimen in de CI-tool, nooit in het configuratiebestand. Zie omgevingsvariabelen en geheimen.

CI/CD en Mythex

Mythex draait geen CI-pipeline voor je, maar het dekt een aantal van dezelfde behoeften op zijn eigen manier:

• Checkpoints. Na elke geslaagde agentbeurt slaat Mythex een git-checkpoint op, en Terug naar dit punt zet het project terug als een wijziging misging. Zie Chat.
• App Testing. Typ /test en de agent klikt door je live preview zoals een gebruiker en meldt kapotte stromen — handig vóór elke publicatie. Zie App Testing.
• Publiceren is een bewuste stap. Wijzigingen verschijnen eerst in de privépreview; je publieke app wordt alleen bijgewerkt wanneer je opnieuw publiceert — dichter bij continuous delivery dan continuous deployment.
• GitHub-sync (Pro). Synchroniseer het project met een GitHub-repository en je kunt je eigen GitHub Actions-workflows toevoegen om tests bij elke push te draaien. Zie GitHub en export.

Voor een checklist van wat je met de hand moet testen vóór de lancering, zie hoe je je app test voor de lancering, en voor werken met versiebeheer, hoe je Git gebruikt met een met AI gebouwde app.

Veelgestelde vragen