A l’ère du digital il faut livrer rapidement les applications pour que le client puisse en bénéficier le plus vite possible. C’est tout l’objet de la démarche DevOps qui permet d’aligner les équipes, les outils et les processus mais aussi de choisir les meilleures stratégies pour optimiser la fréquence des déploiements tout en minimisant les risques de temps d’arrêt et surtout que ce soit transparent pour les utilisateurs.
L’implémentation CI/CD (intégration continue et déploiement continu) est l’une des meilleures pratiques mise en œuvre par les équipes DevOps.
Le déploiement continu : l’étape finale d’un pipeline CI/CD mature
Il dépend surtout de l’automatisation des processus de tests qui nécessite un investissement non négligeable pour que les tests soient rédigés de manière à s’adapter à un large éventail d’étapes.
Les tests sont fondamentaux pour garantir que la livraison pourra s’effectuer à la fois sans régression et en conservant un niveau de performance suffisant. Malgré l’impact potentiel sur le rythme des déploiements, le bénéfice sera supérieur au risque encouru par le déploiement d’une application ou d’un service mal testé.
Comme le précise Micaël Vanhalst, expert DevOps chez SoftFluent
Néanmoins sans les stratégies avancées de déploiement, il est difficile de mettre en place le déploiement continu. Le déploiement continu implique de répondre à certaines questions :
Faut-il garder le site en production le temps qu’un correctif soit livré ? Faut-il faire un rollback vers la version précédente ? Comment adresser ces problèmes dans sa stratégie de déploiement ? La démarche DevOps, qui prône une livraison fréquente des évolutions aux utilisateurs, propose plusieurs moyens pour garantir la continuité des services, et notamment les patterns comme Blue-Green Deployment, Canary Release et A/B Testing…
Qu’est-ce que le « Blue-Green Deployment » ?
Le pattern « Blue Green Deployment » est une implémentation d’un modèle plus générique appelé ZDD « Zero Downtime Deployment » dont l’objectif est de limiter au maximum la rupture de service lors du déploiement d’une nouvelle version.
Un déploiement Blue-Green utilise deux environnements de production configurés de manière identique sur lesquels vous pouvez déployer votre application et un routeur pour envoyer du trafic utilisateur vers l’un ou l’autre. On peut ainsi facilement effectuer les tests avant de déployer. On se retrouve en production avec une version assez mature et qui a quasiment déjà fait ses preuves, l’utilisateur ressentira quant à lui à peine une légère interruption en passant d’une version à l’autre
Avantages
- L’implémentation est facile et rapide (sur un environnement type Cloud)
- Rollback possible car l’ancien déploiement est encore opérationnel
- Possibilité de faire des tests sur un environnement identique à la production
Inconvénients
- Besoin de deux fois plus de ressources (coûts et maintenance supérieurs)
Qu’est-ce que le « Canary Release » ?
Le principe du « Canary Release » est assez similaire au « Blue-Green Deployment », mais offre aux équipes projet une étape durant laquelle l’application est testée en production par un nombre restreint d’utilisateurs, sans impacter l’expérience utilisateur de la majeure partie des utilisateurs.
Ce mode est à privilégier, par rapport au « Blue Green Deployment », si vous n’êtes pas certain du fonctionnement en production de la nouvelle version.
Son objectif est de détecter et de résoudre rapidement un problème avec une nouvelle version de logiciel avant qu’il ne dégrade l’expérience de chacun.
Comment fonctionne le « Canary Release » ?
On commence par déployer une nouvelle version de service, qui ne reçoit aucun trafic. Si l’on observe que le service démarre normalement, on dirige un petit pourcentage de trafic vers ce service. Les erreurs sont surveillées en permanence. L’augmentation du trafic s’effectue par étape jusqu’à ce que le nouveau service reçoive 100% du trafic.
Qu’est ce que le « Ring Based Deployment » ?
Le « Ring based Deployment » est la version étendue du « Canary Release ». Il peut lui-même être combiné avec l’exposition différenciée des fonctionnalités « Features Flags » générant un niveau de complexité encore plus important. Cette combinaison produit un nouveau modèle le « Dark Launch ».
Le modèle du « Ring Based Deployment » étend le « Canary Release » car il identifie de manière plus précise les différentes cibles. Alors que le « Canary Release » redirige progressivement le trafic réseau, de manière indifférenciée, vers une cible générale, le « Ring Based Deployment » procède par étapes en ciblant des publics déterminés à l’avance.
Selon Micaël
Feature Flags
Ce mécanisme de configuration permet d’activer ou de désactiver des fonctionnalités au moment de l’exécution. Les fonctionnalités encore en cours de développement sont balisées dans le code par des indicateurs de fonctionnalités déployées en production à partir de la branche principale et désactivées jusqu’à ce qu’elles soient prêtes à être utilisées.
Ce modèle peut avoir un impact non négligeable en termes de coût de développement. S’il n’a pas été prévu en amont, il demandera un effort conséquent et devra faire l’objet d’un vrai projet plus ou moins simple. La version simple s’appuie sur un fichier de configuration avec les instructions d’activation ou non d’une fonctionnalité, les versions plus avancées vont jusqu’à présenter des interfaces permettant l’activation dynamique de fonctionnalités
Selon Micaël
Dark launch
C’est la combinaison du « Ring-based Deployment » et des « Features Flags ». Concrètement, la nouvelle fonctionnalité, lorsqu’elle est encore au stade de préversion, est livrée en production avec les autres mises à jour de la version en production et activée pour un nombre réduit d’utilisateurs en fonction de critères (zone géographique, sexe) ou en proposant un message invitant à tester cette nouvelle fonctionnalité.
Au fil des déploiements, la fonctionnalité est améliorée en tenant compte du feedback des utilisateurs et des différents indicateurs, jusqu’à son déploiement à l’ensemble des utilisateurs.
Ce modèle permet une très grande souplesse, en proposant d’activer des fonctionnalités en fonction d’un groupe d’utilisateurs cible, d’un environnement ou de tout autre paramètre. Pour implémenter ce modèle, il est généralement conseillé de s’appuyer sur des solutions existantes comme « LaunchDarkly »
Selon Micaël
Qu’est-ce que le « Test A/B » ?
Le « Test A/B » est une méthode connue de comparaison de deux versions qui dépasse le cadre du déploiement. Deux variantes sont présentées aux utilisateurs de manière aléatoire pour déterminer celle qui fonctionne le mieux.
Comment fonctionne un « A/B Testing » ?
Dans un « Test A/B », nous modifions une page Web d’une application pour créer une deuxième version de la même page par exemple. Ça peut être un titre H2, la position d’un bouton, ou une refonte complète de la page. Une partie du trafic affiche la version originale de la page et l’autre partie, identifiée par un paramètre spécifique, la version modifiée avec des statistiques pour évaluer la performance de chacune.
Le Continuous Deployment avec Azure
Voyons ici un exemple d’implémentation concrète du « Blue-Green Deployment »
Lorsque vous créez une Web Application sur Azure, vous disposez par défaut d’un slot de production.
Chaque fois que vous déployez votre application, cette dernière est déployée par défaut sur ce slot. Azure Web Apps vous offre cependant la possibilité de créer un autre emplacement de déploiement (staging) dans le même service plan. Lorsque la nouvelle version est prête, vous la déployez dans un premier temps sur le slot de staging. A partir du portail Azure, vous pouvez définir le pourcentage d’utilisateurs qui seront redirigés vers cette nouvelle version et effectuer vos tests de performance en production (A/B Testing).
Après l’échange des slots de staging et de production, il ne faut pas oublier de modifier la configuration de la redirection du trafic réseau pour que l’ensemble des utilisateurs ait accès à la production. Toutes ces opérations peuvent être accomplies en exploitant le portail Azure, mais il est recommandé de les mettre en œuvre de la manière la plus automatisée possible. Elles peuvent évidemment être réalisées dans le cadre du déploiement continu.
Comme l’explique Micaël
Rappel des bonnes pratiques de déploiement continu
Les trois principaux composants du déploiement sur App Service sont : les sources de déploiement, les pipelines de génération et les mécanismes de déploiement.
Source de déploiement
Une source de déploiement correspond à l’emplacement de votre code d’application. Pour les applications de production, la source de déploiement est généralement un référentiel hébergé par un logiciel de gestion de version comme Git et en s’appuyant sur des opérateurs comme GitHub, GitLab, BitBucket ou les repos d’Azure DevOps.
Pipeline de build
Après la source de déploiement, l’étape suivante consiste à choisir un pipeline de build. Un pipeline exécute une série d’étapes (telles que la compilation de code, la minimisation du HTML et du JavaScript, l’exécution de tests et l’empaquetage de composants) pour rendre l’application exécutable. Ces opérations peuvent être exécutées sur un serveur de build, comme Jenkins, TeamCity ou en exploitant les pipelines d’Azure DevOps.
Le pipeline de build va produire en sortie, le package applicatif qu’on appelle souvent artefact de livraison. Il est important que ce soit le même livrable issu du CI qui soit transporté vers les différents environnements (Dev, tests, UAT, prod par exemple) au risque de se retrouver avec des versions différentes de l’application au sein des différents environnements. En cas d’erreur, il serait très complexe d’en identifier la source
Selon Micaël
Mécanisme de déploiement
Le mécanisme de déploiement est l’action utilisée pour placer votre application intégrée dans le répertoire « /home/site/wwwroot » de votre application web, un emplacement de stockage partagé par toutes les instances incluant un système de notification. App Service prend en charge les mécanismes suivants :
- Points de terminaison Kudu : Kudu est l’outil de productivité de développement open source qui gère les déploiements continus et fournit des points de terminaison HTTP pour le déploiement, comme « Zip Deploy » (déploiement d’une archive ZIP ou WAR) ;
- FTP et WebDeploy : à l’aide des informations d’identification de votre site ou de votre utilisateur, vous pouvez aussi téléverser des fichiers via FTP ou WebDeploy.
La plupart des outils de déploiement, tels que les pipelines d’Azure DevOps, Jenkins et les plug-ins d’éditeur, utilisent un de ces mécanismes de déploiement.
Utiliser des emplacements de déploiement
Dans la mesure du possible :
- Utilisez des emplacements de déploiement comme un plan App Service Standard par exemple pour déployer dans un environnement intermédiaire et effectuer les tests de vérification de Build.
- Déployez votre branche de production principale sur un emplacement dit de ‘non-production’ et lorsque vous êtes prêt, échangez-la dans l’emplacement de production.
Déployer du code en continu
Que votre équipe projet ait sélectionné un workflow Git avancé comme « GitFlow » ou ait décidé d’aller vers une stratégie de gestion des branches Git plus simple, comme le TBD ou « Trunk Based Development », il faut qu’un choix sur le processus de mise en production ait été fait.
Il peut par exemple s’appuyer sur l’application d’un tag Git de version sur la branche principale et une configuration adaptée des déclencheurs au niveau du service en charge de la CI/CD. Ces principes doivent assurer une automatisation maximale des déploiements pour qu’ils deviennent les plus continus possibles
Comme l’explique Micaël
Déployer des conteneurs en continu
La conteneurisation apporte un nombre important d’avantages, parmi lesquels :
- La standardisation du packaging d’une application ou d’un service
- Une très grande stabilité de la description des pipelines (la gestion des dépendances, d’une grande partie de la configuration étant gérées au sein du conteneur lui-même)
- La possibilité d’exécuter sur le poste du développeur un environnement qui devient très proche de la production (il suffit d’installer le runtime Docker)
- L’exploitation d’orchestrateurs tels que Kubernetes pour améliorer le processus de déploiement (en évitant notamment les ruptures de service)
La conteneurisation a déjà pris une grande part au sein des pratiques DevOps, mais elle ne peut encore que progresser. Tous les avantages qu’elle apporte correspondent pleinement aux pratiques encouragées par le DevOps
Comme l’explique Micaël
A lire aussi Devops, Docker et .NET Core : optimiser la taille de l’image Docker
Le DevOps n’a pas inventé les modèles de déploiement présentés dans cet article. Le DevOps définit de manière assez rationnelle et pragmatique, un certain nombre de concepts. Il se trouve simplement que ces modèles de déploiement correspondent à ces concepts. C’est pour cette raison qu’ils sont souvent mis en avant quand on aborde le sujet du DevOps. D’autres modèles existent, certains sauront répondre à vos besoins. Il sera parfois nécessaire d’adapter ou de créer un modèle qui vienne s’aligner à vos contraintes.
