Un deploy canary in PHP consente di esporre una nuova versione a una parte controllata del traffico e valutarne il comportamento prima di estenderne l'esposizione. Il suo valore non consiste nel sostituire i test né nel garantire che una modifica sia sicura: offre un modo per rilevare problemi in produzione con un impatto inizialmente limitato e criteri decisionali espliciti.
Per funzionare, le versioni devono poter coesistere, il traffico deve essere instradato in modo controllato e il team deve poter osservare risultati confrontabili. Se l'infrastruttura non consente queste condizioni, una pubblicazione graduale più semplice o una finestra di manutenzione pianificata con cura possono essere scelte più sensate.
Quale rischio controlla un deploy canary
I test automatizzati e gli ambienti pre-produzione aiutano a individuare i difetti, ma non riproducono necessariamente la distribuzione reale di clienti, dati, integrazioni e carico. Un canary mette alla prova una versione con richieste reali, limitando in anticipo la parte della popolazione che può essere interessata.
In pratica, la versione candidata riceve una frazione del traffico, mentre la versione stabile continua a gestire il resto. Il team confronta i segnali di salute di entrambe. Se non ci sono regressioni rilevanti, aumenta l'esposizione; se emergono segnali negativi, interrompe l'estensione e applica la procedura prevista.
Il canary è diverso da un deploy progressivo inteso semplicemente come pubblicazione in più fasi. Nel canary l'attenzione è rivolta alla valutazione di una popolazione e al confronto dei segnali prima di decidere. Non è neppure la stessa cosa di un'attivazione graduale tramite feature flag: questa può nascondere una nuova funzionalità mentre il codice è già stato distribuito, ma non consente necessariamente di confrontare due versioni dell'applicazione.
Quando usarlo e quando scegliere qualcosa di più semplice
Può essere utile quando una modifica ha conseguenze rilevanti, l'applicazione riceve traffico sufficiente per osservare i segnali e l'architettura permette a due versioni di funzionare contemporaneamente. È particolarmente utile se è possibile circoscrivere la popolazione interessata e associare le richieste alla versione che le ha gestite.
Non sempre conviene. Se il traffico è scarso, i risultati possono essere inconcludenti; se il servizio è piccolo e la modifica ha una portata limitata, il costo operativo dell'instradamento e dell'osservabilità può superare i benefici. Inoltre, non è opportuno presentare il canary come una protezione sufficiente contro una migrazione incompatibile o un'operazione irreversibile.
Tra le alternative più semplici ci sono la pubblicazione in una fascia oraria di minore attività, l'uso di un feature flag per controllare una funzionalità specifica o il deploy iniziale in un ambiente interno. Queste opzioni risolvono problemi diversi: una finestra riduce l'esposizione nel tempo, un flag controlla l'attivazione e un ambiente interno consente una convalida preliminare. La scelta dipende dal rischio che si vuole ridurre e dalle funzionalità disponibili.
Requisiti di infrastruttura e operatività
Prima di automatizzare un deploy canary in PHP, verifica che l'infrastruttura possa mantenere in parallelo la versione stabile e quella candidata. Potrebbero servire artefatti di deploy separati, processi PHP e configurazioni compatibili e capacità sufficiente per eseguire entrambe le versioni durante la valutazione.
- Instradamento controllato: un load balancer, un proxy, una piattaforma di container o un altro componente deve poter inviare alla candidata una determinata percentuale di traffico o una popolazione definita. Il meccanismo deve essere reversibile e avere un responsabile operativo.
- Identificazione della versione: log, metriche e trace devono consentire di distinguere quale versione ha gestito ogni richiesta. Senza questa separazione, il confronto può mescolare gli effetti di entrambe.
- Configurazione compatibile: secret, variabili d'ambiente, sessioni, cache e code condivise devono funzionare durante la coesistenza. Non bisogna dare per scontata la compatibilità dei formati o dei contratti tra le versioni.
- Osservabilità utilizzabile: definisci dashboard e alert prima della pubblicazione. Una metrica che nessuno può consultare o interpretare in tempo utile non aiuta a decidere.
Considera anche la persistenza delle sessioni e l'affinità del traffico. Mantenere sempre un utente sulla stessa versione può facilitare il confronto, ma dipende dall'architettura e può distorcere i risultati. In ogni caso, le decisioni di instradamento devono evitare cambiamenti di stato imprevisti tra le versioni.
Scegliere popolazione, fasi e segnali di valutazione
Inizia con una popolazione la cui esposizione puoi spiegare e limitare. Può essere definita in base alla percentuale di richieste o a un segmento controllato, purché la selezione sia coerente e non escluda proprio i casi importanti. Non dare per scontato che una determinata percentuale sia sicura per qualsiasi servizio: la dimensione iniziale dipende dal volume, dall'impatto potenziale e dalla capacità di reazione.
Definisci in anticipo le fasi di estensione e il tempo di osservazione. Ogni fase deve durare abbastanza da consentire di osservare il tipo di utilizzo rilevante; non basta attendere un intervallo arbitrario se il flusso interessato si verifica raramente. Stabilisci chi esamina i dati e chi può interrompere il processo.
Confronta la candidata e la versione stabile usando segnali che consentano di individuare sia i guasti tecnici sia i danni per gli utenti:
- Errori: tassi di risposte non riuscite, eccezioni PHP, errori delle dipendenze e problemi nei processi asincroni associati a ciascuna versione.
- Latenza: tempi di risposta, idealmente suddivisi per route o transazioni importanti, insieme ai segnali di saturazione delle risorse.
- Risultati di business: completamento di un'operazione, pagamenti elaborati o errori in un flusso rilevante, sempre sulla base di definizioni e fonti di dati affidabili.
- Integrità: duplicati, stati incoerenti o divergenze tra sistemi, quando la modifica può influire su dati o processi.
Un miglioramento o una stabilità di una metrica aggregata non escludono un problema concentrato in una route, in un cliente o in una dipendenza. Esamina il contesto e la distribuzione degli errori e, quando possibile, confronta periodi e popolazioni equivalenti.
Stabilire soglie e preparare un rollback
Prima del deploy, concorda quali condizioni consentono di estendere l'esposizione, quali impongono una pausa e quali richiedono un rollback. Le soglie devono tenere conto della baseline e dell'impatto accettabile per il servizio; non esistono valori universali. Per esempio, un aumento degli errori su una route critica può giustificare una pausa anche se la media globale rimane stabile.
Documenta anche la procedura: chi modifica l'instradamento, come viene rimossa la candidata, quali verifiche confermano che la versione stabile riceve di nuovo il traffico e come viene comunicato l'incidente. Sospendere e fare rollback non sono sinonimi: una pausa interrompe l'esposizione o la sua estensione mentre si indaga; un rollback riporta il servizio alla versione precedente secondo una procedura convalidata.
Il rollback del codice non annulla automaticamente le modifiche ai dati, i messaggi già inviati né le operazioni esterne. Per questo, il ripristino rapido deve essere testato come parte del piano e deve tenere conto dello stato che rimane dopo la pubblicazione.
Dati condivisi e coesistenza delle versioni
Il database è spesso il punto più delicato. Se la nuova versione richiede immediatamente una colonna o un formato che quella stabile non comprende, le due versioni non potranno coesistere in sicurezza. Progetta modifiche compatibili secondo una sequenza che permetta di mantenere il servizio: prima prepara strutture compatibili, poi distribuisci codice in grado di utilizzarle e, in seguito, rimuovi ciò che è obsoleto quando nessuna versione ne ha più bisogno.
Applica lo stesso criterio a cache, sessioni, code e contratti delle API interne. Verifica il comportamento di consumer e producer durante la transizione ed evita che due versioni scrivano stati incompatibili. Se non puoi garantire questa compatibilità, potrebbe essere necessario separare la migrazione dal deploy o scegliere una strategia diversa.
Procedura e lista di controllo
Un ciclo operativo chiaro riduce le decisioni improvvisate: pubblica la candidata, verifica che sia integra prima di indirizzarle il traffico, attiva la popolazione iniziale, osserva i segnali concordati, decidi se estendere, sospendere o fare rollback e registra la decisione. Dopo ogni fase, annota la versione, la popolazione, l'intervallo osservato, gli incidenti e il responsabile.
Prima di iniziare, verifica che:
- Le versioni possano coesistere e ci sia capacità sufficiente per gestirle.
- L'instradamento e il relativo rollback siano stati testati.
- I dati e gli stati condivisi siano compatibili durante la transizione.
- Le metriche distinguano le versioni e dispongano di una baseline utile.
- Siano state concordate soglie, responsabilità e procedure di pausa e rollback.
- Il team sappia quali impatti non possono essere annullati automaticamente.
Se mancano diverse di queste condizioni, inizia migliorando i test, l'osservabilità e il controllo della pubblicazione prima di aggiungere complessità. Un deploy canary è una decisione architetturale e operativa, non solo un'opzione della pipeline: è utile quando permette di apprendere dal traffico reale e intervenire prima che una regressione raggiunga l'intera popolazione.
