Mises en production progressives avec Actions

Imaginez que vous lanciez une nouvelle fonctionnalité ou une mise à jour. Que se passerait-il si elle contenait un bogue qui affectait tous vos utilisateurs ? Cela fait peur, n’est-ce pas ?

Les mises en production Canary contribuent à réduire ce risque en déployant progressivement les modifications auprès d’un petit sous-ensemble d’utilisateurs. C’est comme envoyer un « canari dans une mine de charbon » pour tester l’air avant que les autres n’y entrent.

Les mises en production Canary offrent plusieurs avantages importants :

• Risque réduit : limitez l’impact des problèmes à un petit groupe d’utilisateurs.
• Retour d’expérience en conditions réelles : obtenez des données de production sur les performances et la stabilité.
• Restauration rapide : en cas de problème, restaurez rapidement le petit groupe Canary ou l’ensemble du service.
• Exposition contrôlée : augmentez progressivement l’exposition des utilisateurs à mesure que la confiance s’installe.

Vous vous souvenez peut-être des déploiements Blue/Green, dans lesquels le trafic bascule instantanément entre deux environnements identiques.

Les mises en production Canary sont différentes. Au lieu d’une bascule instantanée, elles impliquent un transfert progressif du trafic. Une nouvelle version s’exécute en parallèle de l’ancienne, et seul un faible pourcentage des utilisateurs voit initialement la nouvelle version. Cela permet une surveillance détaillée avant le déploiement généralisé.

Voici le déroulement de base d’une mise en production Canary :

1. Déployer la nouvelle version : une nouvelle version de votre application est déployée sur un petit ensemble de serveurs ou d’instances, en parallèle de la version stable existante.
2. Diriger une petite partie du trafic : un répartiteur de charge ou un maillage de services est configuré pour envoyer un faible pourcentage (par exemple, 5 à 10 %) du trafic des utilisateurs vers la nouvelle version.
3. Surveiller : les performances, les taux d’erreur et les retours des utilisateurs du groupe Canary sont surveillés attentivement.
4. Promouvoir ou restaurer : si tout semble correct, le trafic est augmenté progressivement, ou la nouvelle version est déployée auprès de 100 % des utilisateurs. En cas de problème, la version Canary est restaurée et le trafic est redirigé vers la version stable.

GitHub Actions peut orchestrer l'ensemble du processus de mise en production canary. Il ne gère pas directement le trafic — c'est le rôle de votre infrastructure —, mais il déclenche les étapes suivantes :

• Compiler et tester votre application.
• Déployer la nouvelle version dans un environnement canary.
• Déclencher les changements de répartition du trafic via des appels d'API à votre répartiteur de charge ou à votre maillage de services.
• Attendre les résultats de la surveillance ou les validations manuelles.
• Promouvoir la version canary ou déclencher une restauration.

Un flux de travail GitHub Actions classique pour une mise en production canary pourrait ressembler à ceci :

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

Chaque étape interagirait avec vos outils de déploiement.

GitHub Actions orchestre le processus, mais les décisions et les commandes de déploiement sont souvent exécutées dans des scripts. Voici un exemple en Python qui simule la logique d'un déploiement canary. Imaginez qu'une Action exécute ce script :

Une surveillance efficace est essentielle. Votre flux de travail GitHub Actions peut s'intégrer aux systèmes de surveillance de plusieurs façons :

• Appels d'API : Interroger les outils de surveillance (par exemple, Datadog et Prometheus) pour obtenir les indicateurs clés.
• Contrôles d'état : Interroger régulièrement les points de terminaison d'état de l'application.
• Étapes de validation manuelle : Mettre le flux de travail en pause pour permettre une vérification et une validation humaines.
• Attentes temporisées : Attendre une durée définie afin que les indicateurs se stabilisent.

Le flux de travail utilise ensuite ces signaux pour décider de promouvoir la version ou d'effectuer une restauration.

Après la phase de surveillance, GitHub Actions utilise une logique conditionnelle pour décider de l'étape suivante. Vous pouvez utiliser des instructions if dans les définitions de vos tâches ou de vos étapes.

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

Cela garantit une réaction automatique aux performances de la version canary.

Vous avez découvert les avantages et le fonctionnement des mises en production canary. Vérifions maintenant votre compréhension.

Dans cette leçon, vous avez découvert les mises en production canary, une stratégie de déploiement puissante qui consiste à déployer progressivement de nouvelles versions logicielles auprès d'une partie des utilisateurs.

• Les mises en production canary réduisent les risques et fournissent des retours en conditions réelles.
• GitHub Actions orchestre la compilation, le déploiement vers l'environnement canary, la surveillance et les étapes conditionnelles de promotion ou de restauration.
• Une surveillance efficace et une logique conditionnelle sont essentielles à la réussite des flux de mise en production canary.

Grâce aux versions canary, vous pouvez déployer avec davantage de confiance et de contrôle !