Stratégie de libération de Canary vs Bleu / Vert

Ma compréhension d'une version Canary est qu'il s'agit d'une version partielle d'un sous-ensemble de nœuds de production avec des sessions persistantes activées. De cette façon, vous pouvez contrôler et minimiser le nombre d'utilisateurs / clients qui sont touchés si vous finissez par publier un mauvais bogue.

Ma compréhension d'une version bleue / verte est que vous avez 2 environnements de production en miroir ("bleu" et "vert"), et que vous transmettez les modifications à tous les nœuds bleus ou verts à la fois, puis utilisez la magie du réseau pour contrôler vers quel environnement les utilisateurs sont acheminés via DNS.

Donc, avant de commencer, si quelque chose que j'ai dit jusqu'à présent est incorrect, veuillez commencer par me corriger!

En supposant que je suis plus ou moins sur la bonne voie, alors quelques questions sur les deux stratégies:

• Existe-t-il des scénarios où le canari est préféré au bleu / vert et vice versa?
• Existe-t-il des scénarios dans lesquels un modèle de déploiement peut mettre en œuvre les deux stratégies en même temps?

La libération bleu-vert est plus simple et plus rapide.

Vous pouvez faire une version bleu-vert si vous avez testé la nouvelle version dans un environnement de test et êtes très certain que la nouvelle version fonctionnera correctement en production. Toujours utiliser les bascules de fonctionnalités est un bon moyen d'augmenter votre confiance dans une nouvelle version, car la nouvelle version fonctionne exactement comme l'ancienne jusqu'à ce que quelqu'un bascule une fonctionnalité. Diviser votre application en petits services pouvant être libérés indépendamment en est une autre, car il y a moins à tester et moins à casser.

Vous devez faire une version Canary si vous n'êtes pas complètement certain que la nouvelle version fonctionnera correctement en production. Même si vous êtes un testeur approfondi, Internet est un endroit vaste et complexe et présente toujours des défis inattendus. Même si vous utilisez des bascules de fonctionnalités, il se peut que l'une d'entre elles soit implémentée de manière incorrecte.

L'automatisation du déploiement demande des efforts, de sorte que la plupart des organisations prévoient d'utiliser une stratégie ou une autre à chaque fois.

Faites donc un déploiement bleu-vert si vous vous engagez à adopter des pratiques qui vous permettent d'être confiant. Sinon, envoyez le canari.

L'essence du bleu-vert se déploie en même temps et l'essence du déploiement de Canary se déploie progressivement, donc étant donné un seul groupe d'utilisateurs, je ne peux pas penser à un processus que je décrirais comme faisant les deux en même temps. Si vous disposez de plusieurs pools d'utilisateurs indépendants, par exemple en utilisant différents centres de données régionaux, vous pouvez utiliser le bleu-vert dans chaque centre de données et le canari entre les centres de données. Bien que si vous n'aviez pas besoin d'un déploiement Canary dans un centre de données, vous n'en auriez probablement pas besoin dans les centres de données.

J'ai écrit un essai détaillé sur ce sujet ici: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

À mon avis, la différence est de savoir si la nouvelle version «verte» est exposée ou non à de vrais utilisateurs. Si c'est le cas, je l'appellerais Canary. Un moyen courant d'implémenter Canary est le bleu / vert régulier avec l'ajout d'un routage intelligent d'utilisateurs spécifiques à la nouvelle version. Lisez l'article pour une comparaison détaillée

Bleu vert:

Canari:

Bien que ces deux termes semblent assez proches l'un de l'autre, ils présentent des différences subtiles. L'un fait confiance à votre version de fonctionnalité et l'autre met la confiance dans la façon dont vous la publiez.

Canari

1. La version Canary est une technique permettant de réduire le risque d'introduire une nouvelle version logicielle en production en déployant lentement le changement vers un petit sous-ensemble d'utilisateurs avant de le déployer sur l'ensemble de l'infrastructure.

2. Il est sur le point d'avoir une idée des performances de la nouvelle version (intégration avec d'autres applications, CPU, mémoire, utilisation du disque, etc.).

Bleu vert:

1. Il s'agit davantage de la version prévisible sans déploiement de temps d'arrêt.
2. Annulations faciles en cas d'échec.
3. Processus de déploiement entièrement automatisé

Voici quelques définitions en ligne -

• Déploiement bleu-vert - Lors du déploiement d'une nouvelle version d'une application, un deuxième environnement est créé. Une fois le nouvel environnement testé, il prend le relais de l'ancienne version. L'ancien environnement peut alors être désactivé.

   

• Test A / B - Deux versions d'une application sont en cours d'exécution en même temps. Une partie des demandes est adressée à chacun. Les développeurs peuvent ensuite comparer les versions.  
• Version Canary - Une nouvelle version d'un microservice est démarrée avec les anciennes versions. Cette nouvelle version peut alors prendre une partie des demandes et l'équipe peut tester comment cette nouvelle version interagit avec le système global.

Un bon début de définitions. Je pense que cela aide également à prendre une décision pour votre stratégie si vous divisez votre définition de «publication» en «déployer» et «version (fonctionnalité)».

Déployer (binaires)

L'action du déploiement binaire de votre produit dans un système (de production).

Libération (fonctionnalité)

L'action de gestion de la disponibilité des fonctionnalités pour (groupes d'utilisateurs).

Pourquoi? Vous avez généralement (plusieurs) deux préoccupations lors de la «publication»: 1) Bogues / rétrocompatibilité / etc 2) Vérification de la validité / de l'utilisabilité des nouvelles fonctionnalités

Ensuite, demandez-vous, avant de choisir une stratégie Canari ou Bleu / vert ou toute autre stratégie en mode gris / mixte: quelle (s) préoccupation (s) avons-nous lors de la sortie / déploiement de la nouvelle version? Et alors seulement si vous connaissez vos préoccupations, choisissez votre stratégie.

De plus, il est possible de mettre en place des stratégies de déploiement / lancement plus complexes. Par exemple, dans certains clouds / infra, il est possible d'avoir plusieurs serveurs de production, de relayer la charge dans des proportions différentes vers différents serveurs et versions de votre produit, et de surveiller la solidité avant de mettre à l'échelle une version / déployer à tous les utilisateurs.

Marquage des fonctionnalités

L'action de "configurer" (à froid, voire à chaud) quelle fonctionnalité est (non) disponible pour quel (groupe) d'utilisateurs

Si vous faites également quelque chose comme «marquage des fonctionnalités», vous pouvez commencer par déployer, mesurer la solidité de votre version dans la perspective de la compatibilité descendante / bogue, et publier de nouvelles fonctionnalités progressivement pour différents utilisateurs, ou vice versa (réduire ou même restaurer les fonctionnalités et / ou les binaires ). Le marquage des fonctionnalités permet de séparer la disponibilité des fonctionnalités du déploiement des binaires, et donne une prise de décision beaucoup plus fine que "déployer / revenir en arrière"