La phase de déploiement de la livraison de logiciels joue un rôle substantiel dans le développement de logiciels d’aujourd’hui, encore plus dans un environnement en nuage.
Malgré cela, c’est aussi l’une des phases de livraison les plus sous-estimées. Les entreprises n’investissent généralement pas assez de temps et d’énergie pour rendre le déploiement rapide, fiable, automatisé, ou l’un de ces éléments.
La plupart du temps, je vois encore diverses formes de procédures de déploiement manuel. Dans le meilleur des cas, au moins avec une liste de contrôle des étapes correctement documentée. Dans le pire des cas, il s’agit de plans aléatoires créés par improvisation dans les dernières minutes.
L’automatisation des procédures de déploiement est toujours un objectif lointain et un élément de la feuille de route à court ou moyen terme, mais le chemin qui y mène est semé d’embûches et imprévisible. Mais une procédure de déploiement entièrement automatisée et fiable est la clé d’économies significatives au fil du temps. Vous pouvez alors éliminer les efforts que la plupart des membres de l’équipe de développement consacrent habituellement au déploiement de chaque version de production.
Les stratégies de déploiement Canary et Blue-Green reprennent tous ces avantages et en ajoutent d’autres, tels que la haute disponibilité et des processus d’installation et de retour en arrière rapides. Elles permettent à l’équipe de publier des versions encore plus souvent et sans plus de nuits blanches. Voyons ce qu’elles apportent et en quoi elles diffèrent.
Déploiement bleu-vert : Une vue d’ensemble
Le déploiement bleu-vert réduit les temps d’arrêt et les risques liés aux nouvelles versions de logiciels en créant deux environnements identiques : un environnement actif (bleu) et un environnement inactif (vert).
L’environnement actif est celui où la version actuelle du logiciel fonctionne et où les utilisateurs génèrent du trafic de production. L’environnement inactif est celui dans lequel la nouvelle version du logiciel est déployée et testée.
Une fois la nouvelle version testée et prête, le trafic est transféré de l’environnement actif vers l’environnement inactif, qui devient ainsi le nouvel environnement actif. Vous pouvez répéter ce processus autant que nécessaire.
Lisez aussi : Explication du déploiement bleu-vert et de son rôle dans DevOps
Principales caractéristiques et avantages
Voici les caractéristiques spécifiques du processus de déploiement bleu-vert :
- Deux environnements identiques sont identiques du point de vue des données et des processus. L’environnement bleu (actif) est celui dans lequel les utilisateurs de la production exécutent leurs processus quotidiens. L’environnement vert (inactif) est celui où le nouveau déploiement est installé et toujours synchronisé avec l’environnement bleu.
- Vous pouvez basculer le trafic de l’environnement actif vers l’environnement inactif, ce qui en fait le nouvel environnement actif. Le basculement est instantané. Tous les déploiements appartiennent désormais au passé. Il n’y a pas de fenêtre d’indisponibilité. Les utilisateurs n’ont rien à faire pour accéder au nouvel environnement.
- Le retour rapide en arrière en cas de problème est une conséquence. Cela garantit un temps d’arrêt minimal en cas de problème avec la nouvelle version du logiciel, et l’application reste hautement disponible.
- L’automatisation des tests est un aspect essentiel du déploiement bleu-vert. Ils garantissent que la nouvelle version du logiciel est testée de manière approfondie avant d’être déployée dans l’environnement actif.
- Ce déploiement fait partie d’un pipeline de livraison continue, ce qui signifie en fin de compte des mises en production plus rapides et plus fréquentes du logiciel. Étant donné que le déploiement a déjà été effectué et que vous n’avez qu’à effectuer le changement de trafic lui-même, c’est tellement rapide que vous pouvez le faire tous les jours. En supposant que vous soyez rapide dans les activités de test.
Déploiement de Canary : Une vue d’ensemble
Le déploiement canarien consiste à diffuser progressivement de nouvelles fonctionnalités ou des mises à jour à un petit sous-ensemble d’utilisateurs avant de les diffuser à l’ensemble de la base d’utilisateurs.
Cette approche consiste à créer une nouvelle version du logiciel et à la déployer auprès d’un petit groupe tout en conservant l’ancienne version pour le reste des utilisateurs. L’équipe de développement surveille étroitement la nouvelle version pour s’assurer qu’elle est stable et qu’elle fonctionne comme prévu.
Si tout se passe bien, la nouvelle version est déployée auprès d’un plus grand nombre d’utilisateurs jusqu’à ce qu’elle atteigne l’ensemble de la base d’utilisateurs. De cette manière, l’équipe de projet minimise le risque d’introduire des bogues ou d’autres problèmes qui pourraient affecter tous les utilisateurs en même temps.
L’objectif est de réduire le risque d’introduire de nouvelles fonctionnalités auprès d’une large base d’utilisateurs. La transition vers la nouvelle version se fait donc beaucoup plus en douceur.
Lisez aussi : Explication du déploiement Canary et de son rôle dans DevOps
Principales caractéristiques et avantages
Voici les caractéristiques spécifiques du processus de déploiement de Canary :
- Déployez d’abord la nouvelle version auprès d’un petit sous-ensemble d’utilisateurs, puis progressivement auprès d’un plus grand nombre d’utilisateurs. Vous minimisez ainsi le risque d’introduire des bogues ou d’autres problèmes qui pourraient affecter tous les utilisateurs en même temps.
- Surveillez de près la nouvelle version pour vous assurer qu’elle est stable et qu’elle fonctionne comme prévu. Les développeurs peuvent recevoir plus rapidement des commentaires sur la nouvelle version, ce qui leur permet d’apporter les ajustements nécessaires avant de la déployer auprès de l’ensemble des utilisateurs.
- En cas de problème, revenez rapidement et facilement à la version précédente. Cela permet d’accroître la confiance des développeurs et des parties prenantes dans le processus de déploiement, car cela réduit le risque d’introduire des problèmes qui pourraient avoir un impact sur l’expérience de l’utilisateur.
- Automatisez le processus de déploiement autant que possible afin de réduire le risque d’erreur humaine.
Résumé : Déploiement bleu-vert vs. déploiement canarien
| Fonctionnalité | Déploiement bleu-vert | Déploiement canarien |
|---|---|---|
| Synchronisation des données | Synchronisation constante des données entre les environnements bleu et vert. | Un sous-ensemble d’utilisateurs ou de serveurs reçoit la nouvelle version ; les autres continuent à utiliser la version actuelle. |
| Processus d’activation | Passage de l’environnement actif à l’environnement inactif lorsqu’une nouvelle version est prête. | Déploiement progressif vers un sous-ensemble défini d’utilisateurs qui testent activement les nouvelles versions. |
| Expérience des utilisateurs en production | Pas de temps d’arrêt de la production ; passage transparent d’un environnement actif à l’autre. | Un sous-ensemble d’utilisateurs de la production teste activement la nouvelle version ; problèmes potentiels pour ce groupe. |
| Haute disponibilité et rapidité du retour d’information | Priorité à la haute disponibilité. | Priorité à un retour d’information plus rapide et à un déploiement contrôlé. |
| Atténuation des risques | Réduction des risques de problèmes grâce à une diffusion progressive auprès d’un sous-ensemble d’utilisateurs. | Essais principalement dans des environnements inactifs ; les testeurs risquent de ne pas détecter tous les problèmes réels. |
| Approche par les tests | Test principalement dans des environnements inactifs ; les testeurs peuvent ne pas détecter tous les problèmes du monde réel. | Les utilisateurs de la production jouent le rôle de testeurs et découvrent rapidement les problèmes du monde réel. |
| Cas d’utilisation notables | Netflix, Amazon, Etsy, LinkedIn et IBM utilisent Blue-Green. | Netflix et Google utilisent Canary, ainsi que des tests automatisés et des déploiements progressifs. |
Déploiement Blue-Green et déploiement Canary : Caractéristiques
Déploiement
Le déploiement bleu-vert implique deux environnements (bleu et vert). Mais en même temps, les deux environnements sont constamment synchronisés en termes de données. Cela augmente la demande de processus de synchronisation permanente des données entre les deux environnements.
Une fois que la nouvelle version est testée et considérée comme prête, le trafic est transféré de l’environnement actif vers l’environnement inactif, qui devient ainsi le nouvel environnement actif.
Vous ne perdez pas de temps à déployer le nouveau code et il n’y a pas de temps d’arrêt de la production. Tous les utilisateurs de la production travaillent en permanence sur l’environnement actif et ne remarquent même pas le basculement.
Le déploiement canarien consiste à déployer une nouvelle version du logiciel auprès d’un petit sous-ensemble d’utilisateurs, tandis que la plupart des utilisateurs ou des serveurs continuent d’utiliser la version actuelle. Il s’agit d’un déploiement progressif plutôt que d’un changement complet. Les testeurs sont, dans ce cas, des utilisateurs directs de la production, même s’il ne s’agit que d’un sous-ensemble défini d’entre eux. Ce groupe teste activement la nouvelle version avec les processus de production et, une fois qu’elle est stable, la nouvelle version est diffusée au reste des utilisateurs.
Le déploiement bleu-vert sera votre choix si la haute disponibilité est la priorité. Vous pouvez privilégier le déploiement Canary si vous préférez un retour d’information plus rapide et un déploiement plus contrôlé (bien que plus lent).
Atténuation de la différence de risque
Le déploiement Blue-Green atténue le risque d’échec de la mise à jour en passant rapidement à la version précédente stable. Pour chaque utilisateur et instantanément. Évidemment, il existe toujours un risque que les nouvelles fonctionnalités soient retardées pour les utilisateurs en cas de retour en arrière, mais au moins aucun utilisateur ne sera bloqué en raison de problèmes critiques liés à la nouvelle version.
La stratégie d’atténuation des risques liés au déploiement de Canary repose sur la réduction progressive des risques de problèmes. Étant donné que les nouvelles fonctionnalités sont mises à la disposition d’un sous-groupe d’utilisateurs de production, ceux-ci utilisent déjà cette version du logiciel quelque temps avant que la version ne soit diffusée à l’ensemble des utilisateurs. La probabilité est très élevée que ces premiers utilisateurs détectent rapidement les problèmes.
Différence dans l’approche des tests
Le déploiement bleu-vert laisse les processus de test uniquement à l’environnement inactif. Ici, les développeurs, les testeurs et les différentes parties prenantes peuvent tester ce qu’ils veulent. Vous pouvez toujours vous attendre à un comportement similaire à celui des tests exécutés directement sur l’environnement de production actif (puisque les données et la configuration sont toujours synchronisées entre les deux environnements).
Ce sont donc vos testeurs qui effectuent les tests, et il est toujours possible qu’ils ne détectent pas tous les problèmes que les vrais utilisateurs de la production pourraient rencontrer. Cependant, ce n’est pas vraiment un problème puisque le passage entre les environnements inactif et actif est toujours rapide. Vous pouvez ensuite laisser les développeurs résoudre le problème et recommencer le changement.
Le déploiement Canary vous permet d’utiliser des utilisateurs de la production comme testeurs. Ces utilisateurs ont généralement tendance à trouver plus de problèmes en moins de temps. Ils exécutent simplement les processus d’entreprise quotidiens de bout en bout.
Non seulement parce qu’ils ont construit de tels scénarios et cas de test, mais aussi parce qu’ils doivent le faire de toute façon. Vous risquez que certains membres du groupe aient de graves problèmes pendant un certain temps. Mais cela n’a pas d’impact sur la majorité des utilisateurs et l’équipe de développement peut se concentrer immédiatement sur les problèmes réels les plus graves.
Expérience et cas d’utilisation
Voici quelques-uns des cas d’utilisation connus où de tels déploiements ont déjà été effectués avec succès :
- Netflix utilise le déploiement Blue-Green pour déployer de nouvelles versions de son service de streaming.
- Amazon et Etsy utilisent le déploiement Blue-Green pour déployer de nouvelles versions de leur plateforme de commerce électronique.
- LinkedIn utilise le déploiement Blue-Green pour déployer de nouvelles versions de sa plateforme de réseau social.
- IBM utilise le déploiement Blue-Green pour déployer de nouvelles versions de sa plateforme cloud.
- Netflix utilise également Canary Deployment pour déployer les changements apportés à son service de streaming. L’entreprise utilise une combinaison de tests automatisés, d’indicateurs de fonctionnalités et de tests A/B pour déployer lentement les changements.
- Google utilise Canary Deployment pour apporter des modifications à ses services en nuage. De la même manière, l’entreprise utilise les avantages des tests automatisés, de la division du trafic et de l’inclusion de la surveillance pour déployer progressivement les changements auprès d’un petit sous-ensemble d’utilisateurs avant de les déployer auprès de tous les utilisateurs.
Meilleures pratiques et tendances futures
L’automatisation est la clé, et les pipelines DevOps sont sans aucun doute l’avenir des processus de déploiement. Il s’agit de processus entièrement automatiques contenant des étapes telles que
- Création ou mise à jour des environnements cibles en termes de services, de données, d’utilisateurs ou de privilèges.
- Déploiement automatisé de versions complètes/delta des codes sources directement à partir du référentiel de code.
- Mise à jour du schéma de la base de données et rafraîchissement des données.
- Exécution automatisée de tests directement pendant les activités de déploiement.
- Processus de retour en arrière automatisé en cas d’échec d’un cas de test important.
- Élimination de toutes les étapes d’intervention manuelle.
Une fois que vous disposez de ces pipelines de déploiement, vous pouvez ajouter les processus Canary ou Blue-Green ou tout autre processus de votre choix. Il ne s’agit là que de deux exemples parmi d’autres qui ont déjà fait leurs preuves. Mais ce ne sont que des cadres philosophiques pour résoudre la plupart des problèmes liés aux activités de déploiement. Il n’est même pas difficile de passer de l’un à l’autre au fil du temps ou d’utiliser une combinaison des deux.
Le mot de la fin
S’en tenir à des procédures de déploiement manuelles est le signe d’un processus de développement ou même d’une équipe qui n’a pas encore atteint sa maturité. D’autre part, cela peut révéler à quel point l’entreprise est inflexible et monolithique en termes de livraison de logiciels. Dans les deux cas, cela signifie beaucoup de travail pour corriger le statu quo. Essayez donc de mettre en œuvre les stratégies de déploiement mentionnées ci-dessus pour votre projet.
Ensuite, découvrez comment déployer des applications dans Kubernetes.