Qu’est-ce que les modèles de déploiement ?

Un modèle de déploiement est un moyen automatisé de déployer en douceur de nouvelles fonctionnalités d’application pour vos utilisateurs. Un modèle de déploiement approprié vous permet de réduire les temps d’arrêt. Certains modèles vous permettent également de déployer de nouvelles fonctionnalités progressivement. De cette façon, vous pouvez valider de nouvelles fonctionnalités avec des utilisateurs sélectionnés avant de mettre ces fonctionnalités à la disposition de tous.

Dans cette section, vous allez découvrir certains modèles de déploiement courants. Vous découvrirez également comment Azure App Service aidera à implémenter le modèle choisi par l’équipe Tailspin.

Réunion du matin

L’équipe Tailspin se sent bien. Leur pipeline a accéléré leur processus. L’équipe dispose d’un environnement de développement où elle peut intégrer l’application web à une base de données. Tim et Amita sont heureux d’avoir des tests automatisés qui simplifient leurs travaux. En général, ils voient moins de retards et moins de bogues.

Mais il y a, comme toujours, un problème. Nous allons nous joindre à la réunion de l’équipe, où Tim est en train de parler.

Tim: Il est si difficile de garder tout le monde heureux. Irwin pense qu’il faut trop de temps pour publier de nouvelles fonctionnalités. Je ne peux rien faire tant que la gestion n’approuve pas la version et, pour l’instant, il n’y a aucun moyen fluide de déployer les fonctionnalités après qu’elles donnent l’OK. Le processus n’est pas seulement long, mais désordonné. C’est manuel, et il y a un temps d’arrêt. L’ensemble du processus peut prendre cinq jours. Je sais que c’est trop long, mais que dois-je faire ? Peut-être que si je boit plus de café, la solution viendra à moi.

Andy: Le café est essentiel à la résolution efficace des problèmes, sans aucun doute.

Je pense que la solution dont nous avons besoin est un bon modèle de déploiement. Un modèle de déploiement est une moyen automatisé d’effectuer le basculement. Il s’agit de la façon dont nous passons le logiciel de la phase finale de préproduction à la production dynamique.

Choisir le bon modèle vous aidera certainement, comme en minimisant les temps d’arrêt. Un autre avantage d’un modèle de déploiement est qu’il nous donne la possibilité d’exécuter des tests qui devraient vraiment se produire en production.

Andy commence à écrire sur le tableau blanc.

Voici les possibilités que nous devrions envisager :

• Déploiement bleu-vert
• Versions avec contrôle de validité
• Bascules de fonctionnalités
• Lancements sombres
• Tests A/B
• Déploiement de l’exposition progressive

Examinons brièvement chaque modèle.

Déploiements bleus/verts

Un déploiement bleu-vert réduit les risques et les temps d’arrêt en exécutant deux environnements identiques. Ces environnements sont appelés bleu et vert. À tout moment, un seul des environnements est actif. Un déploiement bleu-vert implique généralement un routeur ou un équilibreur de charge qui permet de contrôler le flux de trafic.

Supposons que le bleu est en production. À mesure que nous préparons une nouvelle version, nous effectuons nos derniers tests dans l’environnement vert. Une fois que le logiciel fonctionne dans l’environnement vert, nous allons simplement basculer le routeur afin que toutes les demandes entrantes passent à l’environnement vert.

Le déploiement bleu-vert nous donne également un moyen rapide d’effectuer un retrait. Si quelque chose ne va pas dans l’environnement vert, nous changeons simplement le routeur vers l’environnement bleu.

Versions avec contrôle de validité

Une version canary est un moyen d’identifier les problèmes potentiels au début sans exposer tous les utilisateurs au problème. L’idée est que nous exposons une nouvelle fonctionnalité à un petit sous-ensemble d’utilisateurs avant de le rendre disponible pour tout le monde.

Dans une version avec contrôle de validité, nous supervisons ce qui se passe au moment de la mise en production de la fonctionnalité. Si la version présente des problèmes, nous appliquons un correctif. Une fois la version canary jugée stable, nous la transférons vers l’environnement de production réel.

Bascules de fonctionnalités

Utilisez les bascules de fonctionnalité pour « activer ou désactiver une fonctionnalité » au moment de l’exécution. Nous pouvons déployer de nouveaux logiciels sans exposer d’autres fonctionnalités nouvelles ou modifiées à nos utilisateurs.

Dans ce modèle de déploiement, Mara et moi développons de nouvelles fonctionnalités derrière un commutateur. Lorsqu’une version se produit, la fonctionnalité est « désactivée » afin qu’elle n’affecte pas le logiciel de production. Selon la façon dont nous configurons la bascule, nous pouvons actionner le commutateur et exposer la fonctionnalité comme nous le souhaitons.

Par exemple, nous pourrions d’abord exposer la fonctionnalité à quelques utilisateurs pour voir comment ils réagissent. Cet exemple aléatoire d’utilisateurs voit la fonctionnalité. Ou nous pourrions simplement mettre la fonctionnalité en ligne pour tout le monde.

Mais ce modèle de déploiement peut profiter à Mara et moi plus que n’importe qui d’autre. Un avantage majeur du modèle de commutation de fonctionnalités est qu’il nous aide à éviter trop de branlement. La fusion de branches peut être douloureuse.

Lancements sombres

Un lancement sombre est un lancement similaire à une mise en production avec contrôle de validité ou à une bascule de fonctionnalité. Au lieu d’exposer une nouvelle fonctionnalité à tous, dans un lancement sombre, nous publions la fonctionnalité sur un petit ensemble d’utilisateurs.

Ces utilisateurs ne savent pas qu’ils testent la fonctionnalité pour nous. Nous ne mettons même pas en évidence la nouvelle fonctionnalité pour eux. C’est pour ça qu’on appelle un lancement sombre. Le logiciel est progressivement ou discrètement publié pour les utilisateurs afin que nous puissions obtenir des commentaires et tester les performances.

Tests A/B

Les tests A/B comparent deux versions d’une page web ou d’une application pour déterminer celle qui s’effectue mieux. Les tests A/B ressemblent à une expérience classique.

Dans les tests A/B, nous affichons de façon aléatoire deux ou plusieurs variantes d’une page. Ensuite, nous utilisons l’analyse statistique pour déterminer quelle variation fonctionne mieux pour nos objectifs.

Déploiement de l’exposition progressive

Le déploiement progressif d’exposition est parfois appelé déploiement en anneau. Il s’agit d’une autre façon de limiter la façon dont les modifications affectent les utilisateurs tout en s’assurant que ces modifications sont valides dans un environnement de production.

Les anneaux sont essentiellement une extension de la phase du contrôle de validité. La mise en production avec contrôle de validité proprement dite est une phase permettant de mesurer les effets. L’ajout d’un autre anneau est essentiellement la même idée.

Dans un déploiement en anneau, nous déployons d’abord les modifications apportées aux clients tolérants aux risques. Nous étendons ensuite progressivement le déploiement à un plus grand nombre de clients.

Implémentation du déploiement bleu-vert

Andy regarde Tim.

Andy: C’est beaucoup, je sais. Voulez-vous prendre un certain temps pour y réfléchir ? Ou vous et moi pourrions ...

Tim: Bleu-vert.

Tout le monde dans la salle rit.

Mara: C’est le café qui parle ?

Tim: Les commutateurs de fonctionnalités impliquent un changement dans comment vous et Andy travaillez. Faisons une chose à la fois. Les méthodes qui exposent progressivement une fonctionnalité nécessitent une analyse statistique ou des commutateurs de fonctionnalités.

Un déploiement bleu-vert est quelque chose que je peux contrôler. Changer de routeur est simple. C’est facile et sonne sûr. Et dans un déploiement bleu-vert, la gestion a un environnement à évaluer. Quand ils donnent l’OK, nous pouvons facilement changer. Commençons par là.

La question est donc de savoir comment implémenter un déploiement bleu-vert dans notre pipeline ?

Que sont les emplacements de déploiement ?

Andy: Étant donné que nous utilisons Azure App Service, nous pouvons tirer parti des emplacements de déploiement. Les emplacements de déploiement exécutent des applications qui ont leur propre nom d’hôte.

Je sais que nous ne sommes pas encore prêts à déployer le site web Space Game en production dans le cadre du pipeline automatisé. Pour tester, nous pouvons ajouter un emplacement de déploiement à notre environnement préproduction.

Au lieu de configurer un équilibreur de charge ou un routeur, nous pouvons simplement ajouter un deuxième emplacement à l’instance App Service que nous utilisons dans notre environnement intermédiaire existant. Nous pouvons appeler l’emplacement principal bleu et l’emplacement secondaire vert.

De cette façon, nous pouvons déployer de nouvelles fonctionnalités sans temps d’arrêt. Nous échangeons une application et sa configuration entre les deux emplacements de déploiement. En fait, nous échangeons les adresses IP des deux emplacements.

Tim: J’aime ça! Vous pouvez appeler cette variante d’un déploiement bleu-vert un déploiement sans temps d’arrêt.

Andy: Génial! Tim et moi allons travailler sur l’implémentation de ce modèle de déploiement. Nous pouvons tous nous rencontrer plus tard pour voir les résultats.

Recommandations relatives à l’utilisation d’indicateurs de fonctionnalité

Les indicateurs de fonctionnalité étaient l’une des méthodes de cadence de publication prises en compte par l’équipe. L’équipe a décidé de ne pas utiliser les indicateurs de fonctionnalité, mais beaucoup de personnes les ont trouvées utiles. Cette section fournit plus d’informations sur les indicateurs de fonctionnalité.

Les indicateurs de fonctionnalité, parfois appelés bascules de fonctionnalité, vous permettent de modifier le fonctionnement d’un système sans modifier le code. Ces indicateurs vous permettent d’envoyer du nouveau code dans votre branche de développement centrale et de déployer le code, mais pas nécessairement fonctionnel. Les indicateurs sont généralement implémentés comme valeur des variables qui contrôlent la logique conditionnelle.

Imaginez que votre équipe travaille dans la branche centrale de développement d’une application bancaire. Vous avez décidé de faire tout le travail dans la branche primaire pour éviter de devoir faire face à des opérations de fusion désordonnées plus tard. Mais vous rencontrez un problème. Vous modifiez considérablement les calculs d’intérêt, et les gens dépendent de ce code chaque jour. Pire encore, il vous faudra des semaines pour effectuer les changements. Vous ne pouvez pas laisser le code principal rompu pendant si longtemps.

Dans ce scénario, un indicateur de fonctionnalité peut être une bonne solution. Vous pouvez modifier le code afin que les utilisateurs qui n’ont pas l’indicateur de fonctionnalité défini puissent continuer à utiliser le code de calcul d’intérêt d’origine. Par ailleurs, votre équipe a activé le drapeau de fonctionnalité, ce qui lui permet de voir le code qu'elle modifie.

Un autre type d’indicateur de fonctionnalité est un indicateur de mise en production. Imaginez qu’après avoir terminé le travail sur le code de calcul d’intérêt, vous souhaitez l’essayer avant de le publier publiquement. Vous disposez d’un groupe d’utilisateurs qui sont bien placés pour traiter le nouveau code et les éventuels problèmes possibles. Vous les laisserez d’abord essayer la fonctionnalité. Vous modifiez la configuration afin qu’elle ait également l’indicateur de fonctionnalité défini et puisse tester le nouveau code. Si des problèmes se produisent, vous pouvez rapidement désactiver l’indicateur.