# Wat is progressive delivery? Canary, blue-green en flags

URL: https://codebasechat.com/nl/journal/wat-is-progressive-delivery
Type: blog
Locale: nl
Published: 2026-11-03
Updated: 2026-11-03

---

> Progressive delivery rolt wijzigingen uit in kleine stappen, elk gecontroleerd met metrics. Zo werken canary, blue-green en feature flags samen, en zo begin je.

Wat is progressive delivery? Het is een manier van software uitrollen waarbij een wijziging in kleine, gecontroleerde stappen bij productie terechtkomt, en elke stap wordt gecontroleerd met echte metrics voordat de volgende begint. Gaat er iets mis, dan stopt de uitrol of draait hij zichzelf terug. Je zet dan niet langer je hele gebruikersbestand op één deploy.

Herken je dit? Een pull request is goedgekeurd, de CI is groen, de deploy gaat dinsdagmiddag de deur uit, en twintig minuten later vraagt iemand in Slack waarom de latency van de checkout is verdubbeld. Progressive delivery maakt dat gesprek korter, en zorgt ervoor dat het probleem 5% van het verkeer raakt in plaats van 100%.

## Wat verandert progressive delivery eigenlijk?

Klassieke continuous delivery beantwoordt één vraag: kunnen we dit veilig naar productie brengen? Progressive delivery voegt een tweede vraag toe: wie ziet het als eerste, en wat zegt ons dat we moeten stoppen?

De kern is het scheiden van **deployen** en **releasen**. Deployen betekent dat de nieuwe code op de servers draait. Releasen betekent dat gebruikers eraan worden blootgesteld. Zodra die twee los van elkaar staan, kun je op woensdagmiddag deployen en in je eigen tempo releasen, naar een gekozen doelgroep, met een weg terug.

De meeste bronnen noemen drie bouwstenen: geleidelijke verkeersverschuiving (canary), parallelle omgevingen (blue-green) en feature flags. Het zijn geen concurrenten. Volwassen teams gebruiken alle drie, elk op een eigen laag.

## Canary releases: hoeveel verkeer, en wie beslist?

Een canary release stuurt een klein deel van het verkeer, bijvoorbeeld 5%, naar de nieuwe versie, terwijl de rest op de oude blijft. Blijven het foutpercentage, de latency en de saturatie binnen je drempels, dan groeit dat deel: 5%, 25%, 50%, 100%. Zo niet, dan gaat het verkeer terug.

De keerzijde is dat fijnmazige verdelingen iets nodig hebben dat verkeer kan splitsen. [De documentatie van Argo Rollouts](https://argo-rollouts.readthedocs.io/en/stable/concepts/) stelt dat precieze canary-percentages een verkeersmanager vereisen, zoals een service mesh of een ingress controller. Zonder die laag krijg je alleen grove sturing op basis van het aantal replica's, en dan betekent "5%" misschien "één pod van twintig".

Zo ziet een gefaseerde canary eruit in een Argo Rollouts-manifest. Het is bewust kort.

`strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # kijk naar de dashboards of draai een analyse
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100`Sla een canary over als je service zo weinig verkeer krijgt dat 5% een handvol requests per uur is. Dan wacht je eindeloos op een signaal, of erger, je leest ruis als veiligheid. Voor services met weinig verkeer is een feature flag die alleen interne gebruikers raakt de betere eerste poort.

![Drie potten gevuld met blauw zand op verschillende hoogtes, als symbool voor gefaseerde verkeerspercentages](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/97a746-i1.webp)

## Blue-green deployments: wanneer is een volledige tweede omgeving de moeite waard?

Blue-green draait twee complete productieomgevingen. Blue bedient de gebruikers. Green krijgt de nieuwe versie en wordt getest terwijl die nog niet live staat. Als het resultaat goed is, schakel je het verkeer om.

Volgens de documentatie van Argo Rollouts gebeurt de omschakeling in één keer: de oude versie houdt al het productieverkeer tot de nieuwe is geverifieerd, en dan gaat de verdeling van 0% naar 100%. Dat is tegelijk de sterke en de zwakke kant. Terugdraaien is één schakelaar, dus snel. Maar de test gebeurt voordat echte gebruikers er zijn, en je betaalt dubbele infrastructuur zolang beide kanten draaien.

Het loont als je een stateful of kritieke dienst uitrolt, bijvoorbeeld een betaalroute waar twee versies nooit allebei een request mogen afhandelen. Sla het over als je databasemigratie niet op beide versies tegelijk kan draaien, want dan is de "directe rollback" een fictie.

![Twee evenwijdige spoorlijnen met een wisselhendel, als symbool voor blue-green omgevingen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/aba476-i2.webp)

## Waar passen feature flags?

Canary en blue-green werken op infrastructuurniveau. Feature flags werken binnen de applicatie. Een flag omhult een codepad met een voorwaarde die je tijdens runtime kunt wijzigen, zonder nieuwe deploy.

Dat maakt flags het fijnmazigste hulpmiddel in de gereedschapskist. Je kunt een functie eerst aan medewerkers tonen, dan aan 1% van de accounts, dan aan één klantsegment, en hem binnen seconden uitzetten als hij misgaat. Sommige teams zien flags als één techniek naast andere, andere noemen ze de voorwaarde voor de hele aanpak. In de praktijk houdt de tweede opvatting stand: zodra je op doelgroep in plaats van op server wilt uitrollen, heb je een flag nodig.

Flags kosten echter ook iets. Elke flag is een vertakking die je tests moeten dekken en een opruimticket dat iemand moet sluiten. Wil je de uitgebreide versie, dan behandelden we de mechanica en de schuld eerder in [wat een feature flag is](/journal/what-is-a-feature-flag). Behandel elke flag standaard als kortlevend, met een eigenaar en een verwijderdatum.

Tools als LaunchDarkly en Statsig verkopen de beheerlaag: targetingregels, audit logs, geleidelijke percentage-uitrol en experimenten.

## Wat maakt een uitrol progressief en niet gewoon traag?

Automatisering. Een uitrol die tien minuten pauzeert terwijl iemand naar een dashboard staart, is een trage deploy. Hij wordt progressive delivery zodra een machine de metrics controleert en de beslissing neemt.

Het patroon is overal hetzelfde:

- 
Leg de signalen vóór de release vast: foutpercentage, p95-latency en één bedrijfsmetric, zoals het afronden van de checkout.

- 
Leg de drempels vast die "stoppen" betekenen. Schrijf ze in de config, niet in iemands hoofd.

- 
Laat de controller op basis van die signalen promoveren, vasthouden of terugdraaien.

Argo Rollouts koppelt aan metric providers, zodat een uitrol automatisch kan worden gepromoveerd of afgebroken, afhankelijk van de checks. Een van de bronnen die we hebben gelezen zegt het botweg: progressive delivery zonder automatische rollback is gewoon een trage deployment. Dat zijn we eens.

![Ontwikkelaarshanden op een toetsenbord naast een monitor met vage metrics-grafieken](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/33c271-i3.webp)

### Welke metrics moeten een uitrol sturen?

Hou het bij een kleine set. Drie of vier signalen die je al vertrouwt, verslaan twintig waar je nog nooit een alert op hebt gezet.

Een werkbare startset: het aantal HTTP 5xx-fouten van de canary tegenover de baseline, de p95-latency van de canary tegenover de baseline, saturatie (CPU, geheugen, wachtrijdiepte) en één productmetric. Vergelijk de canary met de baseline op hetzelfde moment, niet met "vorige week", want verkeerspatronen verschuiven.

Hier wordt je observability-stack meer dan een prettige extra. Kun je metrics niet splitsen per versie of per flagvariant, dan kun je de canary niet van de baseline onderscheiden, en stort de aanpak in. Onze inleiding over [wat observability is](/journal/what-is-observability) laat zien hoe je dat voor elkaar krijgt.

### Hoe hangt progressive delivery samen met trunk-based development?

Ze passen goed bij elkaar. [Trunk-based development](/journal/what-is-trunk-based-development) houdt branches kort en voegt kleine wijzigingen vaak samen. Het risico is dat onaf of ongetest werk vaker in main terechtkomt. Progressive delivery maakt dat veilig: de code landt op trunk, staat achter een flag en wordt geleidelijk vrijgegeven.

Kleine batches plus geleidelijke blootstelling maken debuggen bovendien goedkoper. Als een canary faalt, is de lijst met verdachten één wijziging, niet veertig. Wie om elf uur 's avonds een week aan samengevoegde commits heeft doorzocht, weet wat dat waard is.

## Wat is een realistische eerste stap voor een team van 10 tot 30 engineers?

Begin niet met het installeren van een service mesh. Begin met het kleinste ding dat je een stopknop geeft.

- 
**Week 1:** zet één risicovolle functie achter een flag en rol die eerst uit naar je eigen team.

- 
**Week 2:** voeg dashboards per versie toe voor foutpercentage en latency. Kan je tooling niet op versie splitsen, los dat dan eerst op.

- 
**Week 3 en verder:** verplaats één stateless dienst naar een canary-controller met twee of drie stappen en een automatische afbreking bij te veel fouten.

Meet het in uren, niet in een "gevoel van veiligheid". Tel hoeveel incidenten beperkt bleven tot een klein deel van de gebruikers, en hoe lang de rollback duurde. Die twee getallen vertellen je of het voor jullie team werkt.

## Waar breken progressieve uitrollen meestal?

Op drie plekken, en geen daarvan is de controller.

**Databasemigraties.** Een canary betekent dat twee versies van je code tegelijk dezelfde database raken. Als versie N+1 een kolom verwijdert of hernoemt die versie N nog leest, sloopt de canary de baseline. De saaie oplossing is expand and contract: voeg eerst de nieuwe kolom toe, lever code die beide schrijft, vul de data aan, schakel de reads om, en verwijder de oude kolom pas later.

**Sticky sessions en caches.** Als een gebruiker bij elk request tussen oude en nieuwe versie heen en weer springt, krijg je bugs die niemand kan reproduceren. Vastpinnen van gebruikers aan een variant voor de duur van de uitrol, via cookie, account-id of flagevaluatie, lost dat op.

**Metrics met vertraging.** Een conversiemetric die per uur wordt bijgewerkt, kan geen stap van tien minuten sturen. Stuur tijdens de uitrol op snelle signalen, zoals fouten en latency, en bekijk de trage bedrijfsmetric voordat je van 50% naar 100% gaat.

### Hoe houd je bij wat er in de repo live staat?

Progressive delivery verspreidt een release over configbestanden, flagdefinities, rollout-manifesten en dashboards. Na een paar maanden wordt de vraag "welke flag bewaakt het nieuwe factuurpad, en wie is de eigenaar?" de bekende routine: grep, blame, en dan iemand vragen.

Dat is een probleem van code lezen, niet van tooling. Zoeken in de repo op de flagsleutel en elke verwijzing naar de aanroep volgen, is de snelste manier om dode flags en halfafgeronde uitrollen te vinden. Een hulpmiddel dat uit je echte code beantwoordt "waar wordt deze flag geëvalueerd, en wat gebeurt er als hij uit staat?", bespaart hier meer tijd dan nog een dashboard.

## Wat we zouden overslaan

Sla blue-green voor alles over als je infrarekening al een gespreksonderwerp is. Sla canaries over op diensten met nauwelijks verkeer. Sla elke rollout-tooling over die niemand in het team om drie uur 's nachts kan debuggen.

Het echte probleem is niet de strategie die je kiest. Het is de kloof tussen code uitrollen en weten wat die in productie doet. Progressive delivery verkleint die kloof één verkeersdeel tegelijk, en het eerste deel is het belangrijkst: maak het klein, maak het observeerbaar en geef het een uitschakelaar.

## FAQ

### Wat is progressive delivery in het kort?

Je rolt software eerst uit naar een klein deel van de gebruikers, controleert echte metrics, en verbreedt het publiek alleen als de cijfers kloppen. Zo niet, dan stopt de release of wordt hij teruggedraaid.

### Wat is het verschil tussen progressive delivery en continuous delivery?

Continuous delivery maakt elke wijziging uitrolbaar. Progressive delivery bepaalt hoe een release bij gebruikers komt: per verkeerspercentage, doelgroep of omgeving, met metrische controles tussen de stappen.

### Is een canary release hetzelfde als progressive delivery?

Nee. Een canary is één techniek. Progressive delivery is de bredere praktijk die ook blue-green deployments, feature flags en geautomatiseerde analyse en rollback omvat.

### Heb ik Kubernetes nodig voor progressive delivery?

Nee. Feature flags werken in elke applicatie. Fijnmazige canary-percentages vragen wel om iets dat verkeer splitst, zoals een service mesh, een ingress controller of een load balancer met gewogen routering.

### Wanneer is blue-green beter dan een canary?

Als een gedeeltelijke uitrol verwarrend of onveilig zou zijn, bijvoorbeeld op een betaalroute waar twee versies niet allebei requests mogen afhandelen. De prijs is dubbele infrastructuur zolang beide omgevingen draaien.

### Welke metrics moeten een progressieve uitrol sturen?

Begin met het foutpercentage van canary versus baseline, de p95-latency en saturatie, plus één snelle productmetric. Vergelijk beide versies tegelijk en houd de set klein.

### Hoe verhouden feature flags zich tot progressive delivery?

Flags werken binnen de applicatie, dus je kunt op doelgroep in plaats van op server uitrollen. Ze bieden de fijnste sturing, maar elke flag heeft een eigenaar en een verwijderdatum nodig.