Comprendre les environnements
Les pipelines de déploiement vous permettent d’automatiser les étapes de votre processus de déploiement. Souvent, vous devez exécuter les étapes dans plusieurs environnements distincts. Dans votre entreprise de jouets, vous souhaitez passer en revue les modifications apportées à votre code avant de déployer les modifications dans votre environnement de production.
Dans cette unité, vous allez découvrir comment les environnements dans Azure Pipelines vous aident à prendre en charge votre propre workflow.
Pourquoi avez-vous plusieurs environnements ?
Les processus de déploiement effectuent des changements sur vos ressources Azure, y compris les ressources en cours d’utilisation. Le changement des ressources implique un risque, car les changements que vous déployez peuvent ne pas se comporter comme prévu. Vous pouvez même découvrir qu’ils bloquent votre configuration actuelle.
Pour réduire le risque de problèmes, une bonne pratique est de tester vos changements de manière sécurisée avant de les déployer dans votre environnement de production. Par exemple, vous pouvez déployer les changements dans un environnement hors production.
De nombreuses organisations configurent plusieurs environnements hors production où elles déploient progressivement leurs changements avant de les mettre en production. Chaque environnement hors production remplit un rôle spécifique et comporte souvent des barrières qualité spécifiques à franchir pour passer à l’environnement suivant. En cas de problème, par exemple, un test qui échoue, le déploiement s’arrête. Le niveau de confiance des changements augmente à mesure que votre déploiement passe par les différents environnements.
Les environnements courants sont les suivants :
Développement : un environnement de développement est généralement utilisé par les développeurs pour essayer leurs changements et les itérer rapidement sur leur travail.
Les environnements de développement ont souvent des contrôles minimaux pour que les membres de l’équipe puissent facilement tester leurs idées. Vous pouvez utiliser un environnement de développement pour tester un certain paramètre de configuration sur une ressource ou pour voir comment configurer de manière sécurisée un nouveau site web avec une base de données de back-end. Un grand nombre de ces changements et essais peuvent ne pas persister dans votre processus de déploiement, car vous éliminez les idées qui ne marchent pas.
Dans certaines équipes, vous pouvez même configurer un environnement de développement distinct pour chaque membre de l’équipe, afin qu’ils ne se gênent pas mutuellement quand ils travaillent sur de nouvelles fonctionnalités.
Les environnements de développement sont parfois également appelés environnements de bac à sable.
Test : un environnement de test est conçu pour exécuter des tests manuels ou automatisés sur vos changements.
Les environnements de test peuvent être utilisés dans un processus d’intégration continue. Dès que vous déployez un changement dans un environnement de test, vous pouvez lui appliquer des tests automatisés. Si tous les tests automatisés réussissent, le changement peut être fusionné dans la branche primaire du projet. Les tests automatisés vérifient généralement les fonctionnalités principales du système, ainsi que des éléments comme les violations de stratégie dans les ressources nouvellement déployées.
Vous pouvez également créer des environnements de test dédiés à des types de tests spécifiques, comme les tests de performances et de sécurité.
Intégration : un environnement d’intégration peut vous aider à tester les points d’intégration avec d’autres systèmes.
Vous pouvez simuler des transactions de bout en bout dans un environnement d’intégration. Ces tests s’exécutent souvent automatiquement, mais de nombreuses organisations font également des tests manuels sur cet environnement.
Les environnements d’intégration sont parfois également appelés environnements de test d’intégration système (SIT).
Test d’acceptation utilisateur : un environnement de test d’acceptation utilisateur (UAT) est utilisé pour la validation manuelle, généralement par les parties prenantes de l’entreprise plutôt que par les développeurs. Dans la validation manuelle, une personne parcourt toute la solution pour vérifier qu’elle se comporte comme prévu et qu’elle répond aux exigences métier nécessaires. Cette personne approuve ensuite les changements pour que le déploiement puisse continuer.
Préproduction : un environnement de préproduction est souvent le miroir de l’environnement de production, avec la même configuration et les mêmes références SKU de ressources. Il est utilisé comme contrôle final pour vérifier comment le déploiement de production se comporte pendant et après l’application du changement. Il peut également être utilisé pour vérifier si un temps d’arrêt est à prévoir pendant le déploiement en production.
Les environnements de préproduction sont parfois également appelés environnements intermédiaires.
Production : votre environnement de production est celui qu’utilisent les utilisateurs finaux de l’application. Il s’agit de l’environnement en direct que vous voulez protéger et maintenir opérationnel autant que possible.
Dans certaines organisations, vous pouvez avoir plusieurs environnements de production. Par exemple, vous pouvez avoir des environnements de production dans différentes régions géographiques ou pour servir différents groupes de clients.
Démo : votre équipe peut également créer des environnements de démonstration (démo) pour montrer l’application aux utilisateurs finaux, pour les utiliser dans des formations ou pour que les équipes de vente puissent présenter certaines fonctionnalités aux clients potentiels. Vous pouvez même avoir plusieurs environnements de démo qui remplissent des objectifs différents. Un environnement de démo est souvent un réplica allégé de votre environnement de production, avec des données client factices.
Environnements dans votre organisation
Vous pouvez voir des variantes de ces environnements. Certaines organisations utilisent seulement quelques environnements, mais d’autres en utilisent beaucoup plus. Le nombre et le type d’environnements que vous utilisez dépendent de la solution que vous déployez, de la taille de l’équipe qui génère la solution et de l’importance de la charge de travail.
Parfois, un seul environnement prend le rôle de plusieurs des environnements listés plus haut. Dans d’autres cas, vous pouvez avoir un pipeline très complexe qui se déploie sur plusieurs environnements, certains en parallèle et d’autres en séquence. Certaines organisations suppriment ou déprovisionnent automatiquement les environnements lorsqu’ils ne sont plus utilisés, puis les redéploient lorsqu’ils sont nécessaires dans le futur.
Quel que soit le choix de votre organisation en tant que liste d’environnements, l’objectif est d’améliorer votre confiance en une modification au fur et à mesure qu’elle progresse dans votre pipeline de déploiement. Quand une modification ne répond pas à vos exigences de qualité, vous devez être en mesure d’arrêter le déploiement de cette modification dans les environnements suivants de la chaîne.
Dans votre entreprise de jouets, vous décidez de commencer avec un ensemble de base d’environnements pour votre site web. En plus de votre environnement de production, vous créez un environnement hors production nommé Test :
Vous allez mettre à jour votre pipeline pour déployer votre code Bicep dans votre environnement de test et exécuter des tests élémentaires par rapport à celui-ci. Si cet effort réussit, le code se déploie dans votre environnement de production.
Environnements de pipeline
Azure Pipelines présente également le concept d’environnement. Vous créez un environnement Azure Pipelines pour représenter l’environnement que vous avez dans Azure. Lorsque vous définissez votre pipeline dans un fichier YAML, vous liez vos travaux de déploiement à un environnement spécifique. En utilisant des environnements, vous bénéficiez de nouvelles fonctionnalités dans votre pipeline.
Vérifications et approbations
Un environnement dans Azure DevOps peut avoir des vérifications et des approbations configurées. Chaque fois que l’environnement est utilisé dans un travail dans votre pipeline, Azure DevOps s’assure que ces vérifications et approbations réussissent avant que le travail commence à s’exécuter.
Par exemple, vous pouvez configurer des approbations manuelles sur votre environnement de production. Avant qu’un déploiement de production commence, l’approbateur désigné reçoit une notification par e-mail. Cette personne peut vérifier manuellement que vos stratégies et procédures sont respectées avant le début du déploiement. Par exemple, l’approbateur peut vérifier que tout fonctionne comme prévu dans l’environnement de préproduction avant d’approuver le déploiement.
Vous pouvez également exécuter une vérification automatisée pour passer en revue les journaux et les taux d'erreur dans votre environnement de préproduction après votre dernier déploiement. Si la vérification confirme que le nombre d’erreurs n’a pas augmenté considérablement, elle permet au déploiement de continuer.
Historique de déploiement
Azure Pipelines effectue le suivi de l’historique des déploiements dans un environnement. Cet historique vous permet de suivre facilement ce qui se passe dans l’environnement au fil du temps. Il vous permet même de suivre un déploiement vers une demande de fonctionnalité spécifique dans vos éléments de travail Azure Boards ou vers une validation dans votre référentiel. Cette fonctionnalité peut être utile si vous rencontrez un problème avec un déploiement et que vous devez identifier la modification qui a conduit au problème.
Sécurité
Vous pouvez appliquer d’autres contrôles de sécurité aux environnements. Vous pouvez limiter les pipelines autorisés à utiliser un environnement spécifique. Ou encore, empêcher quiconque de créer un pipeline secondaire qui interagisse avec votre environnement de production.
Vous pouvez également appliquer des autorisations utilisateur pour contrôler les utilisateurs qui peuvent gérer des environnements. Des autorisations spécifiques peuvent permettre aux utilisateurs de créer de nouveaux environnements, de modifier des environnements et de visualiser les environnements et l’historique des déploiements les concernant.
Notes
Lorsque votre pipeline fait référence à un environnement qui n’existe pas encore, Azure Pipelines le crée automatiquement pour vous. Cette fonctionnalité peut affecter la sécurité de votre projet Azure DevOps, car vous obtenez automatiquement des autorisations d’administration pour l’environnement. Il est préférable que vous créiez vous-même un environnement par le biais de l’interface web Azure DevOps, afin de disposer d’un contrôle total sur sa sécurité et de ne pas obtenir accidentellement d’autorisations dont vous n’avez pas besoin.
Lier un travail de déploiement à un environnement
Dans votre définition de pipeline de déploiement, vous créez une propriété deployment pour spécifier un travail de déploiement et vous spécifiez le nom de l’environnement sur lequel le travail se déploie :
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
Dans cet exemple, le travail nommé DeployWebsite est lié à l’environnement Test.
Conseil
Les travaux ont également d’autres propriétés, notamment la stratégie de déploiement, qui dépassent l’étendue de ce module. Nous proposons des liens vers des informations supplémentaires dans l’unité de résumé.
Connexions des services et environnements
Lorsque vous utilisez plusieurs environnements, vous devez faire en sorte que chaque environnement soit indépendant des autres. Par exemple, le site web de votre environnement de développement ne doit pas être en mesure d’accéder à une base de données dans votre environnement de production.
Le même principe s’applique également au pipeline de déploiement. La connexion de service que vous utilisez pour déployer dans votre environnement de développement ne doit pas être en mesure d’accéder à votre environnement de production. Le respect de ce principe ajoute une autre couche de protection pour garantir que vos déploiements hors production n’affectent pas votre environnement de production.
Vous devez créer des connexions de service distinctes pour chaque environnement. Chaque connexion de service doit utiliser son propre principal de service dédié, avec des autorisations spécifiques pour déployer uniquement sur l’abonnement et le groupe de ressources utilisés par cet environnement :
Important
Utilisez un principal de service et une connexion de service distincts pour chaque environnement sur lequel vous envisagez de déployer. Accordez au principal de service les autorisations minimales qu’il doit déployer dans son environnement, et pas d’autres.
Pensez aussi à séparer vos environnements dans Azure. Au minimum, vous devez créer un groupe de ressources distinct pour chaque environnement. Dans de nombreux cas, mieux vaut créer des abonnements Azure distincts pour chaque environnement. Vous pouvez ensuite créer plusieurs groupes de ressources dans l’abonnement de chaque environnement.
Appliquez des attributions de rôles Azure pour que les utilisateurs et les principaux de service puissent accéder uniquement aux environnements auxquels ils ont besoin d’accéder. Veillez à limiter l’accès à votre environnement de production à un petit ensemble de personnes et au principal de service de déploiement pour cet environnement.