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 introduite phase par phase sur une période donnée, ce qui entraîne une augmentation progressive des instances du nouveau code et en parallèle une diminution des instances de l’ancien code. Cela signifie que les anciennes et les nouvelles instances vont coexister au sein de l’organisation. 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 séparés qui sont identiques entre eux. L’un est un environnement de test contenant la nouvelle version du logiciel, l’autre est l’environnement de production actuel. Quand vous êtes certain que le logiciel fonctionne correctement et qu’il répond à vos standards, vous pouvez effectuer un basculement complet de l’environnement de production actuel vers le nouvel environnement pour gérer désormais tout le trafic de production.

L’environnement bleu est votre environnement de production actuel. L’environnement vert en est son double exact. Vous déployez d’abord la nouvelle version du logiciel dans l’environnement vert puis, quand vous êtes prêt, vous routez le trafic des applications de l’environnement bleu vers le vert, qui est maintenant votre environnement de production.

Cette stratégie présente l’avantage suivant : vous pouvez rendre le basculement presque instantané, sans temps d’arrêt. Il est également facile de revenir à l’environnement bleu si un problème survient après avoir rendu l’environnement vert actif.

Stratégie de déploiement avec contrôle de validité

La stratégie de déploiement avec contrôle de validité combine certains éléments du déploiement propagé avec ceux du déploiement bleu/vert. 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 déploiement avec contrôle de validité, parfois appelé « déploiement canari », fait référence à la pratique qui consistait à utiliser des canaris dans les mines de charbon en tant que système d’alerte précoce. Dans un déploiement avec contrôle de validité, vous pouvez effectuer des tests automatisés et utiliser les fonctionnalités de monitoring 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, une ancienne et une nouvelle (vraisemblablement avec de nouvelles fonctionnalités), nous mettons à disposition une version du logiciel qui contient à la fois l’ancien logiciel et les changements apportés (fonctionnalités, etc.). Par défaut, les changements apportés sont inactifs et ne sont pas visibles tant que l’« indicateur de fonctionnalité » du changement apporté n’est pas activé. Cet indicateur peut prendre plusieurs formes, notamment une ligne dans un fichier config, un argument de ligne de commande, une réponse spéciale d’un serveur en ligne que le logiciel consulte au démarrage, etc.

Cette approche présente un atout majeur : nous pouvons facilement effectuer une restauration en cas de problème ou déployer lentement les changements. Nous n’avons pas besoin d’envoyer une nouvelle version release (avec tous ces éléments) à nos serveurs ou nos clients. Il nous suffit d’activer ou de désactiver l’indicateur approprié pour passer à une version antérieure ou pour effectuer la mise à niveau.

Bonnes pratiques de déploiement

Quelle que soit la stratégie de déploiement que vous utilisez, il existe des bonnes pratiques qui vous aideront à réduire les risques au moment du déploiement de nouveaux logiciels ou d’une nouvelle version de logiciels existants :

• Utilisez les outils appropriés, par exemple Azure Pipelines, pour créer un pipeline d’intégration continue et de déploiement continu.

• Intégrez des tests automatisés.

• Utilisez des canaux de communication afin de notifier aux parties concernées les résultats des tests, par exemple pour alerter les équipes en cas d’échecs ou de problèmes liés aux déploiements, etc.

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

• Prévoyez un plan de restauration si le déploiement d’une nouvelle version ne satisfait pas aux vérifications d’intégrité, ou s’il ne fonctionne pas correctement.