Progressive Delivery in 2026: canary vs blue-green vs feature flags

De meeste teams praten over sneller deployen. De teams die op schaal overeind blijven, praten over iets anders: hoe je een change in productie brengt zonder je hele klantenbestand in te zetten op de aanname dat hij klopt. Dat is wat progressive delivery is - een set technieken om de blast radius van een release te verkleinen en jezelf een snelle, saaie uitweg te geven wanneer er iets misgaat. Voor engineering directors die gereguleerde platformen met hoge doorvoer in de Benelux draaien, is dit geen tooling-trivia. Het bepaalt of een slechte deploy een omschakeling van 90 seconden is of een all-hands-incident om 3 uur 's nachts. Hier is wat de termen echt betekenen, hoe canary, blue-green en feature flags verschillen, en waarom de discipline in 2026 meer telt dan twee jaar geleden.

Een gele Atlantische kanarie op een tak - de vogel die de canary release zijn naam gaf, vroeger gebruikt om gevaar te detecteren voordat het de rest van de groep bereikte. — Foto: David J. Stang, CC BY-SA 4.0, via Wikimedia Commons. De canary release leent de metafoor van de kolenmijn: stel eerst een kleine steekproef bloot en laat die je waarschuwen voordat de hele zwerm gevaar loopt.

Wat is progressive delivery, en waarom telt het nu?

Progressive delivery is een overkoepelende term voor het uitrollen van changes naar een gecontroleerde, groeiende slice van verkeer of gebruikers in plaats van alles in één keer om te schakelen. Het bundelt canary releases, blue-green deployments, feature flags en A/B-testen onder één idee: ontkoppel het deployen van code van het blootstellen van een feature, en stel die blootstelling afhankelijk van echte signalen uit productie. Unleash verwoordt de relatie helder - een canary release "rolt nieuwe softwareversies geleidelijk uit naar een kleine subset van gebruikers", terwijl progressive delivery "een uitgebreide deployment-methodologie is die verschillende deployment-strategieën combineert" waaronder canary, feature flags en blue-green (Unleash). Canary is een techniek; progressive delivery is de paraplu.

De reden dat dit in 2026 meer telt, is het aantal changes. Het 2024 DORA-rapport van Google constateerde dat naarmate de AI-adoptie steeg, zowel de stabiliteit als de doorvoer van delivery op teamniveau daalden, en benoemde de oorzaken direct: batchgroottes groeien wanneer AI code goedkoop maakt om te produceren, en "fundamenten als kleine batchgroottes en robuust testen blijven cruciaal" (DORA, 2024). Meer changes, grotere batches en meer nieuwe codepaden betekenen dat meer van je storingen storingen zijn die niemand voorzag. Progressive delivery is het operationele antwoord: als je niet elke slechte change kunt voorkomen, maak dan elke change goedkoop om te betrappen en nog goedkoper om terug te draaien.

Canary vs blue-green deployment: wat is het verschil?

Dit zijn de twee meest verwarde termen, en het verschil zit in hoe verkeer wordt gesplitst. Blue-green draait twee volledige productieomgevingen - één live (blue), één inactief met de nieuwe versie (green). De oorspronkelijke definitie van Martin Fowler is nog steeds de helderste: je houdt "twee productieomgevingen, zo identiek mogelijk", schakelt verkeer van de een naar de ander, en "als er iets misgaat schakel je de router terug naar je blue-omgeving" (Fowler, 2010). De omschakeling is alles-of-niets en vrijwel direct. De kracht is de snelheid van terugdraaien; de kosten zijn het draaien van dubbele infrastructuur en het ontbreken van een geleidelijke soak - op het moment dat je omschakelt, zit 100% van de gebruikers op de nieuwe build.

Een canary release keert die afweging om. In plaats van twee omgevingen route je een klein percentage live verkeer - vaak 1 tot 5% - naar de nieuwe versie naast de oude, kijk je toe, en verbreed je het aandeel alleen als hij zich gedraagt. Je krijgt een echte soak-periode op echte gebruikers met een begrensde blast radius, tegen de prijs van het gelijktijdig draaien van twee versies en het nodig hebben van traffic-shaping. De vuistregel: grijp naar blue-green als je de snelst mogelijke volledige rollback wilt en dubbele capaciteit kunt betalen; grijp naar canary als je blootstelling wilt beperken en regressies op een kleine steekproef wilt betrappen voordat ze iedereen bereiken. Veel volwassen teams draaien beide - blue-green voor de omgevingsomschakeling, canary-weging voor de verkeersramp.

Waar passen feature flags - en hoe verschillen ze van een canary?

Dit is de nuance waar mensen over struikelen. Canary en blue-green werken op de deployment-laag - welke build een request bedient. Feature flags werken op de release-laag - welk codepad draait voor een bepaalde gebruiker, onafhankelijk van wat er is gedeployed. Zoals Pete Hodgson het stelt, laten feature toggles teams "systeemgedrag aanpassen zonder code te wijzigen", waardoor je afgerond werk naar productie kunt brengen terwijl je de nieuwe functionaliteit verborgen houdt tot je hem wilt onthullen - "release loskoppelen van deployment" (Hodgson, 2017).

In de praktijk kan een feature flag dingen die een canary niet kan. Hij kan een specifieke klant, tenant of regio targeten in plaats van een willekeurig verkeerspercentage. Hij kan wekenlang blijven staan terwijl je een feature dark-launcht naar interne gebruikers. En hij geeft je een kill switch die gedrag in seconden terugdraait zonder redeploy - de snelste rollback van alle technieken hier, omdat niets opnieuw hoeft te bouwen of in te plannen. Het addertje is discipline: elke flag is een vertakking in je code en een kleine belasting op testen. Langlevende flags die niemand opruimt worden hun eigen risico, dus behandel het opruimen van flags als onderdeel van de definition of done, niet als bijzaak.

Hoe draai je een slechte release eigenlijk terug?

Terugdraaien is waar deze strategieën hun waarde bewijzen, en elke strategie geeft je een andere uitweg. Met blue-green schakel je de router terug naar de vorige omgeving - seconden, geen rebuild. Met een feature flag zet je de flag uit en stopt het aanstootgevende pad direct voor iedereen met draaien. Met een canary stop je met verbreden en drain je het kleine aandeel verkeer terug naar de stabiele versie voordat de meeste gebruikers de change ooit zagen.

De sprong in 2026 is dat dit niet langer een menselijke beslissing hoeft te zijn. Kubernetes-controllers automatiseren nu de hele loop. Argo Rollouts, een progressive delivery-controller voor Kubernetes, integreert met ingress controllers en service meshes om verkeer geleidelijk te verschuiven en bevraagt je metrics-provider om "geautomatiseerde promotie of rollback op basis van geslaagde of gefaalde metrics" aan te sturen (Argo Rollouts-documentatie). In de praktijk definieer je een analyse - foutpercentage, latency, saturatie - en de controller breekt de canary af en draait hem automatisch terug als de nieuwe versie de grens overschrijdt, voordat er ook maar een pager afgaat. Dat is het verschil tussen een rollback-plan en een rollback die om 3 uur 's nachts daadwerkelijk gebeurt.

Verlaagt progressive delivery de change failure rate?

Het is de moeite waard hier precies te zijn, want het eerlijke antwoord is genuanceerd. Change failure rate - het aandeel deployments dat een fout, incident of rollback veroorzaakt - is een van DORA's vier kernsignalen voor stabiliteit. Progressive delivery verlaagt niet noodzakelijk het tempo waarin slechte code productie bereikt; een canary die een regressie betrapt en terugdraait, is in de meeste definities nog steeds een gefaalde change. Wat het verlaagt zijn de kosten en de blast radius van elke storing: minder gebruikers raken de bug, de fout wordt in minuten op een kleine steekproef betrapt, en de hersteltijd klapt in richting de elite-benchmark van onder één uur.

Dat onderscheid is de hele pointe. In een wereld waarin AI-ondersteunde ontwikkeling het aantal changes opdrijft en, aldus DORA, de stabiliteit stilletjes uitholt (DORA, 2024), lever je meer defects, niet minder. De teams die betrouwbaar blijven zijn niet de teams die productie nooit breken - het zijn de teams voor wie productie breken klein, ingeperkt en omkeerbaar is. Progressive delivery is hoe je die eigenschap bewust koopt in plaats van erop te hopen.

Wat dit betekent voor een gereguleerd Benelux-team

De praktische agenda is kort. Ten eerste: scheid deploy van release - feature flags zijn de goedkoopste manier om te stoppen "de code staat in productie" en "de feature staat aan" als hetzelfde moment te behandelen. Ten tweede: zet een traffic-shaping-mechanisme voor productie zodat een nieuwe build een kleine steekproef ontmoet voordat hij iedereen ontmoet, of dat nu een canary-controller is of een blue-green-omschakeling die je in seconden kunt terugdraaien. Ten derde: koppel rollback aan metrics, niet aan het oordeel van een mens onder stress - geautomatiseerde analyse die een slechte canary afbreekt is de control die zowel auditors als on-call engineers willen. Niets hiervan vervangt kleine batches en robuust testen; DORA is ondubbelzinnig dat die fundamenten nog steeds je uitkomsten bepalen. Progressive delivery is het vangnet eronder - en naarmate het aantal changes stijgt, houdt een vangnet op optioneel te zijn.