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 suspend l’exécution d’un pipeline avant chaque étape 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é.
Vous pouvez réessayer une étape 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 :
- Contrôles statiques : Contrôle de branche, Modèle requis et Évaluer l'artefact
- Approbations avant vérification
- Contrôles dynamiques : Approbation, Invocation d'une fonction Azure, Invocation d'une API REST, Heures ouvrables, Interrogation des alertes Azure Monitor
- Approbations après vérification
- 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.
Connectez-vous à votre organisation Azure DevOps puis accédez à votre projet.
Sélectionnez Pipelines>Environnements, puis sélectionnez votre environnement.
Sélectionnez l’onglet Approbations et vérifications, puis sélectionnez le signe + pour ajouter une nouvelle vérification.
Sélectionnez Approbations, puis Suivant.
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é.
Sélectionnez Créer lorsque vous avez terminé.
Une fois la vérification d’approbation déclenchée, une fenêtre d’invite, comme dans l’exemple suivant, est présentée dans l’interface utilisateur. Elle permet aux approbateurs de rejeter ou d’approuver l’exécution. Elle affiche également les instructions associées.
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.
Sélectionnez Différer l'approbation.
Définissez l'heure d'approbation.
L'approbation apparaît alors dans le panneau Vérifications sous la forme d'une approbation préalable. L’approbation est effective à l’heure 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 :
Dans votre projet Azure DevOps, accédez à la ressource (par exemple, l’environnement) qui a besoin d’une protection.
Accédez à Approbations et vérifications pour la ressource.
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 si le statut de protection d’une des branches n’est pas connu. Une branche est considérée comme protégée si au moins une stratégie a été appliquée (y compris les stratégies appliquées au niveau du référentiel).
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.
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 vérification dans une fonction Azure de sorte que chaque exécution soit déclenchée par une requête http, ait un temps d’exécution court et renvoie 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
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.
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 :
Dans votre projet Azure DevOps, accédez à la connexion de service que vous souhaitez restreindre.
Ouvrez Approbations et vérifications dans le menu situé en regard de Modifier.
Dans le menu Ajouter votre premier contrôle, sélectionnez Modèle obligatoire.
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.
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 :
Dans votre projet Azure DevOps, accédez à la ressource avec une vérification.
Ouvrez l’onglet Approbations et vérifications.
Dans le menu contextuel, sélectionnez Désactiver ou Activer.
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.
Lorsque vous contournez une vérification, la personne responsable s’affiche dans le panneau des vérifications.
É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.
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.
Accédez à Approbations et vérifications pour l’environnement.
Sélectionnez Évaluer l’artefact.
Collez la définition de stratégie, puis sélectionnez Enregistrer. Découvrez-en plus sur l’écriture de définitions de stratégie.
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.
Vous pouvez également voir les journaux complets des vérifications de stratégie dans la vue du pipeline.
Verrou exclusif
La vérification verrou exclusif permet à une seule exécution du pipeline de continuer et peut être définie au niveau de l’étape ou 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.
La propriété lockBehavior détermine comment les autres étapes gèrent les verrous. Lorsque vous spécifiez la propriété lockBehavior pour une étape, un verrou est automatiquement créé pour cette étape. Il existe deux valeurs possibles pour lockBehavior :
runLatest: Seule la dernière exécution acquiert le verrou sur la ressource.runLatestest la valeur par défaut si aucunlockBehaviorn’est spécifié.sequential: Toutes les exécutions acquièrent le verrou sur la ressource protégée de manière séquentielle.
Pour utiliser une vérification de verrou exclusif avec des déploiements sequential ou runLatest, procédez comme suit :
Activez la vérification Verrou exclusif sur l’environnement (ou une autre ressource protégée). L’option de verrou exclusif est une vérification disponible.
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 et qu’un verrou est défini sur une ressource, la valeur par défaut de 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 :
- 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.
- 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.
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 raison du déploiement valide échoue immédiatement, mais comme l’approbation externe accordée est en attente, elle est réessayé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 :
- 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.
- 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.
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 synchrone 1 réussit, mais elle est réessayée, car la vérification synchrone 2 échoue.
- À la minute 5, la vérification synchrone 1 est réessayée mais échoue, elle est donc réessayé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 synchrone 1 ne réussit pas dans cet intervalle de temps, la vérification synchrone 2 est réessayée.
- À la minute 10, la vérification synchrone 1 est réessayée mais échoue, elle est donc réessayé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 synchrone 1 ne réussit pas dans cet intervalle de temps, la vérification synchrone 2 est réessayé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.
Forum aux questions
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é.
- 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.
- Lorsque les approbations sont configurées sur la même ressource, l’index attend les approbations avant de démarrer.
- 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.