Stratégies de déploiement

Les pratiques DevOps impliquent des cycles de mise en production fréquents qui profitent aux organisations et à leurs utilisateurs finaux de nombreuses façons. Dans la mesure où les déploiements individuels sont plus petits, ils sont plus rapides et moins stressants, mais les choses peuvent tout de même dégénérer. Pour réduire les risques de problème, vous devez adopter une stratégie de déploiement qui répond le mieux aux besoins de votre organisation.

Vous connaissez déjà l’approche du « déploiement de type épopée », que certains appellent la stratégie du « big bang ». Vous savez que cette méthode ne fonctionne pas bien pour les applications modernes. Il existe un certain nombre d’autres stratégies de déploiement qui sont devenues populaires dans le contexte des opérations modernes, chacune ayant ses propres forces et faiblesses selon la situation.

Stratégie de déploiement propagé

La stratégie de déploiement propagé adopte une approche progressive pour l’introduction de nouvelles versions du code. La nouvelle version est progressive sur une période de temps, augmentant progressivement les instances du nouveau code tout en réduisant les instances de l’ancien. Par conséquent, les anciennes et nouvelles instances coexistent entre la cible de déploiement pendant le déploiement. Par exemple, vous pouvez mettre à niveau le logiciel sur un serveur, une machine virtuelle ou un conteneur à la fois.

Cette stratégie présente l’avantage suivant : vous pouvez superviser le nouveau code dans l’environnement de production pour vérifier qu’il respecte vos critères de performances, de sécurité, de fiabilité et d’autres standards avant qu’il ne soit largement déployé.

Stratégie de déploiement bleu/vert

La stratégie de déploiement bleu-vert utilise deux environnements distincts qui sont conservés autant que possible et qui sont tous deux capables de servir le trafic de production. Un environnement gère la charge de production actuelle tandis que l’autre héberge la nouvelle version du logiciel afin de pouvoir la valider avant de déplacer le trafic. Lorsque vous êtes certain que la nouvelle version est saine, vous pouvez basculer le trafic en une seule fois ou augmenter progressivement la proportion du trafic vers le nouvel environnement tout en surveillant les résultats.

L’environnement bleu est celui qui sert actuellement le trafic de production. L’environnement vert est son équivalent parallèle. Vous déployez d’abord la nouvelle version du logiciel sur vert, la validez, puis redirigez le trafic de production de bleu vers vert. Une fois le basculement terminé, les rôles peuvent s’inverser : l'environnement vert devient l'environnement en production, et l'environnement bleu peut être préparé pour la prochaine version.

Un avantage de cette stratégie est que vous pouvez basculer rapidement, souvent avec peu ou pas de temps d’arrêt. Il est également relativement facile de rediriger le trafic vers l’environnement précédent si un problème se produit une fois que le nouvel environnement est en cours de vie.

Stratégie de déploiement canari

La stratégie de déploiement canari combine certains éléments du déploiement progressif avec ceux du déploiement blue-green. Vous ne faites pas le basculement en une seule fois. Au lieu de cela, vous déployez la nouvelle version sur une partie limitée de l’environnement de production, puis vous transférez progressivement tout le trafic vers la nouvelle version. Le logiciel est déployé par étapes incrémentielles sur un nombre limité d’instances ou d’utilisateurs jusqu’à ce que vous ayez vérifié qu’il fonctionne correctement. Le déploiement est ensuite propagé au reste de l’infrastructure.

Le nom vient de la pratique consistant à utiliser des canaris dans les mines de charbon comme système d’alerte précoce. Dans un déploiement canari, vous pouvez effectuer des tests automatisés et utiliser les fonctionnalités de surveillance et d'analytique afin de disposer d’une alerte précoce pour les problèmes liés à la nouvelle version dans le sous-ensemble d’instances ou d’utilisateurs. Ainsi, l’environnement de production tout entier n’est pas affecté.

Indicateurs de fonctionnalités

L’idée de l’indicateur de fonctionnalité est une autre stratégie qui nécessite un peu plus de sophistication de la part des développeurs. Au lieu d’avoir deux versions distinctes du même logiciel (un ancien et un nouveau avec de nouvelles fonctionnalités), vous envoyez une version unique qui contient l’ancien comportement plus les nouvelles modifications. Les nouvelles modifications sont dormantes par défaut et ne sont pas visibles tant que l'« indicateur de fonctionnalité » correspondant n’est pas activé. Un indicateur peut prendre de nombreuses formes, notamment une ligne dans un fichier de configuration, un argument de ligne de commande ou une valeur récupérée à partir d’un service de configuration distant et évaluée au moment de l’exécution.

Un atout majeur de cette approche est la facilité de revenir en arrière si un problème se produit et la facilité de déploiement progressif des modifications. Dans de nombreux cas, vous n’avez pas besoin d’expédier une nouvelle version pour exposer ou masquer la fonctionnalité. Vous pouvez simplement désactiver ou activer l’indicateur approprié et laisser l’application en cours d’exécution réagir au nouveau paramètre.

Sur Azure, la fonctionnalité de gestion feature de Azure App Configuration fournit un magasin d’indicateurs de fonctionnalités managé que vos applications peuvent lire au moment de l’exécution, avec la prise en charge du SDK pour .NET, Java, Python, JavaScript et Go.

Déploiements en anneau

Un déploiement en anneau est une forme structurée de déploiement progressif largement utilisé à l’intérieur de Microsoft et Azure. Le nouveau code est libéré dans une séquence de « anneaux ». Par exemple, un anneau interne ou dog food, un anneau d’adoption précoce, un large anneau de déploiement et enfin un anneau de disponibilité générale. Chaque anneau est plus grand que le précédent, et le déploiement avance uniquement vers l'anneau suivant après que le signal d'intégrité de l'anneau actuel réponde aux critères définis. Les déploiements basés sur des anneaux combinent l’exposition progressive des déploiements canary avec des audiences nommées explicites et des portes d’approbation entre les anneaux.

Livraison progressive

Les stratégies ci-dessus (canari, en anneau et indicateurs de caractéristiques) sont souvent regroupées sous le terme de livraison progressive. L’idée unifiante est qu’une version est présentée à un public croissant et contrôlé, équipée de indicateurs de santé et économiques, et soit avancée soit renversée automatiquement en fonction de ces signaux. La livraison progressive est de plus en plus le modèle par défaut pour les services cloud à haute fiabilité, car il limite le rayon d’explosion de toute modification individuelle.

Bonnes pratiques de déploiement

Quelle que soit la stratégie de déploiement que vous utilisez, certaines bonnes pratiques vous aident à réduire les risques lors du déploiement de nouveaux logiciels ou d’une nouvelle version de logiciels existants :

• Utilisez des outils appropriés, tels que Azure Pipelines ou GitHub Actions, pour créer un pipeline d’intégration et de déploiement continus.

• Intégrez des tests automatisés.

• Utilisez des canaux de communication pour informer les parties appropriées des résultats des tests. Par exemple, alertez les équipes lorsque les déploiements échouent ou rencontrent des problèmes.

• Supervisez les problèmes immédiatement après le déploiement.

• Ayez un plan de retour si une nouvelle version ne passe pas les vérifications d’intégrité et ne fonctionne pas correctement.