Isolement de l’environnement

De nombreuses organisations construisent des systèmes informatiques en utilisant une approche multi-environnement. Qu’elles se réfèrent à ces systèmes en tant que développement, pré-production, assurance qualité, acceptation ou production, ces termes sont utilisés pour désigner différents environnements qui ont des caractéristiques distinctes et sont utilisés à des fins différentes. Il n’existe pas de définition standard des environnements, ou de la façon dont ils sont utilisés, si ce n’est un spectre général qui s’étend des environnements de développement de niveau « inférieur » à un environnement final de « production ». Dans tous les cas, la définition et les contraintes de ces environnements sont entièrement précisées par l’organisation. Elles doivent correspondre à d’autres processus ou normes métier et prendre en charge les exigences métier de l’organisation. Il n’existe pas de bonne pratique unique dans ce domaine (car les systèmes ont des exigences différentes), mais la section suivante fournit des conseils sur la façon d’aborder les sujets d’isolement de l’environnement dans le processus d’architecture.

Les utilisateurs des systèmes ArcGIS s’attendent à ce que le système soit disponible lorsqu’ils doivent accomplir leurs tâches quotidiennes. Toutefois, des modifications importantes apportées aux configurations du système peuvent entraîner des temps d’arrêt si ces modifications ne sont pas développées et testées en toute sécurité dans des environnements distincts de la production. L’isolement des environnements informatiques est une approche permettant de maintenir la fiabilité et la disponibilité du système en créant des systèmes distincts pour les activités de production, de test et de développement. Bien que toutes les modifications (telles que la configuration de l’application) n’aient pas besoin d’être testées dans chaque environnement, des mises à jour importantes et de nouvelles fonctionnalités peuvent bénéficier d’une approche structurée de ce thème.

Dans certains cas, les attentes des utilisateurs peuvent être documentées dans un contrat de niveau de service (SLA). Il peut aussi s’agir simplement d’une attente quant au moment où le système doit être disponible. Tenez compte des attentes de vos utilisateurs et des besoins de l’entreprise lorsque vous décidez du niveau d’isolement de l’environnement et de la gouvernance nécessaire pour gérer les modifications du système.

Recommandations

Pour maintenir au mieux la fiabilité et la disponibilité du système pour vos utilisateurs, les bonnes pratiques suivantes s’appliquent :

1. Si cela est possible pour l’organisation, mettez en œuvre des environnements de production, de préproduction et de développement isolés.
2. Testez les modifications du système telles que les correctifs, les mises à niveau ou les modifications des paramètres du système d’exploitation dans un environnement de préproduction avant d’apporter des modifications à l’environnement de production.
3. Utilisez un environnement de développement pour développer et tester de nouvelles fonctionnalités sans affecter les utilisateurs dans d’autres environnements.
4. Suivez les pratiques de gouvernance standard lors de la promotion du contenu et des fonctionnalités dans plusieurs environnements.
5. Ayez un plan sur la façon dont la promotion du contenu est gérée : qui examine le contenu, qui l’approuve et comment est-il déplacé ?

Objectifs environnementaux

Dans le cadre de ces recommandations de bonnes pratiques, les trois définitions d’environnement suivantes sont largement utilisées par Esri et nos clients.

1. L’environnement de production est le système en direct qui prend en charge les utilisateurs finaux. Les exigences en matière de disponibilité sont généralement définies par un SLA et satisfaites par une gestion des modifications et une gouvernance efficaces. En règle générale, il convient de ne pas apporter de modifications à un logiciel, une application, une configuration ou un réseau sans les avoir été testées dans un environnement de préproduction. Le personnel qui travaille dans l’environnement de production est généralement celui qui consulte des applications pour prendre des décisions, collecter et modifier des informations au bureau ou sur le terrain, et coordonner pour effectuer des tâches critiques. Cet environnement bénéficie souvent d’une surveillance accrue, peut disposer d’un matériel dédié pour garantir de bonnes performances et réclame le plus d’efforts de la part du support informatique en ce qui concerne sa maintenance.
2. Un environnement de préproduction est habituellement conçu pour refléter l’environnement de production afin de vous permettre de vérifier les modifications du système avant de les déployer en production. Le terme « refléter » est utilisé parce que le maintien d’un environnement entier identique à la production est coûteux à la fois en ressources et en soutien du personnel. Bien qu’un environnement de préproduction reflète généralement la production en termes de niveaux, de serveurs, de composants et de rôles, vous pouvez ou non exiger la même capacité de serveur individuel que pour l’environnement de production, de sorte qu’il est possible d’envisager un déploiement réduit pour réaliser des économies. Vous pouvez effectuer des tests d’acceptation par l’utilisateur, des tests de performance, des tests de charge et des formations dans un environnement de préproduction afin d’éviter tout risque pour votre système de production. Au besoin, vous pouvez même mettre en œuvre plusieurs environnements de test pour différentes activités de test et de formation. Le personnel participant à un environnement de préproduction correspond généralement à celui qui exécute des tests de charge, des tests de performance, des tests d’intégration, des tests d’assurance qualité/contrôle de la qualité, voire éventuellement des formations.
3. Un système de développement est un espace de travail dans lequel les développeurs et les analystes peuvent créer et gérer du contenu, ou apporter des modifications sans affecter un large public. Cet environnement dédié permet généralement de créer de nouvelles fonctionnalités telles que des applications, des services, des modèles de données ou des modèles de géotraitement, pour les tests d’unités et pour la conception et la création de processus métier. La taille et la complexité de cet environnement dépendent du niveau de risque généré par les modifications, du nombre de créateurs et de l’impact potentiel des pannes et des périodes d’indisponibilité du système. En règle générale, seuls les membres du personnel qui utilisent activement le contenu dans l’environnement de développement ont accès à ce système, ou il n’est généralement pas accessible au sein de l’organisation.

En fonction de la tolérance au risque de l’organisation et des règles informatiques, il peut être nécessaire de séparer davantage certains types d’activités en les plaçant en dehors des environnements de production, de préparation et de développement. Si nécessaire, vous pouvez mettre en œuvre plusieurs environnements pour différentes activités de test et de formation, telles que les suivantes :

• Assurance/contrôle qualité
• Tests d’intégration ou d’acceptation
• Tests de performances
• Tests de charge
• Formation

Avantages et coûts de l’isolement de l’environnement

L’isolement de l’environnement met votre environnement de production à l’abri des risques connus et des modifications qui peuvent avoir un impact négatif sur votre entreprise, tels que les mises à niveau, les nouveaux logiciels ou les modifications inattendues. Ainsi, vous pouvez mieux maintenir leurs fonctionnalités, leur stabilité et leurs performances. Des modifications involontaires du système peuvent empêcher les systèmes opérationnels de délivrer les capacités et les performances attendues par les utilisateurs. La mise en œuvre de ces environnements informatiques isolés permet de fournir un système stable, extensible et performant.

L’isolement de l’environnement a également des coûts, à la fois en termes de ressources informatiques (maintien de plusieurs systèmes en fonctionnement), de licences logicielles et de capital humain. En effet, un nombre croissant d’environnements nécessite un réseau de prise en charge plus étendu et davantage de personnel impliqué dans le contrôle des modifications et le déploiement. Les systèmes plus importants et plus stratégiques déploient généralement des approches d’isolement d’environnement plus complexes, mais même les petites entreprises peuvent choisir d’y recourir pour faciliter l’isolement des modifications et la protection de leurs systèmes. Il est important d’étudier les coûts découlant de ces choix et d’en informer les parties prenantes afin qu’une décision éclairée soit prise plutôt qu’un choix par défaut d’avoir plusieurs environnements simplement parce que « nous l’avons toujours fait de cette façon ».

Mise en œuvre de l’isolement de l’environnement

La gouvernance joue un rôle essentiel dans la mise en œuvre réussie de l’isolement de l’environnement. C’est la méthode qui permet d’atténuer les risques, d’optimiser les ressources et de fournir des avantages commerciaux. La gouvernance doit définir les politiques, les procédures et les techniques que les équipes utiliseront pour maintenir ces environnements et promouvoir les modifications dans ceux-ci.

Il n’existe pas d’ensemble unique de considérations ou de voie à suivre standard pour gérer l’ensemble de vos logiciels, applications, services et données dans tous les environnements. Toutefois, certaines ressources permettent de déployer des environnements de manière cohérente, telles que Chef Cookbooks, Enterprise Cloud Builder, ArcGIS Enterprise Builder, ainsi que des outils de réplication de bases de données et des paquetages de ressources. Pour en savoir plus, reportez-vous à la rubrique Outils de déploiement ArcGIS Enterprise. De plus, il est recommandé d’éviter la configuration manuelle afin de réduire le risque d’erreur humaine dans la mesure du possible. Envisagez d’utiliser PowerShell DSC for ArcGIS, ArcGIS REST API et ArcGIS API for Python pour automatiser certaines de ces tâches. Gardez à l’esprit que la création de ces scripts est une activité appropriée pour un environnement de développement.

Chaque parti pris en développement conduit naturellement à un élément qu’une personne doit savoir ou savoir faire en préproduction et en production. Appliquez de bonnes pratiques de déploiement en assurant un transfert de connaissances et/ou de compétences approprié au personnel de production afin qu’il puisse intervenir comme prévu.

Utilisation de plusieurs déploiements ArcGIS Enterprise

Certaines organisations utilisent plusieurs environnements ArcGIS Enterprise pour séparer ces différents niveaux. Il peut être difficile de déplacer et de gérer le contenu d’un environnement à l’autre de manière cohérente et réussie. Cependant, des outils sont à votre disposition pour vous aider à automatiser ces tâches. Par exemple, il existe des opérations disponibles avec ArcGIS REST API qui facilitent le déplacement de couches, de cartes et d’applications lorsqu’elles transitent dans des environnements : Exporter le contenu d’un groupe et Importer le contenu d’un groupe.

Imaginez, par exemple, que vous avez développé une application Experience Builder personnalisée qui référence une carte Web et un ensemble de couches d’entités au sein d’un groupe dans votre environnement de développement, et qu’elle est maintenant prête à être déplacée vers un système de préproduction pour une révision structurée. À cette fin, à l’aide des opérations de migration d’exportation/importation de groupe, vous devez effectuer les étapes suivantes :

1. Exportez le contenu du groupe à partir du développement dans un paquetage.
2. Ajoutez le paquetage en tant qu’élément dans votre environnement de préproduction.
3. Importez le contenu du paquetage dans un groupe au sein de l’environnement préproduction.
4. Déployez votre application personnalisée dans votre environnement d’hébergement intermédiaire et pointez la configuration vers les URL de l’environnement de préproduction.

À ce stade, les éléments du paquetage peuvent être découverts, partagés, modifiés et utilisés dans l’environnement de préproduction, comme indiqué par les paramètres du groupe de préproduction. Le même workflow peut être utilisé pour promouvoir les éléments en production lorsqu’ils sont prêts. Vous pouvez également faire appel à la génération de scripts pour ce workflow et utilisez pour cela le module GroupMigrationManager dans ArcGIS API for Python.

Déploiements bleu-vert

Le déploiement de certains types de modifications, telles qu’une mise à niveau du système ou une modification majeure de la configuration, peut s’accompagner de perturbations. Certaines organisations utilisent une stratégie appelée déploiement bleu-vert pour déployer de manière transparente les nouvelles modifications pour les utilisateurs. Un déploiement bleu-vert est une stratégie de déploiement dans laquelle vous créez deux environnements distincts, mais identiques. Un environnement (bleu) exécute la version actuelle de l’application et un environnement (vert) exécute la nouvelle version de l’application ou le nouvel ensemble de configurations. Le trafic est dirigé vers l’un ou l’autre des environnements à l’aide de mécanismes standard tels que des routeurs, des équilibreurs de charge, des proxys inverses ou des serveurs Web.

L’environnement bleu et l’environnement vert jouent à tour de rôle l’environnement de production. Un seul des environnements est actif à un instant T. Par exemple, lorsqu’une mise à niveau ArcGIS Enterprise est prête à être déployée, la mise à niveau doit d’abord être effectuée dans le système vert. Une fois que l’équipe de test est satisfaite, et que le système est entièrement opérationnel et prêt pour une utilisation en production, seule la direction du trafic provenant du proxy ou de l’équilibreur de charge change – vers le vert au lieu du bleu, sans changement perceptible pour les utilisateurs finaux de production. À ce stade, de nouveaux contenus et de nouvelles capacités seraient développés en bleu, jusqu’à ce que suffisamment de tests aient été concluants pour justifier un nouveau basculement du trafic.

Conserver deux ensembles d’environnements en permanence peut s’avérer coûteux.  Heureusement, le Cloud rend les déploiements bleu-vert plus réalisables. Les principaux fournisseurs de plateformes Cloud disposent d’outils qui permettent de monter et de démonter des infrastructures à la demande. Par exemple, vous pouvez démarrer et arrêter des serveurs avec l’infrastructure en tant que code et automatiser le temps de fonctionnement et la configuration du système de manière très détaillée.

Ultimes recommandations

La mise en œuvre de ces environnements informatiques isolés permet de fournir un système stable, extensible et performant. En tirant parti de ces environnements pour prendre en charge une gestion efficace des modifications, vous protégez votre système contre les pannes inattendues et évitez les interruptions des opérations commerciales. Au minimum, la plupart des organisations doivent disposer de deux environnements informatiques : la production et la préproduction. En effet, elles peuvent ne pas être en mesure de participer à des activités de développement personnalisées qui utiliseraient un environnement de développement, ni utiliser essentiellement des applications avec peu de code ou sans code. Cependant, vous pouvez avoir plus davantage d’environnements en fonction du goût du risque de votre organisation.

Réfléchissez à la manière dont vous allez mettre en œuvre et gérer l’isolement de l’environnement (et les activités isolées au sein de chaque environnement) le plus tôt possible. Bien qu’il n’existe pas d’approche unique face à ces choix, il existe de nombreux outils et pratiques courantes auxquels vous pouvez vous référer pour vous guider.

Une ressource supplémentaire récemment publiée couvre le concept de promotion de contenu entre les environnements, accompagné d’un exemple d’approche avec génération de script : Esri Community Post: ArcGIS Enterprise Content Promotion.