Définir des approbations et des vérifications

Azure DevOps Services

Un pipeline est constitué d’index. Un auteur de pipeline peut contrôler si un index doit s’exécuter en définissant des conditions sur cet index. Une autre façon de contrôler si un index doit s’exécuter et à quel moment consiste à utiliser des approbations et des vérifications.

Les approbations et autres vérifications ne sont pas définies dans le fichier yaml. Les utilisateurs qui modifient le fichier yaml du pipeline ne peuvent pas modifier les vérifications effectuées avant le début d’un index. Les administrateurs des ressources gèrent les vérifications à l’aide de l’interface web d’Azure Pipelines.

Les pipelines s’appuient sur des ressources comme des environnements, des connexions de service, des pools d’agents, des groupes de variables et des fichiers sécurisés. Les vérifications permettent au propriétaire de la ressource de contrôler si un index dans un pipeline peut consommer une ressource et quand. En tant que propriétaire d’une ressource, vous pouvez définir des vérifications qui doivent être satisfaites pour qu’un index consommant cette ressource puisse démarrer. Par exemple, une vérification d'approbation manuelle sur un environnement garantit que le déploiement sur cet environnement se produit uniquement une fois que les utilisateurs désignés ont passé en revue les changements en cours de déploiement.

Un index peut se composer de nombreux travaux, et chaque travail peut consommer plusieurs ressources. Pour que l’exécution d’un index puisse commencer, toutes les vérifications sur toutes les ressources utilisées dans cet index doivent être satisfaites. Azure Pipelines interrompt l’exécution d’un pipeline avant chaque index et attend que toutes les vérifications en attente soient terminées.

Il existe cinq catégories d'approbations et de contrôles, qui s'exécutent dans l'ordre dans lequel ils ont été créés au sein de chaque catégorie. Les vérifications sont réévaluées en fonction de l’intervalle de nouvelle tentative spécifié dans chaque vérification. Si toutes les vérifications ne sont pas réussies avant le délai d’expiration spécifié, alors l’index n’est pas exécuté. Si l’une des vérifications échoue invariablement (par exemple, si vous refusez une approbation sur l’une des ressources), alors cet index n’est pas exécuté. Toutefois, vous pouvez réessayer un index lorsque les approbations et les vérifications expirent.

Les contrôles statiques sont exécutés en premier, suivis des approbations de précontrôle. Les catégories sont, dans l'ordre, les suivantes :

  1. Contrôles statiques : Contrôle de branche, Modèle requis et Évaluer l'artefact
  2. Approbations avant vérification
  3. Contrôles dynamiques : Approbation, Invocation d'une fonction Azure, Invocation d'une API REST, Heures ouvrables, Interrogation des alertes Azure Monitor
  4. Approbations après vérification
  5. Verrou exclusif

Vous pouvez également voir l'ordre d'exécution dans l'onglet Approbations et vérifications.

Important

Des vérifications peuvent être configurées sur des environnements, des connexions de service, des référentiels, des groupes de variables, des fichiers sécurisés et des pools d’agents.

Les connexions de service ne peuvent pas être spécifiées par une variable.

Approbations

Vous pouvez contrôler manuellement le moment auquel un index doit s’exécuter à l’aide d’approbations et de vérifications. Cette vérification est couramment utilisée pour contrôler les déploiements dans des environnements de production.

  1. Connectez-vous à votre organisation Azure DevOps puis accédez à votre projet.

  2. Sélectionnez Pipelines>Environnements, puis sélectionnez votre environnement.

  3. Sélectionnez l’onglet Approbations et vérifications, puis sélectionnez le signe + pour ajouter une nouvelle vérification.

    A screenshot showing how to add approvals and checks in Azure Pipelines.

  4. Sélectionnez Approbations, puis Suivant.

  5. Ajoutez des utilisateurs ou des groupes en tant qu’Approbateurs désignés et, si vous le souhaitez, fournissez des instructions pour les approbateurs. Spécifiez si vous souhaitez autoriser ou non les approbateurs à approuver leurs propres exécutions et spécifiez le Délai d’attente souhaité. Si les approbations ne sont pas effectuées dans le délai spécifié, l’index est marqué comme ignoré.

  6. Sélectionnez Créer lorsque vous avez terminé.

    A screenshot showing how to create a new approval.

  7. Une fois la vérification de l’approbation déclenchée, une fenêtre d’invite s’affiche dans l’interface utilisateur, comme illustré dans l’exemple ci-dessous. Elle permet aux approbateurs de rejeter ou d’approuver l’exécution. Elle affiche également les instructions associées.

    A screenshot showing the approval prompt window.

La liste des utilisateurs qui peuvent examiner une approbation est fixée au moment où les contrôles des approbations & commencent à s'exécuter. En d'autres termes, les modifications apportées à la liste des utilisateurs et des groupes d'un contrôle d'approbation après le début de l'exécution des contrôles ne sont pas prises en compte.

Remarque

Si un groupe est désigné comme approbateur, un seul utilisateur du groupe doit approuver l’exécution pour continuer.

Approbations différées

Dans certaines situations, le moment où une approbation est donnée et le moment où le déploiement doit commencer ne coïncident pas. Par exemple, vous pourriez vouloir déployer une nouvelle version à un moment de la soirée où le trafic est faible.

Pour répondre à ce scénario, vous pouvez différer une approbation et définir l'heure à laquelle l'approbation devient effective.

  1. Sélectionnez Différer l'approbation.

    Screenshot of defer approval option when you respond to an approval request.

  2. Définissez l'heure d'approbation.

    Screenshot of setting the time for an approval.

L'approbation apparaît alors dans le panneau Vérifications sous la forme d'une approbation préalable. L'approbation sera effective à la date définie.

Contrôle des branches

À l’aide de la vérification Contrôle des branches, vous pouvez vérifier que toutes les ressources liées au pipeline sont générées à partir des branches autorisées et qu’une protection est activée pour les branches. Cette vérification permet de contrôler la préparation de la mise en production et la qualité des déploiements. Si plusieurs ressources sont liées au pipeline, la source de toutes les ressources est vérifiée. Si vous avez lié un autre pipeline, alors la protection de la branche de l’exécution spécifique en cours de déploiement est vérifiée.

Pour définir la vérification Contrôle des branches :

  1. Dans votre projet Azure DevOps, accédez à la ressource (par exemple, l’environnement) qui a besoin d’une protection.

  2. Accédez à Approbations et vérifications pour la ressource.

  3. Choisissez la vérification Contrôle des branches et fournissez la liste des branches autorisées séparées par des virgules. Vous pouvez exiger que la protection soit activée pour la branche. Vous pouvez également définir le comportement de la vérification au cas où l’état de protection de l’une des branches ne serait pas connu.

    Configuring branch control check.

Au moment de l’exécution, la vérification permet de valider les branches pour toutes les ressources liées incluses dans l’exécution par rapport à la liste autorisée. Si l’une des branches ne respecte pas les critères, le vérification échoue et l’index est marqué comme ayant échoué.

Notes

La vérification nécessite que les noms des branches soient complets. Veillez à ce que le format des noms de branche soit refs/heads/<branch name>

Horaires de bureau

Si vous voulez que tous les déploiements dans votre environnement se produisent dans une fenêtre de temps spécifique uniquement, alors la vérification Heures d’ouverture constitue la solution idéale. Quand vous exécutez un pipeline, l’exécution de l’index qui utilise la ressource attend les heures d’ouverture. Si plusieurs exécutions se produisent simultanément, chacune d’elles est vérifiée indépendamment. Au démarrage des heures d’ouverture, la vérification est marquée comme réussie pour toutes les exécutions.

Configuring business hours check.

Si l’exécution de l’index n’a pas commencé à la fin des heures d’ouverture (elle est retardée par un autre vérification), alors l’approbation des heures d’ouverture est automatiquement retirée et une réévaluation est planifiée le lendemain. La vérification échoue si l’exécution de l’index ne commence pas dans le délai spécifié et l’index est alors marqué comme ayant échoué.

Appeler la fonction Azure

Les fonctions Azure correspondent à la plateforme de calcul serverless proposée par Azure. Avec des fonctions Azure, vous pouvez exécuter de petits morceaux de code (appelés « fonctions ») sans vous préoccuper de l’infrastructure de l’application. Étant donné leur grande flexibilité, les fonctions Azure offrent un excellent moyen de créer vos propres vérifications. Vous incluez la logique de la fonction Azure de vérification de telle sorte que chaque exécution soit déclenchée sur la requête HTTP, ait un temps d’exécution court et retourne une réponse. Lors de la définition de la vérification, vous pouvez analyser le corps de la réponse pour déduire si la vérification est validée. L’évaluation peut être répétée régulièrement à l’aide du paramètre Temps entre les évaluations dans les options de contrôle. En savoir plus

Configuring Azure function check.

Si votre vérification ne réussit dans le délai d’expiration configuré, l’index associé est ignoré. Les phases qui en dépendent sont également ignorées. Pour plus d’informations, consultez la tâche Application de fonction Azure.

Remarque

Les variables de pipeline définies par l’utilisateur sont accessibles à la vérification à partir de Sprint 215.

Découvrez plus d’informations sur la méthode recommandée pour utiliser des vérifications Appeler la fonction Azure. Les vérifications doivent suivre des règles spécifiques en fonction de leur mode et du nombre de nouvelles tentatives pour être conformes.

Appeler l’API REST

La vérification Appeler l’API REST vous permet d’intégrer l’un de vos services existants. À intervalles réguliers, appelez une API REST et continuez si elle retourne une réponse correcte. En savoir plus

L’évaluation peut être répétée régulièrement à l’aide du paramètre Temps entre les évaluations dans les options de contrôle. Si votre vérification ne réussit dans le délai d’expiration configuré, l’index associé est ignoré. Les phases qui en dépendent sont également ignorées. Pour plus d’informations, consultez la tâche Appeler l’API REST.

Remarque

Les variables de pipeline définies par l’utilisateur sont accessibles à la vérification à partir de Sprint 215.

Découvrez plus d’informations sur la méthode recommandée pour utiliser des vérifications Appeler l’API REST.

Interroger les alertes Azure Monitor

Azure Monitor offre des services de visualisation, requête, routage, alertes, mise à l’échelle automatique et automatisation pour les données issues de l’infrastructure Azure et pour chaque ressource Azure. Les alertes sont un moyen standard de détecter les problèmes liés à l’intégrité de l’infrastructure ou de l’application afin de prendre des mesures correctives. Les déploiements de contrôle de validité et les déploiements intermédiaires sont des stratégies de déploiement courantes utilisées pour réduire les risques de régressions sur les applications critiques. Après le déploiement sur un index (ensemble de clients), l’application est observée pendant un certain temps. L’intégrité de l’application après le déploiement est utilisée pour déterminer si la mise à jour doit être effectuée sur l’index suivant ou non.

La vérification Interroger les alertes Azure Monitor vous permet d’observer Azure Monitor afin de veiller à ce qu’aucune alerte ne soit déclenchée pour l’application à l’issue d’un déploiement. La vérification est correcte si aucune règle d’alerte n’est activée au moment de l’évaluation. En savoir plus

L’évaluation est répétée à l’issue du paramètre Temps entre les évaluations défini dans les options de contrôle. Les vérifications échouent si l’index n’a pas démarré l’exécution dans le délai spécifié.

Modèle obligatoire

Avec la vérification Modèle obligatoire, vous pouvez imposer aux pipelines d’utiliser un modèle YAML spécifique. Lorsque cette vérification est en place, un pipeline échoue s’il ne s’étend pas à partir du modèle référencé.

Pour définir une approbation de modèle obligatoire :

  1. Dans votre projet Azure DevOps, accédez à la connexion de service que vous souhaitez restreindre.

  2. Ouvrez Approbations et vérifications dans le menu situé en regard de Modifier.

  3. Dans le menu Ajouter votre premier contrôle, sélectionnez Modèle obligatoire.

  4. Entrez les détails sur la façon d’accéder à votre fichier de modèle obligatoire.

    • Type de référentiel : Emplacement de votre référentiel (GitHub, Azure ou Bitbucket).
    • référentiel : Nom de votre référentiel qui contient votre modèle.
    • Réf : Branche ou balise du modèle obligatoire.
    • Chemin du modèle obligatoire : Nom de votre modèle.

Vous pouvez avoir plusieurs modèles obligatoires pour la même connexion de service. Dans cet exemple, le modèle obligatoire est production_template.yaml.

Configuring required template check.

Désactiver une vérification

Lors du débogage d’une vérification, vous pouvez la désactiver temporairement, puis l’activer à nouveau. Pour désactiver ou activer une vérification :

  1. Dans votre projet Azure DevOps, accédez à la ressource avec une vérification.

  2. Ouvrez l’onglet Approbations et vérifications.

  3. Dans le menu contextuel, sélectionnez Désactiver ou Activer.

    Screenshot of disable a check option.

Contourner une vérification

Dans certaines circonstances, comme un déploiement de correctif logiciel, vous devrez peut-être contourner une vérification. Vous ne pouvez contourner une vérification que si vous disposez de l’autorisation d’un administrateur pour la ressource où la vérification est définie.

Pour contourner une vérification d’approbation, pour les heures d’ouverture, pour l’appel d’une fonction Azure ou d’API REST, sélectionnez Contourner la vérification lorsque la ressource est en attente de vérification. Voici un exemple de contournement pour une vérification d’heures d’ouverture.

Screenshot of bypass business hours check option.

Lorsque vous contournez une vérification, la personne responsable s’affiche dans le panneau des vérifications.

Screenshot of log of bypassed check.

Évaluer l’artefact

Vous pouvez évaluer les artefacts à déployer dans un environnement par rapport à des stratégies personnalisées.

Remarque

Actuellement, cette vérification fonctionne uniquement avec les artefacts d’image conteneur.

Pour définir une évaluation de stratégie personnalisée sur les artefacts, suivez les étapes ci-dessous.

  1. Dans votre projet Azure DevOps Services, accédez à l’environnement qui a besoin d’être protégé. Découvrez-en plus sur la création d’un environnement.

    View environment.

  2. Accédez à Approbations et vérifications pour l’environnement.

    Add checks to environment.

  3. Sélectionnez Évaluer l’artefact.

    Add evaluate artifact check.

  4. Collez la définition de stratégie, puis sélectionnez Enregistrer. Découvrez-en plus sur l’écriture de définitions de stratégie.

    Add policy definition.

Lorsque vous exécutez un pipeline, cette exécution s’interrompt avant d’entrer dans un index qui utilise l’environnement. La stratégie spécifiée est évaluée en fonction des métadonnées d’image disponibles. La vérification est réussie lorsque la stratégie est correcte. Sinon, elle échoue. L’index est marqué comme ayant échoué si la vérification échoue.

Viewing passed checks.

Vous pouvez également voir les journaux complets des vérifications de stratégie dans la vue du pipeline.

Viewing passed check logs.

Verrou exclusif

La vérification Verrou exclusif autorise une seule exécution à partir du pipeline. Tous les index de toutes les exécutions de ce pipeline qui utilisent la ressource sont interrompus. Une fois que l’index qui utilise le verrou a terminé, un autre index peut continuer à utiliser la ressource. En outre, un seul index est autorisé à continuer.

Le comportement de tous les autres index qui tentent de prendre un verrou est configuré par la valeur lockBehavior, elle-même configurée dans le fichier YAML du pipeline.

  • runLatest : Seule la dernière exécution acquiert le verrou sur la ressource. runLatest est la valeur par défaut si aucun lockBehavior n’est spécifié.
  • sequential : Toutes les exécutions acquièrent séquentiellement le verrou sur la ressource protégée.

Pour utiliser la vérification Verrou exclusif avec des déploiements sequential ou runLatest, suivez ces étapes :

  1. Activez la vérification Verrou exclusif sur l’environnement (ou une autre ressource protégée).
  2. Dans le fichier YAML du pipeline, spécifiez une propriété appelée lockBehavior. Celle-ci peut être spécifiée pour l’ensemble du pipeline ou pour un index donné :

Définie sur un index :

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Définie sur le pipeline :

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Si vous ne spécifiez pas de lockBehavior, la valeur par défaut runLatest est utilisée.

La vérification Verrou exclusif autorise une seule exécution à partir du pipeline. Tous les index de toutes les exécutions de ce pipeline qui utilisent la ressource sont interrompus. Une fois que l’index qui utilise le verrou a terminé, un autre index peut continuer à utiliser la ressource. En outre, un seul index est autorisé à continuer. Tous les autres index qui ont tenté de prendre le verrou sont annulés.

Gestion des changements ServiceNow

Cette vérification nécessite l’installation de l’extension Gestion des changements ServiceNow à partir de la Place de marché

La vérification Gestion des changements ServiceNow permet d’intégrer le processus de gestion des changements ServiceNow dans les pipelines. En ajoutant cette vérification, une nouvelle demande de changement dans ServiceNow peut être créée automatiquement au début de l’index. Le pipeline attend que le processus de changement se termine avant de démarrer l’index. Des informations supplémentaires sont disponibles ici.

Approbations et vérifications multiples

Un index peut se composer de nombreux travaux, et chaque travail peut consommer plusieurs ressources. Pour que l’exécution d’un index puisse commencer, toutes les vérifications sur toutes les ressources utilisées dans cet index doivent être satisfaites. Azure Pipelines interrompt l’exécution d’un pipeline avant chaque index et attend que toutes les vérifications en attente soient terminées.

Une seule décision finale négative entraîne le refus de l’accès au pipeline et l’échec de l’index. Les décisions de toutes les approbations et vérifications, à l’exception des vérifications Appeler la fonction Azure/l’API REST et Verrou exclusif, sont définitives. Vous pouvez réexécuter une vérification d’appel de fonction Azure ou d’API REST.

Lorsque vous utilisez les vérifications Appeler la fonction Azure/l’API REST de la manière recommandée, leurs décisions d’accès sont également définitives.

Lorsque vous spécifiez le paramètre Temps entre les évaluations pour une vérification Appeler la fonction Azure/l’API REST sur une valeur non nulle, la décision de la vérification n’est pas définitive. Ce scénario mérite d’être exploré.

Intéressons-nous à un exemple. Imaginez que votre pipeline YAML a un index qui utilise une connexion de service. Deux vérifications sont configurées pour cette connexion de service :

  1. Une vérification asynchrone, nommée Approbation externe accordée, qui vérifie qu’une approbation externe est donnée et qui est configurée de la manière recommandée.
  2. Une vérification synchrone, nommée Validité du motif de déploiement, qui vérifie que le motif du déploiement est valide et pour laquelle vous définissez le paramètre Temps entre les évaluations sur 7 minutes.

Une exécution possible des vérifications est illustrée dans le diagramme suivant. Diagram that shows the timeline of an asynchronous and a synchronous check's executions.

Dans cette exécution :

  • Les deux vérifications, Approbation externe accordée et Validité du motif de déploiement, sont appelées en même temps. La vérification Validité du motif de déploiement échoue immédiatement, mais étant donné que la vérification Approbation externe accordée est en attente, elle va être retentée.
  • À la 7e minute, la vérification Validité du motif de déploiement est retentée et cette fois, elle réussit.
  • À la 15e minute, la vérification Approbation externe accordée rappelle Azure Pipelines avec une décision de réussite. Maintenant, les deux vérifications sont correctes, de sorte que le pipeline est autorisé à poursuivre le déploiement de l’index.

Examinons un autre exemple, qui implique deux vérifications synchrones. Partez du principe que votre pipeline YAML a un index qui utilise une connexion de service. Deux vérifications sont configurées pour cette connexion de service :

  1. Une vérification synchrone, nommée Vérification de synchronisation 1, pour laquelle vous définissez le paramètre Temps entre les évaluations sur 5 minutes.
  2. Une vérification synchrone, nommée Vérification de synchronisation 2, pour laquelle vous définissez le paramètre Temps entre les évaluations sur 7 minutes.

Une exécution possible des vérifications est illustrée dans le diagramme suivant. Diagram that shows the timeline of two synchronous checks' executions.

Dans cette exécution :

  • Les deux vérifications, Vérification de synchronisation 1 et Vérification de synchronisation 2, sont appelées en même temps. La vérification de synchronisation 1 réussit, mais elle va être retentée, car la vérification de synchronisation 2 échoue.
  • À la 5e minute, la vérification de synchronisation 1 est retentée, mais elle échoue, si bien qu’elle va être retentée.
  • À la 7e minute, la vérification de synchronisation 2 est retentée et elle réussit. La décision de réussite est valide pendant 7 minutes. Si la vérification de synchronisation 1 ne réussit pas pendant cet intervalle de temps, la vérification de synchronisation 2 va être retentée.
  • À la 10e minute, la vérification de synchronisation 1 est retentée, mais elle échoue, si bien qu’elle va être retentée.
  • À la 14e minute, la vérification de synchronisation 2 est retentée et elle réussit. La décision de réussite est valide pendant 7 minutes. Si la vérification de synchronisation 1 ne réussit pas pendant cet intervalle de temps, la vérification de synchronisation 2 va être retentée.
  • À la 15e minute, la vérification de synchronisation 1 est retentée et elle réussit. Maintenant, les deux vérifications sont correctes, de sorte que le pipeline est autorisé à poursuivre le déploiement de l’index.

Examinons un exemple qui implique une approbation et une vérification synchrone. Imaginez que vous avez configuré une vérification synchrone et une approbation pour une connexion de service avec un paramètre Temps entre les évaluations égal à 5 minutes. Tant que l'approbation n'est pas donnée, votre vérification s'exécute toutes les 5 minutes, quelle que soit la décision.

FAQ

Les vérifications définies n'ont pas démarré. Que s’est-il passé ?

L’évaluation des vérifications démarre une fois les conditions d’index remplies. Vous devez vérifier le démarrage de l’exécution de l’index après l’ajout des vérifications sur la ressource et la consommation de la ressource dans l’index.

Comment puis-je utiliser les vérifications pour planifier un index ?

À l’aide de la vérification Heures d’ouverture, vous pouvez contrôler l’heure de démarrage de l’exécution de l’index. Vous pouvez obtenir le même comportement que la planification prédéfinie sur un index dans les mises en production du concepteur.

Comment puis-je obtenir des approbations à l’avance pour un index dont l’exécution est planifié à une date future ?

Ce scénario peut être activé.

  1. La vérification Heures d’ouverture permet de planifier l’exécution de tous les index qui se déploient sur une ressource pendant la fenêtre de temps.
  2. Lorsque les approbations sont configurées sur la même ressource, l’index attend les approbations avant de démarrer.
  3. Vous pouvez configurer les deux vérifications sur une ressource. L’index attend les approbations et les heures d’ouverture. Il démarre dans la fenêtre planifiée suivante une fois les approbations terminées.

Puis-je attendre la fin de l’analyse de sécurité sur l’artefact en cours de déploiement ?

Pour attendre la fin de l’analyse de sécurité sur l’artefact en cours de déploiement, vous avez besoin d’utiliser un service d’analyse externe comme AquaScan. L’artefact en cours de déploiement doit être chargé à un emplacement accessible au service d’analyse avant le démarrage des vérifications et il peut être identifié à l’aide de variables prédéfinies. À l’aide de la vérification Appeler l’API REST, vous pouvez ajouter une vérification pour attendre l’API dans le service de sécurité et passer l’identificateur de l’artefact en tant qu’entrée.

Comment puis-je utiliser des variables de sortie des étapes précédentes dans une vérification ?

Par défaut, seules des variables prédéfinies sont disponibles pour des vérifications. Vous pouvez utiliser un groupe de variables lié pour accéder à d’autres variables. La variable de sortie de la phase précédente peut être écrite dans le groupe de variables et accessible dans la vérification.

En savoir plus