Déployer des infrastructures et des applications

Le déploiement sur différents serveurs

Le déploiement sur différents serveurs est une pratique courante dans le domaine de l’informatique et du développement logiciel, notamment pour des raisons de performance, de redondance, de disponibilité, de scalabilité et de répartition de charge. Cette approche est largement adoptée pour garantir un fonctionnement stable et optimal des applications, surtout lorsque celles-ci doivent gérer de grandes charges de travail ou nécessitent une haute disponibilité. Nous en avions parlé au chapitre « Architecturer des systèmes et des données », section « La redondance des composants et des données ».

Les raisons du déploiement sur différents serveurs sont multiples :

Performance et scalabilité : répartir les charges de travail sur plusieurs serveurs permet de réduire la pression exercée sur chaque serveur individuel, améliorant ainsi les performances globales du système. De plus, cela facilite l’ajout de capacités supplémentaires pour faire face à une augmentation de la demande.
Redondance et haute disponibilité : en déployant sur plusieurs serveurs, on crée un environnement résilient. Si l’un des serveurs tombe en panne, les autres peuvent prendre...

L’automatisation des déploiements

1. Les avantages des déploiements automatisés

Plus le périmètre des nouvelles fonctionnalités à incorporer au sein d’une application est petit, plus il est simple de tester ces fonctionnalités et plus le nombre de déploiements et de tests à effectuer augmente. Dans le monde du logiciel, il est d’ailleurs bien souvent nécessaire de compiler des versions d’une même application ou d’un même module ayant pour cible différentes plateformes et différentes configurations, ce qui augmente d’autant plus le nombre d’actions nécessaires.

Automatiser une suite d’actions permet d’effectuer ces actions autant de fois que souhaité, de manière répétitive et sans intervention humaine et a pour but d’augmenter le nombre d’occurrences, mais aussi de fiabiliser le processus en lui-même. Il s’agit en effet de réduire les étapes intermédiaires dans la séquence et le besoin de synchronisation entre ces étapes. Dans la majorité des cas, l’ensemble des actions nécessaires au déploiement d’une application peut être automatisé et permet dès lors de bénéficier des avantages qui en découlent.

La mise en place d’une telle automatisation permet également d’utiliser des techniques et des technologies communes au travers des déploiements et d’augmenter la traçabilité de ces actions et des livrables qui en résultent. Par ailleurs, les équipes informatiques peuvent dès lors se focaliser sur la définition de procédures automatisées qui seront enregistrées au sein d’un registre afin de pouvoir être réutilisées. Les équipes informatiques produisent désormais de la valeur lors de leurs activités alors qu’elles effectuaient des actions répétitives sans grande valeur jusqu’alors.

Enfin, un bénéfice souvent peu évalué est la réduction des coûts notamment de backups étant donné la possibilité de « monter » un serveur ou un environnement en peu de temps.

2. De l’intégration...

Les pipelines de livraison

Les pipelines de livraison, aussi connu sous le nom de pipelines CI/CD, c’est-à-dire Continuous Integration/Continuous Deployment ou encore intégration continue/déploiement continu, est un processus qui permet de mettre en production rapidement des modules construits sur la base du code. Cette approche est totalement automatisée, ce qui garantit la fiabilité et la répétition, mais aussi cette même rapidité.

La gestion du code source : l’utilisation d’un serveur de sources permet de garder l’ensemble des versions d’un fichier de code. De plus il permet la gestion de branches diverses. Généralement, il y a la possibilité de déclencher des actions en fonction des opérations faites sur les branches, principalement la branche principale, que ce soient des tests unitaires automatiques ou même la construction d’artefacts et la livraison de package.
La construction d’artefacts : le code source est rarement utilisé tel quel sur les serveurs. Il faut donc créer des artefacts prêts à être assemblés et déployés.
La publication d’artefacts dans un gestionnaire d’artefacts : une fois le module créé, il est possible de l’utiliser tout de suite. Une autre approche, meilleure en bien des points, propose de stocker...

Une architecture pour la compilation et le déploiement

Compiler une application ne requiert que bien peu de choses : du code et un compilateur. Les développeurs disposent généralement des deux sur leur machine de développement. Cependant, quand il s’agit de collaborer sur un même projet, mais aussi de gérer les compilations régulières et les déploiements associés, alors des outils proprement architecturés s’avèrent fort utiles.

Chaque ligne individuelle de code est stockée dans un contrôle de source unique, mais les développeurs se connectent à ce contrôleur de source via un proxy situé au plus proche d’eux. Le proxy a pour responsabilité de réduire la charge sur le réseau et la durée associée à la récupération du code.

Lorsque le code est publié dans le contrôle de source, le code et l’application qui correspond se doivent d’être testés afin de vérifier la non-régression, mais aussi afin de tester les fonctionnalités ou encore les interopérabilités. Pour ce faire, un agent de compilation est automatiquement sélectionné parmi tous les agents enregistrés. La sélection est basée sur les capacités requises (composants installés) et la disponibilité...