Canary-releases met Actions

Stel je voor dat je een nieuwe functie of update uitbrengt. Wat als er een fout in zit die al je gebruikers treft? Best eng, toch?

Canary-releases helpen dit risico te beperken door wijzigingen eerst geleidelijk uit te rollen naar een kleine groep gebruikers. Het is alsof je een "kanarie in een kolenmijn" stuurt om de lucht te testen voordat alle anderen naar binnen gaan.

Canary-releases bieden verschillende belangrijke voordelen:

• Minder risico: Beperk de impact van problemen tot een kleine gebruikersgroep.
• Feedback uit de praktijk: Verzamel productiegegevens over prestaties en stabiliteit.
• Snel terugdraaien: Als er problemen ontstaan, kun je snel alleen de kleine canary-groep of de volledige service terugdraaien.
• Gecontroleerde blootstelling: Vergroot geleidelijk het aantal gebruikers dat de nieuwe versie ziet naarmate je meer vertrouwen krijgt.

Misschien herinner je je blauw-groene implementaties, waarbij je het verkeer direct omschakelt tussen twee identieke omgevingen.

Canary-releases werken anders. In plaats van een directe omschakeling voeren ze een geleidelijke verschuiving van verkeer uit. Een nieuwe versie draait naast de oude en aanvankelijk ziet slechts een klein percentage gebruikers de nieuwe versie. Zo kun je deze uitvoerig controleren voordat je haar volledig uitrolt.

Dit is de basisstroom voor een canary-release:

1. Nieuwe versie implementeren: Een nieuwe versie van je toepassing wordt geïmplementeerd op een kleine groep servers of instanties, naast de bestaande stabiele versie.
2. Een kleine hoeveelheid verkeer routeren: Een load balancer of servicemesh wordt zo geconfigureerd dat een klein percentage (bijvoorbeeld 5-10%) van het gebruikersverkeer naar de nieuwe versie wordt gestuurd.
3. Controleren: De prestaties, foutpercentages en feedback van gebruikers worden voor de canary-groep nauwlettend gecontroleerd.
4. Promoveren of terugdraaien: Als alles er goed uitziet, wordt het verkeer geleidelijk verhoogd of wordt de nieuwe versie gepromoveerd naar 100%. Als er problemen optreden, wordt de canary teruggedraaid en wordt het verkeer teruggeleid naar de stabiele versie.

GitHub Actions kan het volledige proces van een canaryrelease orkestreren. Het beheert het verkeer niet rechtstreeks (dat is de taak van je infrastructuur), maar activeert wel de stappen:

• Je toepassing bouwen en testen.
• De nieuwe versie implementeren in een canaryomgeving.
• Verkeersverschuivingen starten via API-aanroepen naar je load balancer of servicemesh.
• Wachten op monitoringresultaten of handmatige goedkeuringen.
• De canary promoveren of een rollback activeren.

Een gebruikelijke GitHub Actions-workflow voor een canaryrelease kan er als volgt uitzien:

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

Elke stap zou communiceren met je implementatietools.

Hoewel GitHub Actions de orkestratie uitvoert, vinden de daadwerkelijke besluitvorming en implementatieopdrachten vaak plaats in scripts. Hier volgt een Python-voorbeeld dat de logica van een canaryuitrol simuleert. Stel je voor dat een Action dit script uitvoert:

Effectieve monitoring is cruciaal. Je GitHub Actions-workflow kan op verschillende manieren integreren met monitoringsystemen:

• API-aanroepen: Vraag monitoringtools (bijvoorbeeld Datadog en Prometheus) op naar belangrijke meetwaarden.
• Gezondheidscontroles: Vraag periodiek de health-endpoints van de toepassing op.
• Handmatige poorten: Pauzeer de workflow voor menselijke beoordeling en goedkeuring.
• Tijdgebonden wachttijden: Wacht een bepaalde periode totdat de meetwaarden stabiel zijn.

De workflow gebruikt deze signalen vervolgens om te bepalen of de canary wordt gepromoveerd of een rollback wordt uitgevoerd.

Na de monitoringfase gebruikt GitHub Actions voorwaardelijke logica om de volgende stap te bepalen. Je kunt if-instructies gebruiken in de definities van je taak of stap.

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

Zo wordt automatisch gereageerd op de prestaties van de canary.

In deze les heb je geleerd over canaryreleases, een krachtige implementatiestrategie om nieuwe softwareversies geleidelijk uit te rollen naar een deel van de gebruikers.

• Canaryreleases beperken het risico en leveren feedback uit de praktijk.
• GitHub Actions orkestreert het bouwen, de implementatie naar de canary, de monitoring en de stappen voor voorwaardelijke promotie of rollback.
• Effectieve monitoring en voorwaardelijke logica zijn essentieel voor succesvolle canarypijplijnen.

Met canaryreleases kun je met meer vertrouwen en controle implementeren.