Déploiement progressif
Par déploiement progressif (en anglais : rolling deployment), on entend une diffusion échelonnée des logiciels sur plusieurs phases, qui fait généralement intervenir un ou plusieurs serveurs exécutant une ou plusieurs fonctions au sein d'un cluster de serveurs.
Plutôt que de mettre à jour tous les serveurs ou tous les niveaux simultanément, l'organisation installe le progiciel mis à jour sur un seul serveur ou sous-ensemble de serveurs à la fois. Un déploiement progressif permet de réduire le temps d'arrêt d'une application et d'éviter les conséquences ou les erreurs inattendues résultant des mises à jour logicielles.
Lors d'une mise à jour logicielle classique, un serveur d'applications est arrêté pendant la mise à jour et le test du logiciel, puis remis en service. L'application risque de rester inaccessible pendant un bon moment, surtout si des erreurs ou des problèmes inattendus obligent un développeur à réinstaller une version antérieure.
En cas de mise à niveau progressive, seule la capacité serveur liée à une application est immobilisée à un moment donné.
Prenons l'exemple d'une application à trois niveaux, comprenant le front end, le back end et la base de données, déployée sur trois nœuds à chaque niveau. Chacun des trois nœuds du serveur d'application reçoit le trafic par le biais d'un équilibreur de charge. En cas de mise à jour traditionnelle, l'équilibreur de charge suspend tout le trafic applicatif pour arrêter et mettre à jour les serveurs. En cas de déploiement progressif, l'organisation se contente d'arrêter l'un des nœuds à chaque niveau, l'équilibreur de charge étant configuré de manière à rediriger le trafic vers les serveurs restants qui exécutent toujours la version logicielle éprouvée en vigueur. Les serveurs inactifs sont mis à jour et soumis aux tests, pendant que les serveurs actifs prennent en charge le trafic utilisateur.
On parle de taille de fenêtre pour désigner le nombre de cibles visées simultanément par le déploiement progressif. Si elle est de un, le déploiement porte sur une seule cible, et le déploiement suivant ne peut commencer qu'à l'issue de celui-ci. Si elle est de trois, le déploiement porte sur trois serveurs à la fois. En toute logique, il faut agrandir la taille de fenêtre en présence d'un grand cluster.
Un déploiement progressif peut comporter une phase de test au cours de laquelle l'équilibreur de charge achemine uniquement un trafic limité ou de test pendant la configuration et la validation du nouveau logiciel. Les utilisateurs ne s'aperçoivent de rien, car ils accèdent à l'application à partir des serveurs restants non encore mis à jour.
Une fois que le logiciel réussit les tests, le serveur est remis en service, puis le processus se répète sur un autre nœud, qui est alors arrêté, jusqu'à ce que tous les nœuds de serveur du cluster soient mis à jour et exécutent la version voulue de l'application. L'application reste disponible pendant toute la durée du déploiement progressif.
Avec ce mode de déploiement, la rétrocompatibilité sur l'ensemble de la pile reste la préoccupation majeure. En effet, certains nœuds risquent d'exécuter des versions plus récentes alors que d'autres en sont restés à des versions plus anciennes. L'organisation doit s'assurer que les anciennes versions des composants web ou applicatifs fonctionnent avec le nouveau schéma de base de données, ou inversement.
En cas de déploiement progressif, la persistance des sessions risque de laisser à désirer si le trafic utilisateur est acheminé vers des serveurs exécutant des versions logicielles différentes, les résultats risquant alors d'être imprévisibles et indésirables. Les équilibreurs de charge doivent assurer la persistance des utilisateurs de sorte que le trafic utilisateur continue à transiter par le même serveur d'application. Il convient de plus d'invoquer le partage de sessions au maximum, pour que la session utilisateur se poursuive sur un autre serveur, au cas où le serveur assurant actuellement la persistance des utilisateurs serait arrêté en vue de sa mise à jour.
Un déploiement progressif ne mobilise par autant de ressources informatiques qu'un déploiement bleu/vert, où la mise à jour a lieu sur l'intégralité d'un premier environnement de production, alors qu'un deuxième identique exécute encore la version logicielle précédente.
Un déploiement progressif n'a rien à voir avec un déploiement par étapes. Un déploiement par étapes se déroule sur une période plus longue, et un utilisateur sait qu'il travaille sur différentes versions logicielles pour recueillir des réactions ou tester les performances avant le déploiement général d'une modification.
