Une sorte de test A/B lorsque B est un repli

Question

En fait, un meilleur terme peut exister pour ce dont j'ai besoin, mais je ne suis pas au courant et je serais reconnaissant à quiconque en suggère un et/ou édite le sujet de la question de manière appropriée.

Envisagez d'utiliser le service Web API S qui est déployé sur le serveur de production. Traitons cela comme une source de vérité. Puis, par exemple, j'ai besoin de mettre à jour certaines dépendances externes ou de modifier le code de l'infrastructure sans affecter directement la logique métier principale ni le contrat public du service.

Ainsi, je reçois S_updated qui doit passer la phase de mise en scène et ensuite seulement être déployé en production. En raison du genre de changements apportés à la base de code, je m'attendrais à ce que ce service fonctionne comme la version précédente ou ne fonctionne pas du tout en raison de problèmes d'intégration. Il y a toujours un risque de changer le comportement du système, mais je peux vivre avec et je m'attends à ce que les tests unitaires soient un bon filet de sécurité. Ceci est également prouvé par la pratique. Ce que je veux réellement, c'est pouvoir déployer S_updated en production et avoir un service de proxy envoyant tout ou partie (dépend de la configuration) des demandes échouées à l'ancien service S.

Existe-t-il des solutions génériques configurables pour une telle fonctionnalité?

Answer 1

Le commentaire de Paolo est correct. Vous demandez Canary release process.

Lorsqu'il est déployé, un client aura de grandes chances d'atteindre l'ancien service et une petite chance d'accéder au nouveau service. Ainsi, si un appel échoue (en raison d'une erreur dans le nouveau service), le client peut répéter l'appel et avoir de grandes chances de succès en accédant à l'ancien service.

Comment faire cela dépend de l'infrastructure que vous utilisez. Par exemple, si vous utilisiez des clusters kubernetes, vous configureriez votre équilibreur de charge frontal pour que le service n'envoie qu'une fraction du trafic vers un deuxième cluster (ou un deuxième service, s'il est exécuté sur le même cluster). exécuter la nouvelle version du service. Un autre exemple serait que si vous utilisez une solution d'équilibrage de charge basée sur le DNS, vous devrez changer la politique DNS en un mode pondéré qui envoie une fraction du trafic vers le (s) serveur (s) avec le nouveau service.