Met een canarydeployment in PHP stel je een nieuwe versie bloot aan een gecontroleerd deel van het verkeer en beoordeel je het gedrag ervan voordat je het aandeel uitbreidt. De waarde ervan is niet dat het tests vervangt of garandeert dat een wijziging veilig is: het biedt een manier om problemen in productie op te sporen terwijl de impact aanvankelijk beperkt blijft en er expliciete besliscriteria zijn.
Om dit te laten werken, moeten versies naast elkaar kunnen bestaan, moet het verkeer gecontroleerd kunnen worden gerouteerd en moet het team vergelijkbare resultaten kunnen observeren. Als de infrastructuur die voorwaarden niet ondersteunt, kan een eenvoudigere gefaseerde uitrol of een goed geplande onderhoudsperiode een verstandigere keuze zijn.
Welk risico een canarydeployment beheerst
Geautomatiseerde tests en preproductieomgevingen helpen defecten op te sporen, maar reproduceren niet noodzakelijk de werkelijke verdeling van klanten, gegevens, integraties en belasting. Een canary test een versie met echte verzoeken, terwijl vooraf wordt beperkt welk deel van de gebruikerspopulatie hierdoor kan worden geraakt.
In de praktijk ontvangt de kandidaatversie een deel van het verkeer, terwijl de stabiele versie de rest blijft afhandelen. Het team vergelijkt de gezondheidssignalen van beide versies. Als er geen relevante regressies zijn, wordt de blootstelling uitgebreid; als er ongunstige signalen optreden, wordt de uitbreiding stopgezet en de afgesproken procedure gevolgd.
Een canary is iets anders dan een gefaseerde uitrol waarbij simpelweg in meerdere stappen wordt gepubliceerd. Bij een canary ligt de nadruk op het evalueren van een gebruikerspopulatie en het vergelijken van signalen voordat een beslissing wordt genomen. Het is ook niet hetzelfde als geleidelijke activering met een feature flag: die kan een nieuwe functie verbergen terwijl de code al is uitgerold, maar maakt het niet noodzakelijk mogelijk om twee applicatieversies met elkaar te vergelijken.
Wanneer je het gebruikt en wanneer je iets eenvoudigers kiest
Een canary kan waardevol zijn als een wijziging aanzienlijke gevolgen kan hebben, de applicatie voldoende verkeer ontvangt om signalen waar te nemen en de architectuur toestaat dat twee versies tegelijk actief zijn. Dit is vooral nuttig als de getroffen gebruikerspopulatie kan worden afgebakend en verzoeken kunnen worden gekoppeld aan de versie die ze heeft afgehandeld.
Het is niet altijd de moeite waard. Bij weinig verkeer kunnen de resultaten geen uitsluitsel geven; als de service klein is en de wijziging een beperkte reikwijdte heeft, kunnen de operationele kosten van routing en observability zwaarder wegen dan de voordelen. Een canary mag ook niet worden voorgesteld als afdoende bescherming bij een incompatibele migratie of een onomkeerbare bewerking.
Eenvoudigere alternatieven zijn publiceren tijdens een periode met minder activiteit, een feature flag gebruiken om een specifieke functionaliteit te beheren of eerst uitrollen naar een interne omgeving. Deze opties lossen verschillende problemen op: een tijdvenster beperkt de blootstelling in de tijd, een flag regelt de activering en een interne omgeving maakt validatie vooraf mogelijk. De keuze hangt af van het risico dat je wilt beperken en van de beschikbare mogelijkheden.
Infrastructuur- en operationele vereisten
Controleer voordat je een canarydeployment in PHP automatiseert of de infrastructuur de stabiele en kandidaatversie naast elkaar kan uitvoeren. Daarvoor kunnen afzonderlijke deploymentartefacten, compatibele PHP-processen en configuratie, en voldoende capaciteit om beide versies tijdens de evaluatie te draaien nodig zijn.
- Gecontroleerde routing: een load balancer, proxy, containerplatform of ander onderdeel moet een bepaald aandeel of een afgebakende gebruikerspopulatie naar de kandidaatversie kunnen sturen. Het mechanisme moet omkeerbaar zijn en een operationeel verantwoordelijke hebben.
- Versie-identificatie: logs, meetwaarden en traces moeten duidelijk maken welke versie elk verzoek heeft afgehandeld. Zonder dit onderscheid kan een vergelijking de effecten van beide versies door elkaar halen.
- Compatibele configuratie: secrets, omgevingsvariabelen, sessies, caches en gedeelde queues moeten tijdens de co-existentie werken. Ga niet uit van formaten of contracten die tussen versies incompatibel zijn.
- Actiegerichte observability: definieer dashboards en alerts voordat je publiceert. Een meetwaarde die niemand tijdig kan raadplegen of interpreteren, helpt niet bij de besluitvorming.
Houd ook rekening met sessiepersistentie en traffic affinity. Een gebruiker altijd aan dezelfde versie koppelen kan de vergelijking vergemakkelijken, maar is afhankelijk van de architectuur en kan de resultaten vertekenen. In alle gevallen moeten routeringsbeslissingen onverwachte statuswijzigingen tussen versies voorkomen.
Gebruikerspopulatie, fasen en evaluatiesignalen kiezen
Begin met een gebruikerspopulatie waarvan je de blootstelling kunt toelichten en beperken. Je kunt deze definiëren aan de hand van een percentage verzoeken of een gecontroleerd segment, zolang de selectie consistent is en niet juist de belangrijke gevallen uitsluit. Ga er niet van uit dat een bepaald percentage voor elke service veilig is: de initiële omvang hangt af van het volume, de mogelijke impact en de reactiemogelijkheden.
Leg vooraf de uitbreidingsfasen en observatieduur vast. Elke fase moet lang genoeg duren om het relevante gebruik te observeren; zomaar een willekeurig interval afwachten volstaat niet als de betreffende stroom maar zelden voorkomt. Bepaal wie de gegevens beoordeelt en wie het proces mag stopzetten.
Vergelijk de kandidaatversie met de stabiele versie aan de hand van signalen waarmee zowel technische storingen als nadelige gevolgen voor gebruikers kunnen worden vastgesteld:
- Fouten: percentages mislukte responses, PHP-exceptions, fouten in afhankelijkheden en storingen in asynchrone processen, uitgesplitst per versie.
- Latentie: responstijden, bij voorkeur uitgesplitst naar belangrijke routes of transacties, samen met signalen van overbelasting van resources.
- Bedrijfsresultaten: het voltooien van een bewerking, verwerkte betalingen of fouten in een relevante flow, steeds met betrouwbare definities en gegevensbronnen.
- Integriteit: duplicaten, inconsistente statussen of afwijkingen tussen systemen, wanneer de wijziging gegevens of processen kan beïnvloeden.
Een verbetering of stabiele waarde voor een geaggregeerde meetwaarde sluit een probleem dat zich concentreert in één route, bij één klant of in één afhankelijkheid niet uit. Controleer de context en de verdeling van fouten, en vergelijk waar mogelijk gelijkwaardige perioden en gebruikerspopulaties.
Drempelwaarden vaststellen en een rollback voorbereiden
Spreek vóór de deployment af onder welke voorwaarden je kunt uitbreiden, wanneer je moet pauzeren en wanneer je moet terugrollen. De drempelwaarden moeten rekening houden met de baseline en de aanvaardbare impact op de service; er bestaan geen universele waarden. Een toename van fouten op een kritieke route kan bijvoorbeeld reden zijn om te pauzeren, ook als het algemene gemiddelde stabiel blijft.
Documenteer ook de procedure: wie de routing wijzigt, hoe de kandidaatversie wordt verwijderd, welke controles bevestigen dat de stabiele versie weer verkeer ontvangt en hoe het incident wordt gecommuniceerd. Pauzeren en terugrollen zijn geen synoniemen: pauzeren stopt de blootstelling of uitbreiding terwijl het probleem wordt onderzocht; een rollback brengt de service volgens een gevalideerde procedure terug naar de vorige versie.
Een code-rollback maakt wijzigingen in gegevens, reeds verzonden berichten of externe bewerkingen niet automatisch ongedaan. Daarom moet een snelle rollback als onderdeel van het plan worden getest en rekening houden met de toestand die na de publicatie achterblijft.
Gedeelde gegevens en het naast elkaar bestaan van versies
De database is vaak het meest kwetsbare onderdeel. Als de nieuwe versie onmiddellijk een kolom of indeling vereist die de stabiele versie niet begrijpt, kunnen beide versies niet veilig naast elkaar bestaan. Ontwerp compatibele wijzigingen in een volgorde die de service beschikbaar houdt: bereid eerst compatibele structuren voor, rol vervolgens code uit die ermee kan werken en verwijder later het oude pas wanneer geen enkele versie het meer nodig heeft.
Pas hetzelfde principe toe op caches, sessies, queues en interne API-contracten. Controleer hoe consumers en producers zich tijdens de overgang gedragen en voorkom dat twee versies incompatibele statussen wegschrijven. Als je die compatibiliteit niet kunt garanderen, moet je de migratie mogelijk loskoppelen van de deployment of een andere strategie kiezen.
Procedure en checklist
Een duidelijke operationele cyclus beperkt ad-hocbeslissingen: publiceer de kandidaatversie, controleer of deze gezond is voordat je er verkeer naartoe stuurt, activeer de initiële gebruikerspopulatie, observeer de afgesproken signalen, beslis of je uitbreidt, pauzeert of terugrolt en leg de beslissing vast. Noteer na elke fase de versie, de gebruikerspopulatie, de observatieperiode, de incidenten en de verantwoordelijke.
Controleer voordat je begint het volgende:
- De versies kunnen naast elkaar bestaan en er is voldoende capaciteit om ze te draaien.
- De routing en de rollback ervan zijn getest.
- Gedeelde gegevens en statussen zijn tijdens de overgang compatibel.
- De meetwaarden maken onderscheid tussen versies en hebben een bruikbare baseline.
- Er zijn afspraken over drempelwaarden, verantwoordelijken en stappen voor pauzeren en terugrollen.
- Het team weet welke gevolgen niet automatisch ongedaan kunnen worden gemaakt.
Als aan meerdere van deze voorwaarden niet is voldaan, begin dan met het verbeteren van tests, observability en publicatiebeheer voordat je extra complexiteit toevoegt. Een canarydeployment is een architectuur- en operationele keuze, niet slechts een optie in de pipeline: ze levert waarde op wanneer je ervan kunt leren met echt verkeer en kunt ingrijpen voordat een regressie de hele gebruikerspopulatie bereikt.
