Qu’est-ce que le déploiement de logiciels ?

Selon Wikipédia, le « déploiement de logiciels » comprend toutes les activités qui rendent un système logiciel disponible. Le processus de déploiement général est constitué de plusieurs activités interdépendantes, où des transitions sont possibles. Chaque système logiciel est unique. Ainsi, le « déploiement » doit être interprété en tant que processus général qui doit être personnalisé en fonction d’exigences ou de caractéristiques spécifiques.

Certains utilisent les termes « déploiement » et « installation » de manière interchangeable, mais l’installation de logiciel n’est qu’une partie du processus de déploiement. Le déploiement implique beaucoup plus. Les activités de déploiement peuvent inclure les aspects suivants :

• « Mise en rack et empilement » d’un serveur.
• Déploiement d’un logiciel mis à jour sur ce serveur.
• Utilisation d’éléments tels que les scripts et l’IAC (Infrastructure as Code).
• Ou même utilisation d’un lecteur USB pour installer manuellement des logiciels sur tous les ordinateurs d’un bureau.

Le déploiement manuel de logiciels nécessite beaucoup de main-d’œuvre et sa mise à l’échelle est délicate. Grâce à l’automatisation, il est plus rentable et plus facile de garantir la cohérence quand vous déployez de nouveaux logiciels ou mettez à jour des logiciels existants dans une organisation.

Dans le cadre de ce parcours d’apprentissage, nous nous concentrons sur la façon de déployer au mieux les logiciels pour une meilleure fiabilité. Ce module traite non seulement du déploiement de logiciels mais également du déploiement de l’infrastructure cloud. Les références au déploiement d’un service ou d’une solution peuvent signifier le déploiement de logiciels, d’une infrastructure cloud, d’une configuration et de tout ce qui est nécessaire à la mise à disposition d’un système logiciel de manière fiable.

Scénario : Déploiement de type épopée

Le mot épopée renvoie à quelque chose de « grand, monumental ou vaste », mais dans le contexte de cette discussion, ce n’est pas une bonne chose. Le terme « épopée » a été inventé par Jez Humble dans son livre Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, car il représente une entreprise importante (et massivement disruptive). Voici un exemple de la façon dont cela se produit généralement :

• Une organisation développe une application commerciale. Cette application est mise à jour deux fois par an précisément.
• Au cours de ces mises à jour, toutes les nouvelles fonctionnalités, les résolutions de bogues (quelle que soit leur importance) et les mises à jour de dépendances sont déployées.
• Le premier déploiement de l’année est prévu pour le week-end de la fête du Travail, et le second a lieu le week-end après la fête du Thanksgiving.
• Chaque mise à jour est une situation où « tout le monde est sur le pont ». L’équipe d’application, l’équipe du support technique, l’équipe d’infrastructure, la direction ; tout le monde est impliqué dans le déploiement.
• Les services sont temporairement hors connexion pendant le déploiement.
• L’expérience montre que le déploiement comporte toujours un certain nombre de difficultés. De plus, il est souvent l’objet de changements liés à l’ingénierie à la demande, à la résolution des problèmes et à la gestion de la configuration.
• Il se passe rarement bien. Quand il prend fin, il ressemble généralement à un processus corrigé de toutes parts et impossible à répéter.

Il ne s’agit pas d’une bonne situation de déploiement. La méthode de déploiement de type épopée est une tâche manuelle intense qui présente un certain nombre de problèmes :

• Elle est complexe.
• Elle est stressante.
• Elle est risquée.
• Elle est lente.
• Elle n’est pas reproductible en raison de toutes les étapes complexes qu’elle comprend.
• Plusieurs experts individuels sont souvent nécessaires pour effectuer le déploiement.

Dans la mesure où ce processus est long et ardu, il doit être planifié à des moments qui entraîneront le moins de perturbations possible sur la productivité des utilisateurs, en d’autres termes, les moments susceptibles d’être gênants pour l’équipe de déploiement, par exemple les week-ends et les jours fériés.

Les membres de l’équipe peuvent être tentés de bâcler cette opération titanesque pour qu’elle soit effectuée dans les délais impartis, ce qui entraîne des erreurs de configuration. De plus, les longues périodes qui séparent les déploiements peuvent vous faire oublier la façon exacte dont les choses fonctionnent.

Dilemme du déploiement

Le déploiement de logiciels est une tâche complexe. Quand vous « accumulez » plusieurs changements majeurs, correctifs et ajouts de fonctionnalités pour les déployer en une seule fois, vous augmentez le degré de complexité ainsi que la probabilité que quelque chose se passe mal. De plus, en cas de problème, cette complexité rend plus difficile la recherche de la cause exacte du problème.

La complexité peut également créer des problèmes pour les utilisateurs finaux. En effet, ils risquent de devoir apprendre un grand nombre de nouvelles fonctionnalités tout en étant confrontés à un grand nombre de changements, sans parler des bogues introduits par la complexité du déploiement de type épopée.

Il doit forcément exister une meilleure solution, et c’est le cas. Bonne nouvelle : la traditionnelle stratégie de déploiement de type épopée n’est pas la seule option. Nous découvrirons une meilleure façon d’aborder ce processus dans l’unité suivante.