Que sont 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 auprès des utilisateurs. Un modèle de déploiement approprié vous aide à réduire les temps d’arrêt. Certains modèles vous permettent également de déployer progressivement de nouvelles fonctionnalités. Ainsi, vous pouvez valider de nouvelles fonctionnalités auprès de certains utilisateurs avant de les mettre à disposition de tout le monde.
Dans cette section, vous allez découvrir certains modèles de déploiement courants. Vous allez apprendre également comment Azure App Service contribue à l’implémentation du modèle choisi par l’équipe de Tailspin.
Réunion du matin
L’équipe de Tailspin est détendue. Son pipeline a accéléré le processus. L’équipe dispose d’un environnement de développement dans lequel elle peut intégrer l’application web avec une base de données. Tim et Amita se félicitent de disposer de tests automatisés qui leur simplifient le travail. En général, ils voient moins de retards et moins de bogues.
Mais, comme toujours, il existe un problème. Passons à la réunion d’équipe, où Tim a la parole.
Tim : Il est si difficile de satisfaire tout le monde. Irwin pense que la mise en production de nouvelles fonctionnalités prend trop de temps. Je ne peux rien faire tant que la direction n’a pas approuvé la mise en production. Et à ce stade, il n’existe aucune méthode fluide pour déployer les fonctionnalités, une fois que le feu vert aura été obtenu. Le processus est non seulement long mais compliqué. Il est manuel, et il comporte des temps d’arrêt. L’ensemble du processus peut durer cinq jours. Je sais que c’est trop long, mais que suis-je censé faire ? Peut-être qu’en buvant plus de café, je trouverai la solution.
Andy : Le café est essentiel à toute résolution de problème efficace, 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 méthode automatisée qui permet d’effectuer le basculement. Il s’agit de la façon dont nous faisons passer le logiciel de la phase finale de préproduction à la production.
Choisir le bon modèle vous aidera certainement, par exemple en réduisant les temps d’arrêt. Un modèle de déploiement présente un autre avantage : il nous permet d’exécuter des tests qui doivent réellement avoir lieu en production.
Andy commence à écrire sur le tableau blanc.
Voici les possibilités que nous devons prendre en compte :
- Déploiement bleu-vert
- Mises en production avec contrôle de validité
- Bascules de fonctionnalités
- Dark launch
- Test A/B
- Déploiement avec exposition progressive
Voyons brièvement chaque modèle.
Déploiement Blue-Green
Un déploiement bleu-vert réduit les risques et les temps d’arrêt en permettant l’exécution de deux environnements identiques. Ces environnements sont appelés bleu et vert. À tout moment, l’un des environnements est en production. Un déploiement bleu-vert implique généralement l’utilisation d’un routeur ou d’un équilibreur de charge, qui permet de contrôler le flux de trafic.
Supposons que le bleu est en production. Durant la préparation d’une nouvelle version, nous effectuons nos derniers tests dans l’environnement vert. Une fois que le logiciel fonctionne dans l’environnement vert, il nous suffit de commuter le routeur pour que toutes les requêtes entrantes soient dirigées vers l’environnement vert.
Le déploiement bleu-vert nous offre également un moyen rapide de procéder à une restauration. En cas de problème dans l’environnement vert, nous commutons simplement le routeur pour repasser à l’environnement bleu.
Mises en production avec contrôle de validité
Une mise en production avec contrôle de validité permet d’identifier rapidement les problèmes potentiels sans exposer l’ensemble des utilisateurs. L’idée est la suivante, nous exposons une nouvelle fonctionnalité à un petit groupe d’utilisateurs avant de la rendre accessible à 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 mise en production a des problèmes, nous appliquons un correctif. Une fois que la mise en production avec contrôle de validité est reconnue comme étant stable, nous la déplaçons vers l’environnement de production réel.
Bascules de fonctionnalités
Utilisez les bascules de fonctionnalités pour « actionner un commutateur » au moment de l’exécution. Nous pouvons déployer de nouveaux logiciels sans exposer les nouvelles fonctionnalités ou celles qui ont changé aux utilisateurs.
Dans ce modèle de déploiement, Mara et moi créons des fonctionnalités à bascule. Quand une mise en production a lieu, la fonctionnalité est « désactivée » pour qu’elle n’affecte pas le logiciel en 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 pouvons d’abord exposer la fonctionnalité à quelques utilisateurs pour voir comment ils réagissent. Cet échantillon aléatoire d’utilisateurs voit la fonctionnalité. Ou, nous pouvons simplement rendre la fonctionnalité accessible à tout le monde.
Toutefois, ce modèle de déploiement peut être plus utile à Mara et moi qu’à quiconque. Un gros avantage du modèle avec bascule de fonctionnalité est qu’il nous permet d’éviter un trop grand nombre de créations de branches. La fusion des branches peut être une tâche fastidieuse.
Dark launch
Un dark launch 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 les utilisateurs, nous la proposons à un petit nombre d’entre eux à travers un dark launch.
Ces utilisateurs ne savent pas qu’ils testent la fonctionnalité pour nous. Nous ne leur parlons même pas de la nouvelle fonctionnalité. C’est la raison pour laquelle il s’agit d’un dark launch (lancement dans l’ombre). Le logiciel est mis à la disposition des utilisateurs de manière progressive ou discrète pour que nous puissions recueillir leurs commentaires et tester les performances.
Test A/B
Un test A/B permet de comparer deux versions d’une page web ou d’une application pour déterminer celle qui est la plus performante. Les tests A/B ressemblent à une expérience classique.
Dans un test A/B, nous montrons de manière aléatoire aux utilisateurs deux ou plusieurs variantes d’une page. Nous utilisons ensuite l’analyse statistique pour déterminer quelle est la variante la plus performante pour nos objectifs.
Déploiement avec exposition progressive
Le déploiement avec exposition progressive est parfois appelé déploiement en anneaux. Il s’agit d’une autre façon de limiter l’impact des changements sur les utilisateurs tout en garantissant la validité de ces changements 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 correspond essentiellement à la même idée.
Dans un déploiement en anneaux, nous déployons d’abord les changements auprès des clients qui tolèrent les risques encourus. Nous étendons ensuite progressivement le déploiement à un plus grand nombre de clients.
Implémentation du déploiement bleu-vert
Andy regarde Tim.
Andy : Cela fait beaucoup, je sais. Voulez-vous prendre le temps d’y réfléchir ? Ou vous et moi, nous pourrions...
Tim : Bleu-vert.
Tout le monde se met à rire dans la salle.
Mara : C’est le café qui parle ?
Tim : Les bascules de fonctionnalités impliquent un changement dans la façon dont vous et Andy travaillez. Faisons une chose à la fois. Les méthodes qui exposent progressivement une fonctionnalité nécessitent une analyse statistique ou des bascules de fonctionnalités.
Un déploiement bleu-vert est une chose que je peux contrôler. La commutation d’un routeur ne pose pas de problème. C’est facile et cela semble sûr. De plus, dans un déploiement bleu-vert, la direction a un environnement à évaluer. Une fois que le feu vert aura été donné, nous pourrons facilement procéder à la commutation. Commençons par là.
La question est donc de savoir comment nous allons implémenter un déploiement bleu-vert dans notre pipeline ?
Que sont les emplacements de déploiement ?
Andy : Dans la mesure où nous utilisons Azure App Service, nous pouvons tirer parti des emplacements de déploiement. Les emplacements de déploiement sont des applications actives qui ont leurs propres noms d’hôtes.
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é. Mais à titre de test, nous pouvons ajouter un emplacement de déploiement à notre environnement de préproduction.
Au lieu de configurer un équilibreur de charge ou un routeur, il nous suffit d’ajouter un deuxième emplacement à l’instance d’App Service que nous utilisons dans notre environnement de préproduction existant. Nous pouvons appeler l’emplacement principal bleu, et l’emplacement secondaire vert.
Ainsi, nous pouvons déployer de nouvelles fonctionnalités sans le moindre 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 : Ça me plaît ! Vous pouvez appeler cette variante d’un déploiement bleu-vert un déploiement sans temps d’arrêt.
Andy : Parfait ! Tim et moi allons travailler sur l’implémentation de ce modèle de déploiement. Nous nous réunirons plus tard pour voir les résultats.
Recommandations relatives à l'utilisation des indicateurs de fonctionnalités
Les indicateurs de fonctionnalités étaient l’une des méthodes de gestion de la cadence de mise en production envisagée par l’équipe. L’équipe a décidé de ne pas utiliser les indicateurs de fonctionnalités, mais de nombreuses personnes les ont trouvés utiles. Cette section fournit plus d’informations sur les indicateurs de fonctionnalités.
Les indicateurs de fonctionnalités, parfois appelés bascules de fonctionnalités, vous permettent de modifier le fonctionnement d’un système sans changer le code. Ces indicateurs vous permettent de pousser le nouveau code dans votre branche de développement centrale, et de déployer ce code sans qu’il soit nécessairement opérationnel. Les indicateurs sont généralement implémentés en tant que valeurs des variables qui contrôlent la logique conditionnelle.
Imaginez que votre équipe travaille dans la branche de développement centrale 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 êtes confronté à un problème. Vous changez de manière importante les calculs des intérêts, et les gens dépendent de ce code tous les jours. Pire encore, les changements vont vous demander des semaines. Vous ne pouvez pas laisser le code principal dans cet état pendant si longtemps.
Dans ce scénario, un indicateur de fonctionnalité peut être une bonne solution. Vous pouvez changer le code afin que les utilisateurs pour lesquels l’indicateur de fonctionnalité n’est pas défini puissent continuer à utiliser le code d’origine de calcul des intérêts. Pendant ce temps, votre équipe, pour laquelle l’indicateur de fonctionnalité a été défini, peut voir le code auquel elle apporte des changements.
L’indicateur de version est un autre type d’indicateur de fonctionnalité. Imaginez qu’après avoir effectué le travail nécessaire sur le code de calcul des intérêts, vous souhaitiez le tester avant de le mettre en production publiquement. Vous disposez d’un groupe d’utilisateurs bien positionnés pour gérer le nouveau code et les éventuels problèmes. Vous allez d’abord les laisser tester la fonctionnalité. Vous changez la configuration afin de définir également l’indicateur de fonctionnalité pour ces utilisateurs. Ainsi, ils peuvent tester le nouveau code. Si des problèmes se produisent, vous pouvez rapidement désactiver l’indicateur.