Le déploiement canarien est une technique de développement et de déploiement de logiciels qui consiste à diffuser progressivement de nouvelles fonctionnalités ou des mises à jour à un petit sous-ensemble d’utilisateurs avant de les déployer à l’ensemble de la base d’utilisateurs.
Cette approche consiste à créer une nouvelle version du logiciel et à la déployer auprès d’un petit groupe d’utilisateurs tout en conservant l’ancienne version pour le reste des utilisateurs. L’équipe de développement surveille étroitement la nouvelle version pour s’assurer qu’elle est stable et qu’elle fonctionne comme prévu.
Si tout se passe bien, la nouvelle version est déployée auprès d’un plus grand nombre d’utilisateurs jusqu’à ce qu’elle atteigne l’ensemble de la base d’utilisateurs. De cette manière, l’équipe de projet minimise le risque d’introduire des bogues ou d’autres problèmes qui pourraient affecter tous les utilisateurs en même temps.
L’objectif du déploiement Canary est de réduire le risque d’introduction de nouvelles fonctionnalités auprès d’une large base d’utilisateurs. En déployant progressivement les changements auprès des utilisateurs, les développeurs peuvent contrôler les performances et la stabilité de la nouvelle version. Ils procèdent aux ajustements nécessaires avant de déployer la nouvelle version à l’ensemble des utilisateurs. La transition vers la nouvelle version se fait donc beaucoup plus en douceur.
Principes clés et avantages
Les principes clés du déploiement de Canary sont les suivants :
- Déployez d’abord la nouvelle version auprès d’un petit sous-ensemble d’utilisateurs, puis étendez-la progressivement à un plus grand nombre d’utilisateurs.
- Surveillez étroitement la nouvelle version pour vous assurer qu’elle est stable et qu’elle fonctionne comme prévu.
- En cas de problème, revenez rapidement et facilement à la version précédente.
- Automatisez le processus de déploiement autant que possible pour réduire le risque d’erreur humaine.
Les avantages du déploiement Canary dans le cadre de DevOps sont les suivants :
- En déployant progressivement les changements, vous minimisez le risque d’introduire des bogues ou d’autres problèmes qui pourraient affecter tous les utilisateurs en même temps.
- Les développeurs peuvent recevoir plus rapidement des commentaires sur la nouvelle version, ce qui leur permet d’apporter les ajustements nécessaires avant de la déployer à l’ensemble des utilisateurs.
- En contrôlant les performances et la stabilité de la nouvelle version, les développeurs peuvent s’assurer qu’elle répond aux normes de qualité nécessaires avant de la déployer auprès de l’ensemble des utilisateurs.
- Le déploiement de Canary contribue à accroître la confiance des développeurs et des parties prenantes dans le processus de déploiement, car il réduit le risque d’introduire des problèmes qui pourraient avoir un impact sur l’expérience de l’utilisateur.
Déploiement canarien basé sur le concept et la terminologie
Passons en revue le cycle de vie typique du processus.
Tout commence avec Canary, c’est-à-dire les “premiers utilisateurs” de la nouvelle version du système. Parallèlement, il y a le groupe Baseline. C’est là que se trouvent tous les autres utilisateurs qui ne font pas partie de Canary.
À mesure que les utilisateurs de Canary continuent d’utiliser la nouvelle version, le déploiement de Canary s’étend à un nombre croissant d’utilisateurs. Il s’agit d’un transfert de trafic. Le groupe Canary s’agrandit tandis que le groupe Baseline se réduit, de sorte que le système effectue un déploiement progressif.
En cours de route, le processus de surveillance enregistre toutes les activités et les résultats de l’utilisation et génère des mesures dont les développeurs ont besoin comme retour d’information. Les développeurs réagissent alors et corrigent ce qui est nécessaire. Ou ils reviennent à la ligne de base s’ils ne peuvent pas résoudre les problèmes à ce moment-là.
Automatisez toutes les activités de surveillance et de déploiement. Cela permet aux développeurs de se concentrer exclusivement sur la résolution des problèmes.
Il se peut que le groupe Canary découvre que certaines fonctionnalités de la nouvelle version sont mauvaises alors que d’autres sont excellentes. Les développeurs signaleront donc les fonctionnalités qui posent problème afin de les désactiver des processus de déploiement.
Les développeurs gardent un œil sur les deux groupes simultanément – le groupe canari et le groupe de référence. Les utilisateurs génèrent des résultats de tests A/B. Il s’agit du comportement de l’ancien système et du nouveau système dans les mêmes conditions. En outre, des tests automatiques sont effectués en permanence sur la nouvelle version du système afin de garantir la stabilité du bilan de santé du groupe Canari.
En quoi cela diffère-t-il des stratégies de déploiement traditionnelles ?
Après avoir compris le processus de haut niveau du cycle de vie, les différences entre ce processus et les processus de déploiement traditionnels sont assez évidentes.
- Vous déployez progressivement et avec un meilleur contrôle plutôt que de déployer tout d’un coup pour tout le monde et d’attendre que les problèmes affectent l’ensemble de la production.
- Vous limitez le risque de bogues de la nouvelle version au seul groupe Canary plutôt que d’exposer le monde entier aux problèmes simultanément.
- Vous contrôlez la nouvelle version avant que les utilisateurs ne l’utilisent, plutôt que de la contrôler après coup et d’investir un temps et des ressources considérables dans la phase d’hypercompétence du processus de mise en production.
- Vous pouvez décider d’un retour en arrière bien avant de déployer complètement la nouvelle version en production. D’un autre côté, vous pouvez programmer une autre fenêtre de mise en production pour annuler la production juste après l’achèvement de la mise en production.
- Le déploiement Canary vous oblige naturellement à investir dans des outils et des processus automatisés dans la mesure du possible. D’un autre côté, si vous vous en tenez aux stratégies de déploiement traditionnelles, toutes les initiatives d’automatisation sont naturellement reléguées à la fin de la liste des projets en attente.
Pipelines CI/CD dans le déploiement Canary
Dans un pipeline CI/CD typique, les changements sont automatiquement construits, testés et déployés dans un environnement de mise à disposition pour des tests supplémentaires avant d’être déployés en production. Il s’agit également d’un cas d’utilisation parfait dans le cadre d’un déploiement Canary.
Une fois que les changements ont été déployés dans l’environnement de préparation et ont passé tous les tests nécessaires, le pipeline CI/CD déploie automatiquement la version Canary à un petit sous-ensemble d’utilisateurs dans l’environnement de production.
En cas de problème, il suffit de lancer un autre pipeline pour revenir en arrière. Ou signalez les fonctionnalités problématiques, et elles n’apparaîtront plus jamais dans le processus de déploiement du pipeline de déploiement. Tout est automatique, et vous n’avez plus à vous en préoccuper.
Puisque la version canari est pleine de tests automatisés de contrôle de santé, tous ces éléments sont naturellement incorporés dans les fonctionnalités de base des pipelines CI/CD. Ils sont de toute façon indispensables à tout bon pipeline CI/CD.
Le flux de travail et les phases de déploiement de Canary
En résumant l’information, voici le flux de travail habituel d’un déploiement Canary typique que vous pouvez utiliser sur votre projet.
#1. Planification et préparation
Dans cette phase, l’équipe de développement planifie et prépare le déploiement de Canary. Il s’agit notamment d’identifier les changements ou les mises à jour à effectuer, de créer une nouvelle version du logiciel et de définir les mesures et les contrôles de santé qui seront utilisés pour surveiller les performances de la nouvelle version. L’équipe identifie également le sous-ensemble d’utilisateurs qui recevront la nouvelle version en premier et définit le plan de déploiement.
#2. Mise en œuvre du routage et de la surveillance du trafic
La nouvelle version du logiciel est déployée auprès du sous-ensemble d’utilisateurs identifié lors de la phase de planification. Le routage du trafic est mis en œuvre pour diriger une partie du trafic des utilisateurs vers la nouvelle version tout en laissant l’ancienne version fonctionner pour le reste des utilisateurs. Les performances et la stabilité de la nouvelle version sont étroitement surveillées à l’aide de mesures et de contrôles de santé afin de s’assurer qu’elle fonctionne comme prévu.
#3. Analyse et évaluation des performances du déploiement
Les performances de la nouvelle version sont analysées et évaluées sur la base des mesures et des contrôles de santé définis lors de la phase de planification. Si la nouvelle version fonctionne bien, le déploiement est progressivement étendu à un plus grand nombre d’utilisateurs. En cas de problème avec la nouvelle version, le déploiement peut être ramené rapidement à la version précédente.
#4. Promouvoir ou annuler le déploiement
L’équipe de développement décide de promouvoir la nouvelle version auprès de l’ensemble des utilisateurs ou de revenir à la version précédente. Si la nouvelle version fonctionne bien et répond aux normes de qualité nécessaires, il convient de la promouvoir auprès de l’ensemble des utilisateurs. En cas de problème avec la nouvelle version, revenez rapidement et facilement à la version précédente.
Meilleures pratiques et stratégies
Lors de la mise en œuvre de Canary Deployment dans votre plateforme, commencez par définir des objectifs clairs et ce à quoi ressemble le succès à la fin. Vous pouvez vous aider d’éléments tels que les mesures de performance, les critères de retour d’information des utilisateurs et l’impact sur l’entreprise.
Créez un petit sous-ensemble d’utilisateurs pour tester la nouvelle version (Canary) du logiciel. Le groupe plus important du début n’est pas vraiment un avantage. Vous devez être aussi flexible que possible, surtout au début.
Comme nous l’avons déjà mentionné à plusieurs reprises, surveillez les performances et la stabilité de la nouvelle version à l’aide de mesures et de bilans de santé. Réagissez dès que vous voyez quelque chose de suspect. Il vaut mieux sur-réagir que sous-réagir lors d’un déploiement progressif.
Augmentez progressivement le nombre d’utilisateurs de la nouvelle version. Cela permet d’assurer une transition en douceur vers la nouvelle version.
Utilisez des outils et des processus d’automatisation dans la mesure du possible pour rationaliser le processus de déploiement et de surveillance. Intégrez-les dans les pipelines CI/CD et faites-en des processus de déploiement programmés déclenchés automatiquement. Cela réduit le risque d’erreur humaine et garantit que le processus de déploiement est cohérent et reproductible.
Mettez en œuvre des indicateurs de fonctionnalités pour activer ou désactiver des fonctionnalités spécifiques du logiciel. Vous pourrez ainsi contrôler les processus de déploiement futurs sans avoir à les modifier ou à les mettre à jour manuellement. Vous permettrez aux développeurs de se concentrer davantage sur les aspects les plus importants, à savoir la correction des bogues.
Utilisez les tests A/B pour comparer les performances de deux versions différentes du logiciel. Affectez des utilisateurs aléatoires à l’une ou l’autre version. Identifiez la version la plus performante et réagissez en fonction des décisions de développement futures.
Veillez à pouvoir annuler le déploiement rapidement et à tout moment en cas de problème avec la nouvelle version. Cela réduira l’impact des problèmes et permettra une reprise rapide.
Défis et études de cas
Malgré ses avantages évidents, le déploiement Canary présente encore quelques difficultés.
L’un d’entre eux est la latence du réseau, qui peut avoir un impact sur les performances de la nouvelle version du logiciel. Pour résoudre ce problème, les développeurs peuvent utiliser des outils tels que des équilibreurs de charge et des réseaux de diffusion de contenu pour améliorer les performances du réseau. Il ne s’agit pas seulement de la latence pour le système en cas d’utilisation externe. Il s’agit également de la latence pour les processus internes tels que les déploiements ou les exécutions de pipelines CI/CD. Ceux-ci doivent se dérouler le plus rapidement possible. Sinon, vous aurez une ligne de développeurs dans un état d’inactivité en attendant que les pipelines terminent leur exécution.
Un autre défi consiste à assurer la cohérence des données entre l’ancienne et la nouvelle version du logiciel. Pour relever ce défi, les développeurs peuvent utiliser des techniques telles que la réplication et la synchronisation des bases de données pour s’assurer que les données sont cohérentes dans toutes les versions. Le fait que les utilisateurs de la production travaillent à la fois avec l’ancienne et la nouvelle version augmente les attentes en ce qui concerne la synchronisation totale des deux versions et le fait que les utilisateurs ne perdent pas de données de production simplement parce qu’ils font partie du groupe Canary/Baseline. Il peut s’agir d’une attente très difficile à satisfaire, alors appuyez-vous sur des processus de base solides.
Netflix est un exemple bien connu d’entreprise qui utilise Canary Deployment pour déployer les changements apportés à son service de streaming. L’entreprise utilise une combinaison de tests automatisés, d’indicateurs de fonctionnalités et de tests A/B pour déployer lentement les changements.
Google est un autre exemple d’entreprise qui utilise Canary Deployment pour apporter des modifications à ses services en nuage. De la même manière, l’entreprise utilise les avantages des tests automatisés, de la division du trafic et de l’inclusion de la surveillance pour déployer progressivement les changements auprès d’un petit sous-ensemble d’utilisateurs avant de les déployer auprès de tous les utilisateurs. Cette approche a permis à Google d’améliorer la qualité et la stabilité de ses services.
Le mot de la fin
Comme tous les processus, approches ou stratégies, le déploiement Canary n’est pas une solution à tous les problèmes du monde. Dans certains cas, il est presque impossible à mettre en œuvre en raison de restrictions environnementales, des connaissances des personnes ou d’un manque général de compréhension conceptuelle. I
l est beaucoup plus adapté aux projets de la nouvelle ère. Là où un état d’esprit agile est la propriété de base solide comme le roc, l’automatisation de chaque processus est une priorité incontestable, et un niveau maximal de fiabilité est une attente forte de la part des parties prenantes.
Dans ce cas, le déploiement Canary est en quelque sorte le niveau suivant des pratiques de développement agile. Il peut élever les équipes dans un territoire où le projet n’a jamais été auparavant.
Prochainement, consultez la section sur la mise à l’échelle et l’optimisation de la CI/CD.