CI/CD draait voor mij om het betrouwbaar en herhaalbaar van code naar productie brengen van software. Niet door zoveel mogelijk stappen te automatiseren, maar door precies die controles in te bouwen die nodig zijn om met vertrouwen te kunnen releasen.
Wat is CI/CD?
CI/CD staat voor Continuous Integration en Continuous Delivery of Deployment.
Bij Continuous Integration wordt iedere wijziging automatisch gecontroleerd door bijvoorbeeld builds, unit tests, integratietests en code-quality checks. Continuous Delivery zorgt er vervolgens voor dat software altijd in een deploybare staat blijft. Bij Continuous Deployment kan ook de laatste stap naar productie volledig automatisch verlopen.
Het belangrijkste doel is niet snelheid op zichzelf. Het doel is voorspelbaarheid, kwaliteit en het verkleinen van risico tijdens verandering.
Wat vind ik belangrijk bij CI/CD?
Een pipeline moet vooral duidelijk zijn.
Als een deployment faalt, wil je snel kunnen zien waarom. Als een pipeline uit tientallen ondoorzichtige stappen bestaat, verlies je uiteindelijk het voordeel van automatisering.
Daarom let ik vooral op:
snelle feedback tijdens development
geautomatiseerde tests
reproduceerbare builds
duidelijke scheiding tussen build, test en deployment
zo min mogelijk handmatige stappen
consistente deployments tussen omgevingen
duidelijke foutmeldingen wanneer iets misgaat
Automatisering heeft alleen waarde wanneer het proces er betrouwbaarder en eenvoudiger van wordt.
Hoe gebruik ik CI/CD?
Ik zie CI/CD als onderdeel van de normale development workflow.
Een commit of pull request moet automatisch aantonen dat de software technisch gezond genoeg is om verder te gaan. Denk aan compilatie, tests, code-quality checks, artifact generatie en container builds.
Daarbij probeer ik problemen zo vroeg mogelijk te vinden. Een fout die tijdens een pull request zichtbaar wordt, is bijna altijd eenvoudiger op te lossen dan een fout die pas na deployment naar voren komt.
Hoe bouw ik een pipeline op?
Ik werk graag met duidelijke fases.
Een eenvoudige pipeline ziet er bijvoorbeeld als volgt uit:
Code ophalen
Dependencies installeren
Applicatie bouwen
Tests uitvoeren
Codekwaliteit controleren
Artifact of container image genereren
Artifact publiceren
Deployment uitvoeren
Niet iedere applicatie heeft al deze stappen nodig. De pipeline moet aansluiten op de risico's en behoeften van het systeem.
Build once, deploy many
Een principe dat ik belangrijk vind is dat je een artifact één keer bouwt.
Dat artifact promoveer je vervolgens door verschillende omgevingen heen. Je bouwt dus niet opnieuw voor development, test, acceptatie en productie.
Dat voorkomt dat er kleine verschillen ontstaan tussen builds en geeft meer zekerheid dat wat je getest hebt uiteindelijk ook daadwerkelijk naar productie gaat.
CI/CD en kwaliteit
CI/CD is voor mij niet alleen deployment automation.
Het is ook een manier om technische afspraken automatisch af te dwingen.
Denk bijvoorbeeld aan:
unit tests
integratietests
contract tests
static code analysis
dependency checks
security scans
formatting
coverage checks
Je maakt kwaliteit daarmee minder afhankelijk van handmatige controles.
CI/CD binnen microservices
Bij microservices wordt CI/CD nog belangrijker.
Iedere service heeft vaak zijn eigen lifecycle en moet onafhankelijk gebouwd en uitgerold kunnen worden. Dat betekent dat pipelines klein, voorspelbaar en zoveel mogelijk onafhankelijk van andere services moeten blijven.
Daarbij moet je wel rekening houden met afhankelijkheden tussen services. Een technisch succesvolle deployment betekent namelijk niet automatisch dat het volledige systeem nog correct samenwerkt.
Daarom zijn bijvoorbeeld contract testing, backwards compatibility en goede observability belangrijk.
Rollback en deployment strategieën
Een goede pipeline houdt ook rekening met wat er gebeurt als een deployment niet goed gaat.
Je wilt vooraf nadenken over strategieën zoals:
rollback
rolling deployments
blue-green deployments
canary releases
feature flags
Welke strategie geschikt is hangt af van het systeem. Niet iedere applicatie heeft een complexe deploymentstrategie nodig.
Ook hier geldt voor mij: bewust eenvoudig blijven.
Veelgestelde vragen die ik krijg over CI/CD
Moet alles automatisch gedeployed worden?
Nee. Automatiseren omdat het technisch mogelijk is, is geen doel op zichzelf. Automatiseer vooral stappen die herhaalbaar zijn en waarbij automatisering fouten of onnodig handmatig werk voorkomt.
Hoe uitgebreid moet een pipeline zijn?
Zo uitgebreid als nodig, maar niet uitgebreider. Een pipeline moet vertrouwen geven en begrijpelijk blijven voor het team.
Moet iedere microservice een eigen pipeline hebben?
In de meeste gevallen wel. Een belangrijk voordeel van microservices is onafhankelijk kunnen ontwikkelen en deployen. De CI/CD inrichting moet dat ondersteunen.
Wat is belangrijker: een snelle of uitgebreide pipeline?
Snelle feedback. Zware controles kunnen later in het proces plaatsvinden, maar een developer moet zo snel mogelijk weten of een wijziging fundamenteel niet klopt.
Hoort CI/CD bij developers of DevOps?
Bij allebei. Als developer ben je mede-eigenaar van hoe jouw software gebouwd, getest en uitgerold wordt. De verantwoordelijkheid stopt niet zodra de code naar Git is gepusht.