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

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 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.

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.

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. 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:

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

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

3. 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.

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 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 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.