Rilasci Canary con Actions

Immagini di lanciare una nuova funzionalità o un aggiornamento. E se contenesse un bug che riguardasse tutti gli utenti? Fa paura, vero?

I rilasci Canary aiutano a ridurre questo rischio distribuendo gradualmente le modifiche, inizialmente a un piccolo sottoinsieme di utenti. È come mandare un «canarino in miniera» per testare l'aria prima che entrino tutti gli altri.

I rilasci Canary offrono diversi vantaggi fondamentali:

• Rischio ridotto: limitano l'impatto dei problemi a un piccolo gruppo di utenti.
• Feedback dal mondo reale: forniscono dati di produzione su prestazioni e stabilità.
• Rollback rapido: se si verificano problemi, è possibile ripristinare rapidamente solo il piccolo gruppo Canary o l'intero servizio.
• Esposizione controllata: aumentano gradualmente il numero di utenti coinvolti man mano che cresce la fiducia.

Forse ricorda le distribuzioni Blue/Green, in cui il traffico viene spostato istantaneamente tra due ambienti identici.

I rilasci Canary sono diversi. Invece di uno spostamento istantaneo, prevedono un passaggio graduale del traffico. La nuova versione viene eseguita insieme a quella precedente e inizialmente solo una piccola percentuale di utenti vede la nuova versione. Ciò consente un monitoraggio dettagliato prima del rilascio completo.

Ecco il flusso di base di un rilascio Canary:

1. Distribuzione della nuova versione: una nuova versione dell'applicazione viene distribuita su un piccolo insieme di server o istanze, insieme alla versione stabile esistente.
2. Instradamento di una piccola quota di traffico: un load balancer o una service mesh viene configurato per inviare una piccola percentuale (ad esempio, il 5-10%) del traffico degli utenti alla nuova versione.
3. Monitoraggio: le prestazioni, i tassi di errore e il feedback degli utenti vengono monitorati attentamente per il gruppo Canary.
4. Promozione o rollback: se tutto procede bene, il traffico viene aumentato gradualmente oppure la nuova versione viene promossa al 100%. Se si verificano problemi, si esegue il rollback della versione Canary e si reindirizza il traffico alla versione stabile.

GitHub Actions può orchestrare l'intero processo di rilascio canary. Non gestisce direttamente il traffico (questo è compito della vostra infrastruttura), ma attiva i vari passaggi:

• Creazione e test dell'applicazione.
• Distribuzione della nuova versione in un ambiente canary.
• Avvio dello spostamento del traffico tramite chiamate API al bilanciatore del carico o alla service mesh.
• Attesa dei risultati del monitoraggio o delle approvazioni manuali.
• Promozione del canary o avvio di un rollback.

Un workflow tipico di GitHub Actions per un rilascio canary potrebbe essere simile al seguente:

name: Canary Deployment

on: push

jobs:
  build:
    # ... build and test steps ...

  deploy-canary:
    needs: build
    steps:
      - name: Deploy to Canary Group
        # ... call script/tool to deploy and shift 10% traffic ...

  monitor-canary:
    needs: deploy-canary
    # ... wait for monitoring/approval ...

  promote-or-rollback:
    needs: monitor-canary
    # ... conditionally promote to 100% or rollback ...

Ogni passaggio interagirebbe con i vostri strumenti di distribuzione.

Sebbene GitHub Actions svolga il ruolo di orchestratore, le decisioni effettive e i comandi di distribuzione vengono spesso eseguiti all'interno di script. Ecco un esempio in Python che simula la logica di un rollout canary. Immaginate un'Action che esegue questo script:

Un monitoraggio efficace è fondamentale. Il vostro workflow di GitHub Actions può integrarsi con i sistemi di monitoraggio in diversi modi:

• Chiamate API: interrogare gli strumenti di monitoraggio (ad esempio Datadog e Prometheus) per ottenere le metriche principali.
• Controlli di integrità: interrogare periodicamente gli endpoint di health check dell'applicazione.
• Gate manuali: mettere in pausa il workflow per consentire la revisione e l'approvazione da parte di una persona.
• Attese basate sul tempo: attendere un periodo stabilito affinché le metriche si stabilizzino.

Il workflow utilizza quindi questi segnali per decidere se promuovere il canary o eseguire un rollback.

Al termine della fase di monitoraggio, GitHub Actions utilizza una logica condizionale per decidere il passaggio successivo. È possibile usare istruzioni if nelle definizioni dei job o dei passaggi.

  promote-or-rollback:
    needs: monitor-canary
    if: success() && needs.monitor-canary.outputs.canary_ok == 'true'
    steps:
      - name: Promote Full Rollout
        # ... command to shift 100% traffic to new version ...

  rollback:
    needs: monitor-canary
    if: failure() || needs.monitor-canary.outputs.canary_ok == 'false'
    steps:
      - name: Rollback to Stable
        # ... command to shift 100% traffic to old version ...

In questo modo si garantisce una reazione automatica alle prestazioni del canary.

Avete appreso i vantaggi e il funzionamento dei rilasci canary. Verifichiamo la vostra comprensione.

In questa lezione avete appreso i rilasci canary, una strategia di distribuzione efficace per distribuire gradualmente nuove versioni del software a un sottoinsieme di utenti.

• I rilasci canary riducono al minimo i rischi e forniscono feedback dal mondo reale.
• GitHub Actions orchestra la compilazione, la distribuzione nel canary, il monitoraggio e i passaggi di promozione o rollback condizionali.
• Un monitoraggio efficace e una logica condizionale sono fondamentali per pipeline canary di successo.

Utilizzando i canary, potete distribuire con maggiore sicurezza e controllo.