En phase de test logiciel, les DevOps ont souvent besoin de plusieurs versions pour identifier les bugs et apporter les corrections nécessaires. Mais selon le budget, les besoins ou simplement les outils disponibles, la stratégie de déploiement varie. Dans cet article, nous nous intéressons particulièrement au Canary release.
Alors de quoi s’agit-il ? Quelles sont les autres méthodes ? Comment cela fonctionne-t-il ? Quels sont les avantages et inconvénients de Canary pour les DevOps ? Nous répondons à toutes vos questions.
Qu'est ce que le déploiement Canary ?
Si le déploiement continu est l’un des principes fondateurs du mouvement DevOps, il nécessite toujours une phase de test avant la mise en production du logiciel ou de l’application.
C’est justement pour optimiser cette phase de test que la méthode Canary DevOps a été développée. L’idée est alors de déployer les modifications de manière progressive à un nombre restreint d’utilisateurs. Il est donc plus facile de savoir si les modifications implémentées produisent le résultat escompté.
À travers cette approche plus prudente, le risque est réduit et la mise en production est plus rapide.
Bon à savoir : les utilisateurs ayant accès aux modifications sont appelés les canaris. Ce nom est utilisé en référence aux oiseaux qui avertissaient les mineurs en cas de dangerosité de la concentration de gaz toxiques dans les mines. Ici, les canaris avertissent les DevOps en cas de bugs sur l’application ou le logiciel.
Quels sont les autres modèles de déploiement ?
Le Canary release n’est pas le seul modèle de déploiement disponible. Voici deux autres méthodes très populaires :
- Déploiement progressif (ou Rolling) : comme pour le Canary release, il s’agit d’échelonner les modifications. Mais ici, les modifications sont implémentées sur des serveurs ou instances. À l’inverse, avec le déploiement Canary DevOps, les nouvelles fonctionnalités sont directement mises à disposition de certains utilisateurs.
- Déploiement Blue/Green : deux infrastructures d’hébergement sont programmées. L’une héberge la version de production de l’application (Blue), alors que l’autre est mise en réserve (Green). Cette dernière permet de déployer la nouvelle version et de réaliser différents tests. Lorsque toutes les fonctionnalités sont validées, la mise à jour est déployée au sein de l’infrastructure Blue.
Dans les deux cas, les organisations doivent disposer d’une infrastructure informatique relativement importante pour héberger les deux versions d’une application. Ce qui n’est pas le cas avec l’approche Canary DevOps.
Comment fonctionne Canary release ?
Le déploiement Canary DevOps consiste à échelonner les modifications, de sorte qu’un nombre limité d’utilisateurs ait accès à la nouvelle version. Les autres continueront d’utiliser la version précédente, jusqu’à ce que les modifications soient acceptées.
En cas d’erreur ou de bugs, les DevOps redirigent le trafic vers l’ancienne version afin de corriger les éventuelles failles. Dès lors que les modifications sont validées, elles sont déployées à l’ensemble de l’environnement pour tous les utilisateurs.
Pour que cette méthode fonctionne, il est primordial de bien sélectionner les canaris. Il doit s’agir d’utilisateurs qui soient à la fois tolérants aux bugs, tout en étant capables de les déceler. La tolérance permet de réduire le taux d’insatisfaction et la capacité de détection permet d’améliorer le produit grâce aux retours d’expérience.
C’est d’ailleurs pour cette raison que le Canary release est souvent déployé en interne avant d’être rendu public auprès du plus grand nombre. Mais il est aussi possible de créer des groupes d’utilisateurs opt-in, qui souhaitent recevoir les mises à jour avant tout le monde.
Quelle que soit leur fonction, les canaris ne savent pas toujours qu’ils sont utilisés en tant que signal d’alerte précoce.
Quels sont les avantages du déploiement Canary pour les DevOps ?
Les retours d’expérience
En mettant à disposition une partie des modifications auprès d’un petit échantillon d’utilisateurs, il est plus facile d’avoir des retours d’expérience. Ce sont ces feedbacks qui permettent d’améliorer le logiciel ou l’application en continu.
La réduction des risques
Si certains bugs sont identifiés en phase de test, les utilisateurs les subissant sont peu nombreux. Ce qui permet de maintenir un excellent niveau de satisfaction.
En outre, les modifications sont plus facilement réversibles que si elles étaient diffusées à une large partie des utilisateurs.
Dans tous les cas, le risque lié au déploiement est grandement réduit grâce au Canary Devops.
L’absence d’infrastructure propre
Contrairement aux méthodes de déploiement Blue/Green et progressif, il n’est pas nécessaire de prévoir deux infrastructures (une pour le test et une autre pour le déploiement total). En effet, le test Canary n’est pas réalisé sur un autre serveur ou une autre instance, mais auprès d’un groupe spécifique d’utilisateurs.
À ce titre, le déploiement Canary DevOps est particulièrement utile pour les entreprises qui ne disposent pas de moyens financiers faramineux.
Quels sont les inconvénients de Canary Release ?
Malgré tous les bénéfices de Canary pour un déploiement DevOps, il convient d’avoir conscience des faiblesses de cette méthode. En effet, même si les utilisateurs restreints peuvent apporter leurs retours, il y a parfois des bugs qui passent à la trappe. Alors avant la mise en production à l’ensemble de l’environnement, il est primordial de vérifier à nouveau d’éventuels dysfonctionnements.
Ce qu’il faut retenir
- La méthode Canary DevOps permet de déployer de nouvelles fonctionnalités de manière progressive à un nombre restreint d’utilisateurs.
- À la différence des modèles de déploiement Rolling et Blue/Green, Canary release ne nécessite pas d’infrastructure supplémentaire.
- Le déploiement Canary permet aux organisations de réduire les risques, d’accélérer la mise en production, et tout ça, à moindre coût.
