Créer et cibler un environnement

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Un environnement est une collection de ressources que vous pouvez cibler avec des déploiements à partir d’un pipeline. Les exemples classiques de noms d’environnement sont dev, test, AQ, intermédiaire et production. Un environnement Azure DevOps représente une cible logique où votre pipeline déploie des logiciels.

Les environnements Azure DevOps ne sont pas disponibles dans les pipelines classiques. Pour les pipelines classiques, les groupes de déploiement offrent des fonctionnalités similaires.

Les environnements présentent les avantages suivants.

Avantage	Description
Historique de déploiement	Les détails du nom et de l’exécution du pipeline sont enregistrés pour les déploiements dans un environnement et ses ressources. Dans le contexte de plusieurs pipelines ciblant le même environnement ou la même ressource, l’historique de déploiement d’un environnement est utile pour identifier la source des modifications.
Traçabilité des validations et des éléments de travail	Affichez les travaux dans l’exécution du pipeline qui ciblent un environnement. Vous pouvez également afficher les commits et les éléments de travail qui ont été récemment déployés dans l’environnement. La traçabilité permet également de suivre si une modification de code (validation) ou une fonctionnalité/correction de bogue (éléments de travail) a atteint un environnement.
Intégrité des ressources de diagnostic	Vérifiez si l’application fonctionne à son état souhaité.
Sécurité	Sécurisez les environnements en spécifiant quels utilisateurs et pipelines sont autorisés à cibler un environnement.

Bien qu’un environnement soit un regroupement de ressources, les ressources elles-mêmes représentent des cibles de déploiement réelles. Les types de ressources Kubernetes et ressources de machine virtuelle sont actuellement pris en charge.

Lorsque vous créez un pipeline YAML et que vous faites référence à un environnement qui n’existe pas, Azure Pipelines crée automatiquement l’environnement lorsque l’utilisateur qui effectue l’opération est connu et que des autorisations peuvent être attribuées. Quand Azure Pipelines ne dispose pas d’informations sur l’utilisateur qui crée l’environnement (par exemple, une mise à jour YAML à partir d’un éditeur de code externe), votre pipeline échoue si l’environnement n’existe pas déjà.

Prérequis

• Vous devez disposer du rôle Créateur pour les environnements afin d’ajouter un environnement.

Créer un environnement

1. Connectez-vous à votre organisation https://dev.azure.com/{yourorganization} et sélectionnez votre projet.

2. Sélectionnez Environnements de>pipelines>Créer un environnement.

   

3. Entrez des informations pour l’environnement, puis sélectionnez Créer. Les ressources peuvent être ajoutées à un environnement existant ultérieurement.

   

Utilisez également un pipeline pour créer et déployer dans des environnements. Pour plus d’informations, consultez le guide pratique.

Conseil

Vous pouvez créer un environnement vide et le référencer à partir de travaux de déploiement. Cela vous permet d’enregistrer l’historique des déploiements dans l’environnement.

Cibler un environnement à partir d’un travail de déploiement

Un travail de déploiement est une collection d’étapes à exécuter séquentiellement. Un travail de déploiement peut être utilisé pour cibler un environnement entier (groupe de ressources), comme illustré dans l’extrait de code YAML suivant. Le pipeline s’exécute sur l’ordinateur myVM, car le nom de la ressource est spécifié.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

Cibler une ressource spécifique dans un environnement à partir d’un travail de déploiement

Vous pouvez étendre la cible du déploiement à une ressource particulière au sein de l’environnement. Ensuite, vous pouvez enregistrer l’historique de déploiement sur une ressource spécifique au sein de l’environnement. Les étapes du travail de déploiement héritent automatiquement des détails de connexion de service de la ressource ciblée par le travail de déploiement.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

Environnement dans les détails de l’exécution

Tous les environnements ciblés par les travaux de déploiement d’une exécution spécifique d’un pipeline se trouvent sous l’onglet Environnements des détails de l’exécution du pipeline.

Si vous utilisez un cluster privé AKS, l’onglet Environnements n’est pas disponible.

Approbations

Contrôle manuel du moment auquel un index doit s’exécuter à l’aide de vérifications d’approbation. Utilisez des vérifications d’approbation pour contrôler les déploiements dans des environnements de production. Les vérifications sont disponibles pour le propriétaire de la ressource pour contrôler quand un index d’un pipeline consomme une ressource. En tant que propriétaire d’une ressource, telle qu’un environnement, vous pouvez définir des approbations et des vérifications qui doivent être satisfaites avant qu’un index de consommation de cette ressource commence.

Nous prenons en charge les vérifications d’approbation manuelles sur les environnements. Pour plus d’informations, consultez Approbations.

Les rôles Créateur, Administrateur et Utilisateur peuvent gérer les approbations et les vérifications. Le rôle Lecteur ne peut pas gérer les approbations et les vérifications.

Historique de déploiement

La vue d’historique des déploiements dans les environnements offre les avantages suivants.

• Affichez les travaux de tous les pipelines qui ciblent un environnement spécifique. Par exemple, deux microservices, chacun ayant son propre pipeline, sont déployés dans le même environnement. La liste de l’historique des déploiements permet d’identifier tous les pipelines qui affectent cet environnement et permet également de visualiser la séquence de déploiements par chaque pipeline.

  

• Explorez les détails du travail pour voir la liste des commits et des éléments de travail qui ont été déployés dans l’environnement. La liste des commits et des éléments de travail sont les nouveaux éléments entre les déploiements. Votre première liste inclut tous les commits et les listes suivantes incluent uniquement les modifications. Si plusieurs commits sont liés à la même demande de tirage, vous verrez plusieurs résultats sur les éléments de travail et les onglets modifications.

  

• Si plusieurs éléments de travail sont liés à la même demande de tirage, plusieurs résultats s’affichent sous l’onglet Éléments de travail.

  

Sécurité

Autorisations utilisateur

Contrôler qui peut créer, afficher, utiliser et gérer les environnements avec des autorisations utilisateur. Il existe quatre rôles : Créateur (étendue : tous les environnements), Lecteur, Utilisateur et Administrateur. Dans le panneauAutorisations utilisateur de l’environnement spécifique, vous pouvez définir les autorisations héritées et vous remplacer les rôles pour chaque environnement.

1. Accédez à l’environnement spécifique que vous souhaitez autoriser.
2. Sélectionnez >Sécurité pour afficher les paramètres.
3. Sélectionnez Autorisations utilisateur>+Ajouter un>utilisateur ou un groupe, puis sélectionnez un rôle approprié.

Rôle	Description
Creator	Rôle global, disponible avec l’option Sécurité du hub d’environnements. Les membres de ce rôle peuvent créer l’environnement dans le projet. Les contributeurs sont par défaut ajoutés en tant que membres. Obligatoire pour déclencher un pipeline YAML lorsque l’environnement n’existe pas déjà.
Lecteur	Les membres de ce rôle peuvent afficher l’environnement.
Utilisateur	Les membres de ce rôle peuvent utiliser l’environnement lors de la création et de la modification de pipelines YAML.
Administrateur	Les membres de ce rôle peuvent gérer des autorisations, créer, gérer, afficher et utiliser des environnements. Pour un environnement particulier, son créateur est ajouté en tant que Administrateur par défaut. Les administrateurs peuvent également ouvrir l’accès à un environnement à tous les pipelines.

Autorisations de pipeline

Utilisez les autorisations de pipeline pour autoriser tous les pipelines ou sélectionnés pour le déploiement dans l’environnement.

• Pour supprimer Ouvrir l’accès sur l’environnement ou la ressource, sélectionnez Restreindre l’autorisation dans Autorisations de pipeline.
• Pour autoriser le déploiement de pipelines spécifiques dans un environnement ou une ressource spécifique, sélectionnez + et choisissez dans la liste des pipelines.

Étapes suivantes

Définir des approbations et des vérifications

Questions fréquentes (FAQ)

Q : Pourquoi obtenir un message d’erreur quand j’essaie de créer un environnement ?

R : Si vous voyez le message « Accès refusé : {Utilisateur} a besoin d’autorisations Créer pour effectuer l’action », vérifiez vos autorisations au niveau de l’organisation. Accédez à Paramètres de l’organisation>Utilisateurs et vérifiez si vous avez le rôle de partie prenante. Le rôle de partie prenante ne peut pas créer d’environnements. Modifiez votre niveau d’accès, puis vérifiez si vous pouvez créer des environnements. Pour plus d’informations, consultez FAQ sur la gestion des utilisateurs et des autorisations.

Q : Pourquoi est-ce que je reçois l’erreur « Travail XXXX : l’environnement XXXX est introuvable. L’environnement n'existe pas ou son utilisation n'a pas été autorisée. » ?

R : Voici quelques-unes des raisons possibles de l’échec :

• Lorsque vous créez un pipeline YAML et que vous faites référence à un environnement qui n’existe pas dans le fichier YAML, Azure Pipelines crée automatiquement l’environnement dans certains cas :

  • Vous utilisez l’Assistant Création de pipeline YAML dans l’expérience web Azure Pipelines, puis faites référence à un environnement qui n’a pas encore été créé.
  • Vous mettez à jour le fichier YAML à l’aide de l’éditeur web Azure Pipelines, puis enregistrez le pipeline après avoir ajouté une référence à un environnement qui n’existe pas.

• Dans les flux suivants, Azure Pipelines ne dispose pas d’informations sur l’utilisateur qui crée l’environnement : vous mettez à jour le fichier YAML à l’aide d’un autre éditeur de code externe, ajoutez une référence à un environnement qui n’existe pas, puis déclenchez un pipeline d’intégration manuel ou continu. Dans ce cas, Azure Pipelines ne connaît pas l’utilisateur. Auparavant, nous avons géré ce cas en ajoutant tous les contributeurs de projet au rôle Administrateur de l’environnement. Tout membre du projet peut ensuite modifier ces autorisations et empêcher d’autres personnes d’accéder à l’environnement.

• Vous pouvez utiliser des variables pour créer l’environnement ou utiliser templateContext pour transmettre des propriétés à des modèles. Les paramètres d’exécution ne fonctionnent pas lors de la création de l’environnement, car ils sont développés au moment de l’exécution.

• Un utilisateur avec un niveau d’accès de partie prenante ne peut pas créer l’environnement, car les parties prenantes n’ont pas accès au référentiel.

Articles connexes

• Définir des variables
• Définir des ressources dans YAML