Je hebt net je eerste CI/CD pipeline opgezet; tests draaien automatisch, builds zijn groen, en dan komt die ene vraag: "Gaan we voor continuous delivery of continuous deployment?"
Het verschil lijkt klein, beide eindigen op 'deployment', maar de impact op jouw werk als tester? Enorm. Bij de ene aanpak test je features voor ze live gaan, bij de andere bouw je systemen die zichzelf testen in productie.
Met de juiste YAML-configuraties en monitoring queries maak je een weloverwogen keuze tussen beide aanpakken.
Het technische verschil tussen delivery en deployment
Continuous delivery en continuous deployment verschillen op één cruciaal punt: de production deployment trigger. Bij continuous delivery komt code automatisch tot aan de production gate, maar jij of je team triggert de deployment. Bij continuous deployment daarentegen gaat elke succesvolle build automatisch live.
Het verschil zit in één stap van de pipeline:
Continuous Delivery pipeline:
stages:
- build
- test
- deploy-staging
- manual-approval # Het cruciale verschil
- deploy-production
Continuous Deployment pipeline:
stages:
- build
- test
- deploy-staging
- deploy-production # Geen manual step
Simpel toch? Maar die ene regel code verandert alles aan hoe je test.
Neem een platform dat op deze schaal draait. Developers deployen er meerdere keren per dag. Het testteam bouwt niet alleen tests die controleren of iets productie-klaar is, maar vooral tests die detecteren wanneer iets in productie kapot gaat. Duizenden automated tests draaien binnen een kwartier. Gaat er iets fout? Dan volgt een geautomatiseerde rollback binnen enkele minuten.
Bij fintechs kiezen teams vaak bewust voor continuous delivery, juist omdat ze zich geen downtime kunnen veroorloven. De manual approval geeft hen tijd voor security scans, performance tests onder productielast en een laatste sanity check.
Het verschil bepaalt of je een bewaker bent of een bouwer. Uiteindelijk zijn beide waardevol.
Benieuwd wat continuous delivery concreet oplevert? Lees over de kracht van continuous delivery.
Continuous Delivery: jouw rol als quality gate
In een continuous delivery setup ben jij de laatste lijn tussen code en klant. Dat geeft je macht én verantwoordelijkheid.
Praktisch gezien werk je met deployment pipelines die stoppen voor production:
stage('Deploy to Production') {
when {
expression {
currentBuild.result == null || currentBuild.result == 'SUCCESS'
}
}
input {
message "Deploy to production?"
submitter "qa-team,lead-dev"
parameters {
choice(name: 'DEPLOY_TYPE', choices: ['full', 'canary', 'rollback'])
}
}
steps {
script {
if (params.DEPLOY_TYPE == 'canary') {
sh 'kubectl set image deployment/api api=api:${BUILD_NUMBER} -n production'
sh 'kubectl scale deployment/api --replicas=2 -n production'
}
}
}
}
Deze setup geeft je controle: je kunt kiezen voor full deployment, canary release of rollback. Belangrijker nog, je hebt tijd om te testen wat automation mist.
Neem de edge case die alleen opvalt als je het systeem echt gebruikt: twee features werken apart perfect, maar samen blokkeren ze de checkout flow. Automated tests vangen het gros van de bugs, maar dit soort gevallen vraagt om menselijke exploratie.
Met continuous delivery bouw je vaak deze teststrategie:
- Automated regression: 2000+ tests die bij elke commit draaien
- API contract testing: Pact of Spring Cloud Contract
- Performance benchmarks: Gatling scripts die response times monitoren
- Manual exploratory: 2-4 uur per release voor edge cases
De tools? Jenkins met Blue Ocean voor visual pipelines. GitLab CI/CD met environments. Of GitHub Actions met manual approval workflows. Kies wat past bij je stack. Zie ook hoe je software testen integreert in een continuous delivery pipeline.
Uit de testpraktijk van Your Test Professionals: teams die het meest profiteren van continuous delivery, gebruiken de manual approval als bewuste kwaliteitscheck en niet als reflex. Wat automation mist, vang je daar op: edge cases, productie-ervaring en het gesprek met de business.
Continuous Deployment: automation als foundation
Continuous deployment is een andere wereld: er is geen "zullen we deployen?", code gaat automatisch live zodra tests slagen.
Netflix is het klassieke voorbeeld, met duizenden deploys per dag. Hun geheim: een teststrategie die draait om "fail fast, recover faster":
# Automated rollback trigger
def check_error_rate(service_name, threshold=0.01):
current_rate = get_metric(f"{service_name}.error_rate")
baseline = get_baseline(service_name)
if current_rate > baseline * (1 + threshold):
rollback(service_name)
alert_team(f"Rolled back {service_name}: error rate {current_rate}")
return False
return True
Als test engineer verschuift je focus van "prevent bugs" naar "detect and recover". Daarom bouw je:
1. Synthetic monitoring:
// Playwright synthetic test die elke 5 minuten draait
test('Critical user journey', async ({ page }) => {
await page.goto('https://app.example.com');
await page.click('text=Login');
await page.fill('#email', 'synthetic@test.com');
await page.fill('#password', process.env.SYNTHETIC_PWD);
await page.click('button[type="submit"]');
// Verify critical elements loaded
await expect(page.locator('.dashboard')).toBeVisible({ timeout: 5000 });
// Check response times
const metrics = await page.evaluate(() => performance.getEntriesByType('navigation'));
expect(metrics[0].loadEventEnd).toBeLessThan(3000);
});
2. Feature flags voor safety:
if (await featureFlag.isEnabled('new-payment-flow', user)) {
// New code path
return processPaymentV2(order);
} else {
// Stable code path
return processPaymentV1(order);
}
3. Observability-first testing:
# Datadog monitor voor automated rollback
monitors:
- name: API Error Rate
type: metric alert
query: avg(last_5m):avg:api.request.error{env:prod} > 0.05
message: |
Error rate exceeded 5%
Automated rollback initiated
@pagerduty @slack-alerts
tags:
- automated-rollback:true
De grootste omslag? Je accepteert dat bugs production kunnen halen, maar zorgt dat je ze binnen minuten detecteert en fixt.
Teststrategieën voor beide aanpakken
De testing pyramide ziet er anders uit voor delivery dan voor deployment.
Continuous Delivery Testing Pyramid:
/\
/ \ 5% - Manual Exploratory
/----\
/ \ 15% - E2E Tests
/--------\
/ \ 30% - Integration Tests
/------------\
/ \ 50% - Unit Tests
/________________\
Continuous Deployment Testing Pyramid:
/\
/ \ 25% - Production Monitoring
/----\
/ \ 5% - E2E Tests (critical paths only)
/--------\
/ \ 20% - Integration Tests
/------------\
/ \ 50% - Unit Tests
/________________\
Bij continuous deployment verschuift het testfocus van preventie naar detectie: het zwaartepunt ligt op production monitoring in plaats van uitgebreide E2E suites.
Een test suite voor continuous deployment legt de nadruk anders:
// Jest unit test - draait in milliseconden
describe('PriceCalculator', () => {
it('applies discount correctly', () => {
const calculator = new PriceCalculator();
expect(calculator.calculate(100, 0.1)).toBe(90);
});
});
// API integration test - draait in seconden
describe('POST /api/orders', () => {
it('creates order with valid data', async () => {
const response = await request(app)
.post('/api/orders')
.send({ product: 'ABC123', quantity: 2 });
expect(response.status).toBe(201);
expect(response.body.orderId).toBeDefined();
});
});
// Critical path E2E - alleen voor continuous deployment
describe('Checkout flow monitoring', () => {
it('completes purchase end-to-end', async () => {
// Dit draait elke 5 minuten in productie
await syntheticUser.completePurchase();
await metrics.record('checkout.success', 1);
});
});
Je teststrategie hangt direct af van je deployment model. Investeer in de tests die het snelst feedback geven. Unit tests voor logica, integration tests voor API contracts, en production monitoring voor het echte werk. Wil je weten wanneer je regressietesten moet draaien? Lees het artikel over regressietesten.
Decision matrix: welke aanpak past bij jou?
De keuze hangt af van een paar vragen:
Start: hoe kritiek zijn bugs voor je gebruikers?
│
├─> Life-threatening of financial impact?
│ └─> Continuous Delivery (menselijke check essentieel)
│
└─> Frustrerend maar niet kritiek?
│
├─> Heb je sterke rollback capabilities?
│ ├─> Ja: overweeg Continuous Deployment
│ └─> Nee: blijf bij Continuous Delivery
│
└─> Is je test automation coverage > 80%?
├─> Ja: klaar voor Continuous Deployment
└─> Nee: bouw eerst je test suite uit
De keuze laat zich ook aflezen aan het type organisatie. Waar een fout direct levens of grote bedragen raakt, wint continuous delivery: healthcare platforms kunnen zich geen bug veroorloven die levens kost, financial services moeten compliance-audits kunnen tonen, en enterprise-klanten verwachten stabiliteit boven snelheid. Ook teams die nog onder de 70% test automation zitten, houden de menselijke check liever in de pipeline.
Waar snelheid het product is, werkt continuous deployment beter: consumer apps die dagelijks itereren op gebruikersfeedback, SaaS-platforms die continu verbeteren, en interne tools waar een fout hooguit een klein team raakt. Zij hebben de monitoring en rollback-capaciteit al op orde, en dan weegt automatisch deployen zwaarder dan de laatste handmatige controle.
Praktijktip: begin met "Shadow Continuous Deployment". Deploy automatisch naar production maar achter een feature flag. Meet alles, activeer niets. Na 2 maanden heb je data over hoe vaak je zou hebben moeten rollbacken. Is dat < 1%? Dan ben je klaar voor echte CD.
Uit onze ervaring met teams van 5-15 developers: shadow deployment werkt het best wanneer de monitoring al op orde is en het team de rollback-procedure kent. Begin dus niet met het automatisch deployen, maar met het zichtbaar maken van wat er in productie gebeurt.
Onze testers zien in de praktijk dat deze keuze zelden technisch is, maar bijna altijd organisatorisch: gaat je team mee in de hogere deploy-frequentie, en is je monitoring volwassen genoeg om een terugdraaiing snel te signaleren?
De juiste tools voor delivery en deployment
De tooling volgt je keuze: de ene track heeft een bewuste approval-stap nodig, de andere een systeem dat automatisch in lijn blijft met je repo.
Voor Continuous Delivery:
Bij continuous delivery draait de tooling om één ding: een manual approval die bewust is ingebouwd. GitHub Actions regelt dat met een environment die wacht op goedkeuring voordat er naar productie wordt gedeployed:
name: Deploy to Production
on:
workflow_dispatch:
inputs:
environment:
description: 'Environment to deploy to'
required: true
default: 'production'
type: choice
options:
- production
- staging
jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: ${{ github.event.inputs.environment }}
steps:
- uses: actions/checkout@v3
- name: Deploy
run: |
echo "Deploying to ${{ github.event.inputs.environment }}"
./deploy.sh ${{ github.event.inputs.environment }}
Voor Continuous Deployment:
Bij continuous deployment neem je de menselijke stap juist weg. Argo CD houdt productie continu in lijn met je Git-repo en draait automatisch terug als iets afwijkt:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: production-app
spec:
source:
repoURL: https://github.com/company/app
targetRevision: main
path: k8s/production
destination:
server: https://kubernetes.default.svc
syncPolicy:
automated:
prune: true
selfHeal: true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
Monitoring voor beide:
Om je deployment strategie te blijven volgen, zet je in Grafana drie metrics centraal: hoe vaak je deployt, hoe vaak een deployment faalt en hoe snel je herstelt. De queries:
# Deployment frequency
increase(deployments_total[1d])
# Deployment failure rate
rate(deployments_failed[5m]) / rate(deployments_total[5m])
# Mean time to recovery
histogram_quantile(0.95,
sum(rate(deployment_recovery_seconds_bucket[5m])) by (le)
)
Met deze metrics maak je je deployment strategie op basis van data, niet op onderbuikgevoel.
De keuze tussen continuous delivery en continuous deployment is geen of/of: die hangt af van je team, je monitoring en je risicobereidheid.
Meet eerst je huidige situatie: hoe vaak je deployt, hoeveel bugs productie bereiken en wat je MTTR is. Bepaal daarna waar je bottleneck ligt: test automation coverage, rollback capabilities of team comfort. Experimenteer vervolgens klein: probeer continuous deployment voor één microservice, of automated deployment naar staging met een manual trigger naar production.
Het punt is niet om de "beste" aanpak te kiezen, maar om de aanpak te vinden die jouw team helpt sneller waarde te leveren met acceptabel risico.
Want uiteindelijk gaat het niet om hoe vaak je deployt. Het gaat om hoe betrouwbaar je features levert die gebruikers waarderen.
Wil je meer weten over hoe test automation in een CI/CD-omgeving werkt? Lees over CI/CD testen.
