Environnement de déploiement

Dans le déploiement de logiciels , un environnement ou un niveau est un système informatique ou un ensemble de systèmes dans lequel un programme informatique ou un composant logiciel est déployé et exécuté. Dans les cas simples, comme le développement et l'exécution immédiate d'un programme sur la même machine, il peut y avoir un seul environnement, mais dans l'utilisation industrielle, l' environnement de développement (où les modifications sont initialement apportées) et l'environnement de production (ce que les utilisateurs finaux utilisent) sont séparés, souvent avec plusieurs étapes entre les deux. Ce processus structuré de gestion des versions permet un déploiement (rollout) par phases, des tests et une restauration en cas de problème.

Les environnements peuvent varier considérablement en taille : l'environnement de développement est généralement le poste de travail d'un développeur individuel, tandis que l'environnement de production peut être un réseau de nombreuses machines réparties géographiquement dans des centres de données ou des machines virtuelles dans le cloud computing . Le code, les données et la configuration peuvent être déployés en parallèle et ne doivent pas nécessairement se connecter au niveau correspondant. Par exemple, le code de préproduction peut se connecter à une base de données de production.

Les architectures de déploiement varient considérablement, mais, en gros, les niveaux sont délimités par le début du développement (DEV) et la fin de la production (PROD). Une architecture courante à 4 niveaux est le développement, les tests, le modèle, la production (DEV, TEST, MODL, PROD), les logiciels étant déployés sur chacun d'eux dans l'ordre. D'autres environnements courants incluent le contrôle qualité (QC), pour les tests d'acceptation ; le sandbox ou l'expérimental (EXP), pour les expériences qui ne sont pas destinées à passer à la production ; et la reprise après sinistre, pour fournir une solution de secours immédiate en cas de problèmes de production. Une autre architecture courante est le développement, les tests, l'acceptation et la production (DTAP).

Ce langage est particulièrement adapté aux programmes serveur, où les serveurs s'exécutent dans un centre de données distant ; pour le code qui s'exécute sur l'appareil d'un utilisateur final, comme les applications (apps) ou les clients, on peut plutôt se référer à l'environnement utilisateur (USER) ou à l'environnement local (LOCAL).

Les définitions et limites exactes entre les environnements varient : le test peut être considéré comme faisant partie du développement, l'acceptation peut être considérée comme faisant partie du test, de la phase ou être distincte, etc. Les niveaux principaux progressent dans l'ordre, les nouvelles versions étant déployées ( déployées ou poussées ) vers chacun à tour de rôle. Les niveaux expérimentaux et de récupération, s'ils sont présents, sont en dehors de ce flux : les versions expérimentales sont terminales, tandis que la récupération est généralement une ancienne version ou une version dupliquée de la production, déployée après la production. En cas de problème, on peut revenir à l'ancienne version, le plus simplement en poussant l'ancienne version comme s'il s'agissait d'une nouvelle version. La dernière étape, le déploiement en production (« push to prod »), est la plus sensible, car tout problème entraîne un impact immédiat sur l'utilisateur. Pour cette raison, cela est souvent traité différemment, au moins en étant surveillé plus attentivement et, dans certains cas, avec un déploiement progressif ou en ne nécessitant qu'un simple basculement d'un interrupteur, permettant une restauration rapide. Il est préférable d'éviter un nom comme Assurance Qualité (AQ) ; l'AQ ne signifie pas test logiciel. Les tests sont importants, mais ils sont différents de l'AQ.

Parfois, le déploiement est effectué en dehors de ce processus habituel, principalement pour apporter des modifications urgentes ou relativement mineures, sans nécessiter une version complète. Il peut s'agir d'un seul patch , d'un gros Service Pack ou d'un petit correctif .

Les environnements peuvent être de tailles très différentes : le développement est généralement le poste de travail d'un développeur individuel (bien qu'il puisse y avoir des milliers de développeurs), tandis que la production peut être constituée de nombreuses machines réparties géographiquement ; les tests et le contrôle qualité peuvent être petits ou grands, selon les ressources qui leur sont consacrées, et la préparation peut aller d'une seule machine (similaire à Canary) à une copie exacte de la production.

Le tableau ci-dessous décrit une liste finement divisée de niveaux .

L'environnement de développement (dev) est l'environnement dans lequel les modifications apportées au logiciel sont développées, plus simplement le poste de travail d'un développeur individuel. Il diffère de l'environnement cible final de plusieurs manières : la cible peut ne pas être un ordinateur de bureau (il peut s'agir d'un smartphone, d'un système embarqué, d'une machine sans tête dans un centre de données, etc.) et, même s'il est par ailleurs similaire, l'environnement du développeur comprendra des outils de développement comme un compilateur, un environnement de développement intégré, des versions différentes ou supplémentaires de bibliothèques et de logiciels de support, etc., qui ne sont pas présents dans l'environnement d'un utilisateur.

Dans le contexte du contrôle des révisions , en particulier avec plusieurs développeurs, des distinctions plus fines sont établies : un développeur dispose d'une copie de travail du code source sur sa machine, et les modifications sont soumises au référentiel, validées soit dans le tronc, soit dans une branche, selon la méthodologie de développement. L'environnement sur un poste de travail individuel, dans lequel les modifications sont traitées et testées, peut être appelé environnement local ou sandbox . La création de la copie du code source du référentiel dans un environnement propre est une étape distincte, faisant partie de l'intégration (intégration de modifications disparates), et cet environnement peut être appelé environnement d'intégration ou environnement de développement ; dans l'intégration continue, cela se fait fréquemment, aussi souvent que pour chaque révision. Le concept de niveau de code source de « validation d'une modification dans le référentiel », suivi de la construction du tronc ou de la branche, correspond à la poussée vers la publication du local (environnement du développeur individuel) vers l'intégration (construction propre) ; une mauvaise publication à cette étape signifie qu'une modification a cassé la construction, et l'annulation de la publication correspond soit à l'annulation de toutes les modifications à partir de ce point, soit à l'annulation uniquement de la modification cassée, si possible.

L'environnement de test a pour objectif de permettre aux testeurs humains d'exécuter du code nouveau ou modifié via des contrôles automatisés ou des techniques non automatisées. Une fois que le développeur a accepté le nouveau code et les nouvelles configurations via des tests unitaires dans l'environnement de développement, les éléments sont déplacés vers un ou plusieurs environnements de test. En cas d'échec du test, l'environnement de test peut supprimer le code défectueux des plates-formes de test, contacter le développeur responsable et fournir des journaux de test et de résultats détaillés. Si tous les tests réussissent, l'environnement de test ou un cadre d'intégration continue contrôlant les tests peut automatiquement promouvoir le code vers l'environnement de déploiement suivant.

Différents types de tests suggèrent différents types d'environnements de test, dont certains ou tous peuvent être virtualisés pour permettre des tests rapides et parallèles. Par exemple, des tests d'interface utilisateur automatisés peuvent être effectués sur plusieurs systèmes d'exploitation et écrans virtuels (réels ou virtuels). Les tests de performances peuvent nécessiter une configuration matérielle de base physique normalisée, afin que les résultats des tests de performances puissent être comparés au fil du temps. Les tests de disponibilité ou de durabilité peuvent dépendre de simulateurs de défaillance dans le matériel virtuel et les réseaux virtuels.

Les tests peuvent être en série (les uns après les autres) ou en parallèle (certains ou tous en même temps) selon la sophistication de l'environnement de test. Un objectif important des pratiques de développement logiciel agiles et d'autres pratiques de haute productivité est de réduire le temps entre la conception ou la spécification du logiciel et sa livraison en production. Les environnements de test hautement automatisés et parallélisés contribuent de manière importante au développement rapide de logiciels.

Un environnement de test, de préparation ou de préproduction est un environnement de test qui ressemble exactement à un environnement de production. Il cherche à refléter un environnement de production réel aussi fidèlement que possible et peut se connecter à d'autres services et données de production, tels que des bases de données. Par exemple, les serveurs seront exécutés sur des machines distantes, plutôt que localement (comme sur le poste de travail d'un développeur pendant le développement, ou sur une seule machine de test pendant le test), ce qui permet de tester les effets de la mise en réseau sur le système.

L'utilisation principale d'un environnement de test consiste à tester tous les scripts et procédures d'installation/configuration/migration avant leur application à un environnement de production. Cela garantit que toutes les mises à niveau majeures et mineures d'un environnement de production sont effectuées de manière fiable, sans erreur et dans un minimum de temps.

Une autre utilisation importante de la mise en scène est le test de performance , en particulier le test de charge , car il est souvent sensible à l'environnement.

La mise en scène est également utilisée par certaines organisations pour prévisualiser de nouvelles fonctionnalités afin de sélectionner des clients ou pour valider des intégrations avec des versions en direct de dépendances externes.

L'environnement de production est également appelé environnement live , en particulier pour les serveurs, car c'est l'environnement avec lequel les utilisateurs interagissent directement.

Le déploiement en production est l'étape la plus sensible. Il peut être effectué en déployant directement un nouveau code (en écrasant l'ancien code, de sorte qu'une seule copie soit présente à la fois) ou en déployant une modification de configuration. Cela peut prendre différentes formes : déployer une installation parallèle d'une nouvelle version de code et basculer entre elles avec une modification de configuration ; déployer une nouvelle version de code avec l'ancien comportement et un indicateur de fonctionnalité , et basculer vers le nouveau comportement avec une modification de configuration qui effectue un basculement d'indicateur ; ou en déployant des serveurs distincts (l'un exécutant l'ancien code, l'autre le nouveau) et en redirigeant le trafic de l'ancien vers le nouveau avec une modification de configuration au niveau du routage du trafic. Ces opérations peuvent à leur tour être effectuées en une seule fois ou progressivement, par phases.

Le déploiement d'une nouvelle version nécessite généralement un redémarrage, à moins que l'échange à chaud ne soit possible, et nécessite donc soit une interruption de service (habituelle pour les logiciels utilisateur, où les applications sont redémarrées), soit une redondance - soit le redémarrage lent des instances derrière un équilibreur de charge, soit le démarrage de nouveaux serveurs à l'avance, puis la simple redirection du trafic vers les nouveaux serveurs.

Lors du déploiement d'une nouvelle version en production, plutôt que de la déployer immédiatement sur toutes les instances ou tous les utilisateurs, elle peut d'abord être déployée sur une seule instance ou une fraction d'utilisateurs, puis déployée sur tous ou déployée progressivement par phases, afin de détecter les problèmes de dernière minute. Cette méthode est similaire à la mise en scène, sauf qu'elle est réellement effectuée en production et est appelée version canari , par analogie avec l'extraction de charbon. Cela ajoute de la complexité en raison de l'exécution simultanée de plusieurs versions, et se termine donc généralement rapidement, pour éviter les problèmes de compatibilité.

Le développement, la préparation et la production sont des variables d'environnement connues et documentées dans ASP.NET Core . Selon la variable définie, un code différent est exécuté et un contenu rendu, et différents paramètres de sécurité et de débogage sont appliqués.