DevOps : les trois types de déploiement les plus populaires

Déploiement progressif

Dans le cadre d’un déploiement progressif, les équipes IT maintiennent un environnement de production pour une application distribuée. Celui-ci se compose de plusieurs serveurs ou instances en cloud, chacun hébergeant une copie de l’application. Il y a aussi généralement un répartiteur de charge qui achemine le trafic entre les serveurs.

Pour déployer une nouvelle version de l’application, les administrateurs informatiques échelonnent les modifications de sorte que la mise à jour s’active sur certains serveurs ou instances avant d’autres. Dans ce cas, les premiers cités exécutent la nouvelle version de l’application, tandis que d’autres continuent à héberger l’ancienne. Au fur et à mesure que le trafic arrive dans l’application, certains utilisateurs interagissent avec le nouveau code, tandis que d’autres se retrouvent sur la version existante en production.

Tant qu’aucun problème n’apparaît avec la nouvelle version, le déploiement se poursuit dans l’environnement d’hébergement, jusqu’à ce que tous les serveurs exécutent l’application mise à jour. Si erreur il y a, les opérateurs peuvent cependant rediriger tout le trafic vers les serveurs qui hébergent encore la version existante, jusqu’à ce que le problème avec la nouvelle version soit résolu.

Les déploiements progressifs fonctionnent bien pour les organisations informatiques disposant d’une infrastructure d’hébergement suffisamment importante pour que certains serveurs soient mis hors service – sans dégradation des performances – au cas où un problème surviendrait avec une mise à jour de l’application. C’est également une technique utile pour les déploiements qui impliquent de petites modifications.

Il existe des cas d’usage où le déploiement progressif n’est pas une bonne solution. Par exemple, lorsque les développeurs d’applications publient des changements majeurs, certains utilisateurs – ceux dont les requêtes sont dirigées vers des serveurs exécutant la version A de l’application – connaissent des fonctionnalités sensiblement différentes de celles de la version B. Le support technique doit connaître les deux versions et être capable d’identifier celle sur laquelle un utilisateur se trouve. Des versions distinctes peuvent également perturber le travail d’équipe et les relations avec les contractants.

Une simple application web avec une interface utilisateur qui évolue progressivement est un bon candidat pour un déploiement progressif. Les modifications apportées à une telle application sont suffisamment progressives pour pouvoir être mises en œuvre en toute sécurité dans le cadre d’un « rolling deployment », sans incohérences majeures pour l’utilisateur.

Déploiement blue/green

Dans le modèle de déploiement blue/green, les équipes maintiennent deux infrastructures d’hébergement d’applications distinctes : une bleue et une verte. À tout moment, l’une de ces configurations d’infrastructure héberge la version de production de l’application, tandis que l’autre est tenue en réserve.

Les administrateurs déploient une nouvelle version de l’application dans l’infrastructure de réserve, également appelée environnement de simulation (staging environment). Une fois qu’ils ont suffisamment testé le déploiement, les administrateurs peuvent échanger le trafic d’une infrastructure à l’autre. L’environnement de simulation devient celui de production, et l’ancien environnement de production est décommissionné.

Les modèles de déploiement blue/green offrent aux exploitants IT de plus grandes largesses pour tester une nouvelle version dans un environnement proche de celui de la production avant de la rendre publique. Ils leur permettent également de faire passer tous les utilisateurs à une nouvelle version en une seule fois, contrairement aux approches de déploiement en canari et progressif. Cela permet d’utiliser des applications qui font l’objet de révisions majeures à chaque nouvelle version, plutôt que de changements incrémentiels. Une application SaaS s’avère être une bonne candidate pour ce type de déploiement.

Comme cette stratégie exige des services informatiques qu’ils maintiennent deux environnements d’hébergement, identiques, chacun suffisamment grands pour la production, les coûts d’infrastructure doublent. Soit l’empreinte de l’application est faible, soit le budget de l’équipe doit être suffisamment important pour en supporter la charge. Enfin, l’assurance qualité n’aura peut-être pas le loisir de découvrir tous les bugs importants dans l’environnement de simulation, car celui en production interagit sans doute avec d’autres systèmes ou d’autres composants qui peuvent entrer en conflit avec le nouveau code.

Déploiement canary

Le modèle de déploiement canary (ou canari) est similaire à un déploiement progressif dans la mesure où les développeurs mettent la nouvelle version à la disposition de certains utilisateurs avant d’autres. Cependant, la technique derrière Canary vise à ce que certains utilisateurs reçoivent l’accès à la nouvelle version de l’application, plutôt que certains serveurs.

Cette stratégie de déploiement d’applications offre un avantage clé par rapport à la méthodologie blue/green : l’accès à des retours d’expérience anticipés et à l’identification des bugs que la plupart des utilisateurs n’auront pas à subir. Le sous-ensemble d’utilisateurs spécifié, c’est-à-dire les canaris, trouve les faiblesses et améliore la mise à jour avant que l’équipe informatique ne la déploie auprès de tous les utilisateurs.

Les déploiements canary ont du sens pour les applications dont le groupe d’utilisateurs est identifiable et plus tolérant aux bugs – ou mieux à même de contribuer à les déceler – que la base d’utilisateurs générale. Par exemple, une stratégie courante consiste à déployer la nouvelle version en interne – auprès des employés – pour des tests d’acceptation avant qu’elle ne soit rendue publique. Dans le même ordre d’idées, les SI peuvent créer un groupe d’utilisateurs « opt-in » qui souhaitent recevoir les versions mises à jour de l’application avant les autres. Ces utilisateurs avertis sont prêts à accepter le risque d’anicroches numériques pour accéder plus rapidement aux nouvelles fonctionnalités.

Contrairement aux déploiements progressifs et blue/green, les organisations IT n’ont pas besoin de provisionner une deuxième infrastructure. Il s’agit donc d’une technique utile pour les startups ou d’autres entreprises soumises à des contraintes budgétaires strictes. Attention toutefois à la phase de vérification et aux possibles dégradations de la qualité. Des vérifications manuelles (ou des outils de tests unitaires automatisés) ainsi qu’une observabilité complète sont nécessaires au moment de la mise en production.