Approbations de déploiement de pipeline - Azure Pipelines (2023)

Services Azure DevOps

Un pipeline est composé d'étapes. Un auteur de pipeline peut contrôler si une étape doit s'exécuter en définissantconditionssur la scène. Une autre façon de contrôler si et quand une étape doit s'exécuter consiste àapprobations et vérifications.

Les pipelines reposent sur des ressources telles que des environnements, des connexions de service, des pools d'agents, des groupes de variables et des fichiers sécurisés. Les chèques permettentpropriétaire de la ressourcepour contrôler si et quand une étape de n'importe quel pipeline peut consommer une ressource. En tant que propriétaire d'une ressource, vous pouvez définir des vérifications qui doivent être satisfaites avant qu'une étape consommant cette ressource puisse commencer. Par exemple, uncontrôle d'approbation manuelsur unenvironnementgarantirait que le déploiement dans cet environnement ne se produise qu'après que le ou les utilisateurs désignés ont examiné les modifications en cours de déploiement.

Une étape peut être composée de plusieurs tâches et chaque tâche peut consommer plusieurs ressources. Avant que l'exécution d'une étape puisse commencer, toutes les vérifications de toutes les ressources utilisées dans cette étape 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. Les vérifications sont réévaluées en fonction de l'intervalle de relance spécifié dans chaque vérification. Si toutes les vérifications échouent jusqu'autemps librespécifiée, cette étape n'est pas exécutée. Si l'une des vérifications échoue définitivement (par exemple, si vous rejetez une approbation sur l'une des ressources), cette étape n'est pas exécutée.

Les approbations et autres vérifications ne sont pas définies dans le fichier yaml. Les utilisateurs modifiant le fichier yaml du pipeline ne peuvent pas modifier les vérifications effectuées avant le début d'une étape. Les administrateurs de ressources gèrent les vérifications à l'aide de l'interface Web d'Azure Pipelines.

Approbations

Vous pouvez contrôler manuellement quand une étape doit s'exécuter à l'aide de contrôles d'approbation. Cette vérification est couramment utilisée pour contrôler les déploiements dans des environnements de production.

1. Dans votre projet Azure DevOps, accédez à la ressource (par exemple, l'environnement) qui doit être protégée.

2. Aller versApprobations et vérificationspour la ressource.

3. SélectionnerCréer, indiquez les approbateurs et un message facultatif, puis sélectionnezCréerà nouveau pour terminer l'ajout de la vérification d'approbation manuelle.

Vous pouvez ajouter plusieurs approbateurs à un environnement. Ces approbateurs peuvent être des utilisateurs individuels ou des groupes d'utilisateurs. Lorsqu'un groupe est spécifié en tant qu'approbateur, un seul des utilisateurs de ce groupe doit approuver l'exécution pour avancer.

À l'aide des options avancées, vous pouvez configurer le nombre minimum d'approbateurs pour terminer l'approbation. Un groupe est considéré comme un approbateur.

Vous pouvez également empêcher l'utilisateur qui a demandé (lancé ou créé) l'exécution de terminer l'approbation. Cette option est couramment utilisée pour la séparation des rôles entre les utilisateurs.

Lorsque vous exécutez un pipeline, l'exécution de cette exécution s'interrompt avant d'entrer dans une étape qui utilise l'environnement. Les utilisateurs configurés en tant qu'approbateurs doivent examiner et approuver ou rejeter le déploiement. Si plusieurs exécutions s'exécutent simultanément, vous devez approuver ou rejeter chacune d'elles indépendamment. Si toutes les approbations requises ne sont pas terminées dans le délaiTemps librespécifiée pour l'approbation et que toutes les autres vérifications réussissent, l'étape est marquée comme ignorée.

Contrôle de branche

À l'aide de la vérification du contrôle de branche, vous pouvez vous assurer que toutes les ressources liées au pipeline sont créées à partir duautorisébranches et que la protection des branches est activée. Cette vérification permet de contrôler la préparation des versions et la qualité des déploiements. Dans le cas où plusieurs ressources sont liées au pipeline, la source de toutes les ressources est vérifiée. Si vous avez lié un autre pipeline, la branche de l'exécution spécifique en cours de déploiement est vérifiée pour la protection.

Pour définir la vérification du contrôle de branche :

1. Dans votre projet Azure DevOps, accédez à la ressource (par exemple, l'environnement) qui doit être protégée.

2. Aller versApprobations et vérificationspour la ressource.

3. Choisir laContrôle de branchevérifiez et fournissez une liste séparée par des virgules des branches autorisées. Vous pouvez exiger que la branche ait la protection activée. Vous pouvez également définir le comportement de la vérification au cas où l'état de protection de l'une des branches n'est pas connu.

   See Also

   Azure DevOps contre Jira | Quel est le meilleur? (2023)Connecteur Microsoft Defender pour DevOps Azure DevOps - Série Microsoft Defender pour Cloud PoCSécurité avancée GitHub pour Azure DevOps

Au moment de l'exécution, la vérification validerait les branches de toutes les ressources liées dans l'exécution par rapport à la liste autorisée. Si l'une des branches ne correspond pas aux critères, la vérification échoue et l'étape est marquée comme ayant échoué.

Heures de travail

Si vous souhaitez que tous les déploiements dans votre environnement se produisent uniquement dans une fenêtre horaire spécifique, la vérification des heures ouvrables est la solution idéale. Lorsque vous exécutez un pipeline, l'exécution de l'étape qui utilise la ressource attend pendant les heures ouvrables. Si plusieurs exécutions s'exécutent simultanément, chacune d'elles est vérifiée indépendamment. Au début des heures ouvrables, le contrôle est marqué comme réussi pour toutes les exécutions.

Si l'exécution de l'étape n'a pas commencé à la fin des heures ouvrables (retenue par un autre contrôle), alors l'approbation des heures ouvrables est automatiquement retirée et une réévaluation est prévue pour le lendemain. Le contrôle échoue si l'exécution du l'étape ne commence pas dans leTemps librepériode spécifiée pour la vérification et l'étape est marquée comme ayant échoué.

Appeler la fonction Azure

Les fonctions Azure sont la plateforme de calcul sans serveur proposée par Azure. Avec les fonctions Azure, vous pouvez exécuter de petits morceaux de code (appelés « fonctions ») sans vous soucier de l'infrastructure de l'application. Compte tenu de la grande flexibilité, les fonctions Azure offrent un excellent moyen de créer vos propres vérifications. Vous incluez la logique de la fonction Azure d'archivage de sorte que chaque exécution soit déclenchée sur 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 a réussi. L'évaluation peut être répétée périodiquement à l'aide du paramètre Délai entre les évaluations dans les options de contrôle.Apprendre encore plus

Les vérifications échouent si l'étape n'a pas démarré son exécution dans le délai spécifié.Temps librepériode. VoirTâche Azure Function Apppour plus de détails.

En savoir plus sur la méthode recommandée pour utiliser Invoke Azure Function checks.

Appeler l'API REST

Invoke REST API check vous permet de vous intégrer à n'importe lequel de vos services existants. Périodiquement, appelez une API REST et continuez si elle renvoie une réponse positive.Apprendre encore plus

L'évaluation peut être répétée périodiquement à l'aide duTemps entre les évaluationsréglage dans les options de contrôle. Les vérifications échouent si l'étape n'a pas démarré son exécution dans le délai spécifié.Temps librepériode. VoirAppeler la tâche de l'API RESTpour plus de détails.

En savoir plus sur la méthode recommandée pour utiliser les vérifications Invoke REST API.

Interroger les alertes Azure Monitor

Azure Monitor offre la visualisation, la requête, le routage, l'alerte, la mise à l'échelle automatique et l'automatisation sur les données de l'infrastructure Azure et de chaque ressource Azure individuelle. Les alertes sont un moyen standard de détecter les problèmes de santé de l'infrastructure ou de l'application et de prendre des mesures correctives. Les déploiements Canary et les déploiements par étapes sont des stratégies de déploiement courantes utilisées pour réduire le risque de régression vers des applications critiques. Après avoir été déployée sur une étape (ensemble de clients), l'application est observée pendant un certain temps. La santé de l'application après le déploiement est utilisée pour décider si la mise à jour doit être effectuée à l'étape suivante ou non.

Interroger les alertes Azure Monitor vous aide à observer Azure Monitor et à vous assurer qu'aucune alerte n'est déclenchée pour l'application après un déploiement. La vérification réussit si aucune règle d'alerte n'est activée au moment de l'évaluation.Apprendre encore plus

L'évaluation est répétée aprèsTemps entre les évaluationsréglage dans les options de contrôle. Les vérifications échouent si l'étape n'a pas commencé son exécution dans le délai spécifiéTemps librepériode.

Modèle requis

Avec la vérification de modèle requise, vous pouvez forcer les pipelines à utiliser un modèle YAML spécifique. Lorsque cette vérification est en place, un pipeline échouera s'il ne s'étend pas à partir du modèle référencé.

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

1. Dans votre projet Azure DevOps, accédez auconnexion aux servicesque vous souhaitez restreindre.

2. OuvrirApprobations et vérificationsdans le menu à côté deModifier.

3. Dans leAjoutez votre premier chèquemenu, sélectionnezModèle requis.

4. Entrez les détails sur la façon d'accéder au fichier de modèle requis.

   • Type de référentiel: l'emplacement de votre référentiel (GitHub, Azure ou Bitbucket).
   • Dépôt: Le nom de votre référentiel qui contient votre modèle.
   • Réf: La branche ou la balise du modèle requis.
   • Chemin d'accès au modèle requis: Le nom de votre modèle.

Vous pouvez avoir plusieurs modèles requis pour la même connexion de service. Dans cet exemple, le modèle requis estrequis.yml.

Évaluer l'artefact

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

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

1. Dans votre projet Azure DevOps Services, accédez à l'environnement qui doit être protégé. En savoir plus surcréer un environnement.

2. Aller versAgréments et contrôlesPour l'environnement.

3. SélectionnerÉvaluer l'artefact.

4. Collez la définition de stratégie et cliquez surSauvegarder.Voir plussur la rédaction de définitions de stratégie.

Lorsque vous exécutez un pipeline, l'exécution de cette exécution s'interrompt avant d'entrer dans une étape qui utilise l'environnement. La stratégie spécifiée est évaluée par rapport aux métadonnées d'image disponibles. La vérification réussit lorsque la stratégie réussit et échoue dans le cas contraire. L'étape est marquée comme échouée si la vérification échoue.

Serrure exclusive

stages :- stage : A lockBehavior : jobs séquentiels : - job : Job steps : - script : Hey !

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

Leserrure exclusivecheck autorise une seule exécution à partir du pipeline. Toutes les étapes de toutes les exécutions de ce pipeline qui utilisent la ressource sont interrompues. Lorsque l'étape utilisant le verrou se termine, une autre étape peut continuer à utiliser la ressource. En outre, une seule étape seront autorisés à continuer. Toutes les autres étapes qui ont tenté de prendre le verrou seront annulées.

Gestion du changement ServiceNow

Cette vérification nécessiteExtension de gestion des changements ServiceNowà installer à partir du marché

Leservicenow gestion du changementcheck permet une intégration du processus de gestion des changements de ServiceNow dans les pipelines. En ajoutant le check, une nouvelle demande de changement dans ServiceNow peut être automatiquement créée au début de l'étape. Le pipeline attend la fin du processus de modification avant de démarrer l'étape. Plus de détails sont disponiblesici.

Approbations et vérifications multiples

Une étape peut être composée de plusieurs tâches et chaque tâche peut consommer plusieurs ressources. Avant que l'exécution d'une étape puisse commencer, toutes les vérifications de toutes les ressources utilisées dans cette étape 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.

Une seule décision finale négative entraîne le refus d'accès au pipeline et l'échec de l'étape. Les décisions de toutes les approbations et vérifications, à l'exception de Invoke Azure Function / REST API etSerrure exclusivesont définitifs.

Lorsque vous utilisez Invoke Azure Function / REST API check in themanière recommandée, leurs décisions d'accès sont également définitives.

Lorsque vous spécifiezTemps entre les évaluationspour qu'une vérification Invoke Azure Function / REST API soit différente de zéro, la décision de la vérification n'est pas définitive. Ce scénario mérite d'être exploré.

Prenons un exemple. Imaginez que votre pipeline YAML comporte une étape qui utilise une connexion de service. Cette connexion de service a deux vérifications configurées pour elle :

1. Une vérification asynchrone, nomméeApprobation externe accordée, qui vérifie queune approbation externe est donnéeet est configuré de la manière recommandée.
2. Une vérification synchrone, nomméeMotif de déploiement valide, qui vérifie quela raison du déploiement est valideet pour lequel vous définissez leTemps entre les évaluationsà 7 minutes.

Une exécution possible des contrôles est illustrée dans le schéma suivant.

Dans cette exécution :

• Les deux chèques,Approbation externe accordéeetMotif de déploiement valide, sont invoqués en même temps.Motif de déploiement valideéchoue immédiatement, mais parce queApprobation externe accordéeest en attente, il sera réessayé.
• A la minute 7,Motif de déploiement valideest réessayé et cette fois ça passe.
• A la minute 15,Approbation externe accordéerappelle dans Azure Pipelines avec une décision réussie. Maintenant, les deux vérifications réussissent, de sorte que le pipeline est autorisé à continuer à déployer l'étape.

Prenons un autre exemple, impliquant deux vérifications synchrones. Supposons que votre pipeline YAML comporte une étape qui utilise une connexion de service. Cette connexion de service a deux vérifications configurées pour elle :

1. Une vérification synchrone, nomméeVérification de synchronisation 1, pour lequel vous définissez leTemps entre les évaluationsà 5 minutes.
2. Une vérification synchrone, nomméeVérification de synchronisation 2, pour lequel vous définissez leTemps entre les évaluationsà 7 minutes.

Une exécution possible des contrôles est illustrée dans le schéma suivant.

Dans cette exécution :

• Les deux chèques,Vérification de synchronisation 1etVérification de synchronisation 2, sont invoqués en même temps.Vérification de synchronisation 1passe, mais il sera réessayé, carVérification de synchronisation 2échoue.
• A la minute 5,Vérification de synchronisation 1est réessayé mais échoue, il sera donc réessayé.
• A la minute 7,Vérification de synchronisation 2est réessayé et réussit. La décision de passage est valable 7 minutes. SiVérification de synchronisation 1ne passe pas dans cet intervalle de temps,Vérification de synchronisation 2sera réessayé.
• A la minute 10,Vérification de synchronisation 1est réessayé mais échoue, il sera donc réessayé.
• A la minute 14,Vérification de synchronisation 2est réessayé et réussit. La décision de passage est valable 7 minutes. SiVérification de synchronisation 1ne passe pas dans cet intervalle de temps,Vérification de synchronisation 2sera réessayé.
• A la minute 15,Vérification de synchronisation 1est réessayé et réussit. Maintenant, les deux vérifications réussissent, de sorte que le pipeline est autorisé à continuer à déployer l'étape.

Prenons 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 unTemps entre les évaluationsde 5 minutes. Jusqu'à ce que l'approbation soit donnée, votre vérification sera exécutée toutes les 5 minutes, quelle que soit la décision.

FAQ

Les vérifications définies n'ont pas démarré. Ce qui s'est passé?

L'évaluation des contrôles commence une fois que les conditions d'étape sont remplies. Vous devez confirmer que l'exécution de l'étape a commencé après l'ajout des vérifications sur la ressource et que la ressource est consommée dans l'étape.

Comment puis-je utiliser les chèques pour programmer une étape ?

À l'aide de la vérification des heures d'ouverture, vous pouvez contrôler l'heure de début de l'exécution de l'étape. Vous pouvez obtenir le même comportement quehoraire prédéfini sur une scènedans les versions des créateurs.

Comment puis-je obtenir des approbations préalables pour une étape dont l'exécution est prévue à l'avenir ?

Ce scénario peut être activé

1. La vérification des heures ouvrables permet de planifier l'exécution de toutes les étapes de déploiement sur une ressource entre la fenêtre horaire
2. Lorsque les approbations sont configurées sur la même ressource, l'étape attend les approbations avant de démarrer.
3. Vous pouvez configurer les deux vérifications sur une ressource. La scène attendrait les approbations et les heures d'ouverture. Cela commencerait dans la prochaine fenêtre planifiée 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 ?

Afin d'attendre la fin de l'analyse de sécurité sur l'artefact en cours de déploiement, vous devez utiliser un service d'analyse externe tel qu'AquaScan. L'artefact en cours de déploiement doit être téléchargé à un emplacement accessible au service de numérisation avant le début des vérifications et peut être identifié à l'aide devariables prédéfinies.A l'aide de la vérification Invoke REST API, vous pouvez ajouter une vérification pour attendre l'API dans le service de sécurité et transmettre l'identificateur d'artefact en tant qu'entrée.

Comment puis-je utiliser les variables de sortie des étapes précédentes dans un contrôle ?

Par défaut, seules les variables prédéfinies sont disponibles pour les vérifications. Vous pouvez utiliser un groupe de variables liées pour accéder à d'autres variables. La variable de sortie de l'étape précédente peut être écrite dans le groupe de variables et accessible dans le contrôle.