Séquence d’exécutions de pipeline

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Les exécutions représentent une exécution d’un pipeline. Pendant une exécution, le pipeline est traité et les agents traitent un ou plusieurs travaux. Une exécution de pipeline comprend des travaux, des étapes et des tâches. Exécute les pipelines d’intégration continue (CI) et de livraison continue (CD).

Lorsque vous exécutez un pipeline, de nombreuses choses se produisent sous couverture. Bien que vous n’ayez souvent pas besoin de les connaître, il est parfois utile d’avoir une vue d’ensemble. À un niveau élevé, Azure Pipelines :

• Traiter le pipeline
• Demander un ou plusieurs agents pour exécuter des travaux
• Transmettre les travaux aux agents et collecter les résultats

Côté agent, pour chaque travail, un agent :

• Préparez-vous pour le travail
• Exécuter chaque étape du travail
• Signaler les résultats à Azure Pipelines

Les travaux peuvent réussir, échouer ou être annulés. Il existe également des situations où un travail peut ne pas se terminer. Comprendre comment cela se produit peut vous aider à résoudre les problèmes.

Nous allons décomposer chaque action une par une.

Traiter le pipeline

Pour transformer un pipeline en exécution, Azure Pipelines effectue plusieurs étapes dans cet ordre :

1. Tout d’abord, développez les modèles et évaluez les expressions de modèle.
2. Ensuite, évaluez les dépendances au niveau de la phase pour sélectionner la ou les premières phases à exécuter.
3. Pour chaque étape sélectionnée à exécuter, deux choses se produisent :
   • Toutes les ressources utilisées dans tous les travaux sont collectées et validées pour l’exécution de l’autorisation.
   • Évaluez les dépendances au niveau du travail pour choisir le ou les premiers travaux à exécuter.
4. Pour chaque travail sélectionné à exécuter, développez multi-configs (strategy: matrix ou strategy: parallel en YAML) en plusieurs travaux d’exécution.
5. Pour chaque travail d’exécution, évaluez les conditions pour déterminer si ce travail est éligible à l’exécution.
6. Demandez un agent pour chaque travail d’exécution éligible.

À mesure que les travaux d’exécution se terminent, Azure Pipelines voit s’il existe de nouveaux travaux éligibles à l’exécution. Dans ce cas, les étapes 4 à 6 se répètent avec les nouveaux travaux. De même, à mesure que les phases se terminent, les étapes 2 à 6 sont répétées pour toutes les nouvelles phases.

Ce classement permet de répondre à une question courante : pourquoi ne puis-je pas utiliser certaines variables dans mes paramètres de modèle ? L’étape 1, l’extension de modèle, fonctionne uniquement sur le texte du document YAML. Les variables d’exécution n’existent pas pendant cette étape. Après l’étape 1, les paramètres de modèle ont été résolus et n’existent plus.

Elle répond également à un autre problème courant : pourquoi ne puis-je pas utiliser des variables pour résoudre les noms de connexion de service/d’environnement ? Les ressources sont autorisées avant qu’une phase ne puisse commencer à s’exécuter, de sorte que les variables de niveau phase et travail ne sont pas disponibles. Les variables de niveau pipeline peuvent être utilisées, mais seules ces variables explicitement incluses dans le pipeline. Les groupes de variables sont eux-mêmes une ressource soumise à l’autorisation. Par conséquent, leurs données ne sont pas non plus disponibles lors de la vérification de l’autorisation des ressources.

Demander un agent

Chaque fois qu’Azure Pipelines doit exécuter un travail, il demande au pool un agent. (Les travaux de serveur sont une exception, car ils s’exécutent sur le serveur Azure Pipelines lui-même.) Les pools d’agents auto-hébergés et hébergés par Microsoft fonctionnent légèrement différemment.

Requêtes de pool d’agents hébergés par Microsoft

Tout d’abord, le service vérifie les travaux parallèles de votre organisation. Il additionne tous les travaux en cours d’exécution sur tous les agents hébergés par Microsoft et les compare au nombre de travaux parallèles achetés. S’il n’y a pas d’emplacements parallèles disponibles, le travail doit attendre sur un emplacement pour se libérer.

Une fois qu’un emplacement parallèle est disponible, le travail est routé vers le type d’agent demandé. D’un point de vue conceptuel, le pool hébergé par Microsoft est un pool mondial géant de machines. (En réalité, il s’agit de nombreux pools physiques différents divisés par zone géographique et par type de système d’exploitation.) En fonction du vmImage nom (en YAML) ou du pool (dans l’éditeur classique) demandé, un agent est sélectionné.

Tous les agents du pool Microsoft sont de nouvelles machines virtuelles qui n’ont jamais exécuté de pipelines auparavant. Une fois le travail terminé, la machine virtuelle de l’agent est ignorée.

Requêtes de pool d’agents auto-hébergés

À l’instar du pool hébergé par Microsoft, le service vérifie d’abord les travaux parallèles de votre organisation. Il additionne tous les travaux en cours d’exécution sur tous les agents auto-hébergés et les compare au nombre de travaux parallèles achetés. S’il n’y a pas d’emplacements parallèles disponibles, le travail doit attendre sur un emplacement pour se libérer.

Une fois qu’un emplacement parallèle est disponible, le pool auto-hébergé est examiné pour rechercher un agent compatible. Les agents auto-hébergés offrent des fonctionnalités, qui sont des chaînes indiquant que des logiciels particuliers sont installés ou que des paramètres sont configurés. Le pipeline a des exigences, qui sont les fonctionnalités requises pour exécuter le travail. Si un agent gratuit dont les fonctionnalités correspondent aux demandes du pipeline est introuvable, le travail continue d’attendre. S’il n’y a pas d’agents dans le pool dont les fonctionnalités correspondent aux demandes, le travail échoue.

Les agents auto-hébergés sont généralement réutilisés d’une exécution à l’autre. Pour les agents auto-hébergés, un travail de pipeline peut avoir des effets secondaires tels que l’échauffement des caches ou le fait que la plupart des commits soient déjà disponibles dans le référentiel local.

Préparation à l’exécution d’un travail

Une fois qu’un agent a accepté un travail, il a du travail de préparation à faire. L’agent télécharge (et met en cache pour la prochaine fois) toutes les tâches nécessaires à l’exécution du travail. Il crée de l’espace de travail sur le disque pour contenir le code source, les artefacts et les sorties utilisés dans l’exécution. Ensuite, il commence à exécuter des étapes.

Exécutez chaque étape

Les étapes sont exécutées séquentiellement, l’une après l’autre. Pour qu’une étape puisse commencer, toutes les étapes précédentes doivent être terminées (ou ignorées).

Les étapes sont implémentées par les tâches. Les tâches elles-mêmes sont implémentées en tant que scripts Node.js ou PowerShell. Le système de tâche achemine les entrées et les sorties vers les scripts de stockage. Il fournit également des services courants tels que la modification du chemin d’accès du système et la création de nouvelles variables de pipeline.

Chaque étape s’exécute dans son propre processus, en l’isolant de l’environnement laissé par les étapes précédentes. En raison de ce modèle de processus par étape, les variables d’environnement ne sont pas conservées entre les étapes. Toutefois, les tâches et les scripts ont un mécanisme pour communiquer avec l’agent : les commandes de journalisation. Lorsqu’une tâche ou un script écrit une commande de journalisation en mode standard, l’agent effectue l’action demandée.

Il existe une commande d’agent pour créer de nouvelles variables de pipeline. Les variables de pipeline seront automatiquement converties en variables d’environnement à l’étape suivante. Pour définir une nouvelle variable myVar avec la valeur myValue, un script peut effectuer les actions suivantes :

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Rapporter et collecter des résultats

Chaque étape peut signaler des avertissements, des erreurs et des échecs. Les erreurs et les avertissements sont signalés à la page récapitulative du pipeline, en marquant la tâche comme « réussie avec des problèmes ». Les échecs sont également signalés à la page récapitulative, mais ils marquent la tâche comme « échec ». Une étape est un échec si elle signale explicitement un échec (à l’aide d’une ##vso commande) ou termine le script avec un code de sortie différent de zéro.

Au fur et à mesure que les étapes s’exécutent, l’agent envoie constamment des lignes de sortie au service. C’est pourquoi vous pouvez voir un flux en direct de la console. À la fin de chaque étape, l’intégralité de la sortie de l’étape est également chargée en tant que fichier journal. Les journaux peuvent être téléchargés une fois le pipeline terminé. Les autres éléments que l’agent peut charger incluent les artefacts et lesrésultats des tests. Elles sont également disponibles une fois le pipeline terminé.

État et conditions

L’agent effectue le suivi de la réussite ou de l’échec de chaque étape. À mesure que les étapes réussissent avec des problèmes ou échouent, l’état du travail est mis à jour. Le travail reflète toujours le « pire » résultat de chacune de ses étapes : en cas d’échec d’une étape, le travail échoue également.

Avant d’exécuter une étape, l’agent vérifie la condition de cette étape pour déterminer si elle doit s’exécuter. Par défaut, une étape s’exécute uniquement lorsque l’état du travail est réussi ou réussi avec des problèmes. De nombreux travaux ont des étapes de nettoyage qui doivent s’exécuter peu importe ce qui s’est passé, afin qu’ils puissent spécifier une condition de « always() ». Les étapes de nettoyage peuvent également être définies pour s’exécuter uniquement en cas d’annulation. Une étape de nettoyage réussie ne peut pas empêcher l’échec du travail ; les travaux ne peuvent jamais revenir à la réussite après l’entrée en échec.

Délais d’expiration et déconnexions

Chaque travail a un délai d’expiration. Si le travail ne s’est pas terminé dans le délai spécifié, le serveur annule le travail. Il tente de signaler à l’agent qu’il s’arrête et marque le travail comme étant annulé. Du côté de l’agent, cela signifie annuler toutes les étapes restantes et charger les résultats restants.

Les travaux ont une période de grâce appelée délai d’expiration d’annulation au cours de laquelle tout travail d’annulation est effectué. (N’oubliez pas que les étapes peuvent être marquées pour s’exécuter même en cas d’annulation.) Après le délai d’expiration plus le délai d’annulation, si l’agent n’a pas signalé que le travail s’est arrêté, le serveur marquera le travail comme un échec.

Étant donné qu’Azure Pipelines distribue le travail aux machines d’agent, de temps à autre, les agents peuvent cesser de répondre au serveur. Cela peut se produire si l’ordinateur hôte de l’agent disparaît (perte de courant, machine virtuelle éteinte) ou en cas de défaillance du réseau. Pour faciliter la détection de ces conditions, l’agent envoie un message de pulsation une fois par minute pour informer le serveur qu’il fonctionne toujours. Si le serveur ne reçoit pas de pulsation pendant cinq minutes consécutives, il suppose que l’agent ne reviendra pas. Le travail est marqué comme un échec, ce qui indique à l’utilisateur qu’il doit réessayer le pipeline.

Gérer les exécutions via l’interface CLI

À l’aide de l’interface CLI Azure DevOps, vous pouvez répertorier les exécutions de pipeline dans votre projet et afficher des détails sur une exécution spécifique. Vous pouvez également ajouter et supprimer des balises dans votre exécution de pipeline.

Prérequis

• Vous devez avoir installé l’extension CLI Azure DevOps comme décrit dans Bien démarrer avec l’interface CLI Azure DevOps.
• Connectez-vous à Azure DevOps à l’aide de az login.
• Pour les exemples figurant dans cet article, définissez l’organisation par défaut avec az devops configure --defaults organization=YourOrganizationURL.

Répertorier les exécutions de pipeline

Répertoriez les exécutions de pipeline dans votre projet avec la commande az pipelines runs list . Pour commencer, consultez Bien démarrer avec l’interface CLI Azure DevOps.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Paramètres facultatifs

• branche : filtrez par builds pour cette branche.
• org : URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=ORG_URL. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config. Exemple : --org https://dev.azure.com/MyOrganizationName/.
• pipeline-ids : ID séparés par l’espace des définitions pour lesquelles la liste des builds doit être établie.
• project : nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=NAME_OR_ID. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config.
• query-order : définissez l’ordre dans lequel les exécutions de pipeline sont répertoriées. Les valeurs acceptées sont FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc et StartTimeDesc.
• reason : répertorie uniquement les builds pour cette raison spécifiée. Les valeurs acceptées sont batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated et validateShelveset.
• requested-for : limite aux builds demandées pour un utilisateur ou un groupe spécifié.
• result : limite aux builds avec un résultat spécifié. Les valeurs acceptées sont canceled, failed, none, partiallySucceeded, and succeeded.
• status : limite aux builds avec un état spécifié. Les valeurs acceptées sont all, cancelling, completed, inProgress, none, notStarted, and postponed.
• tags : limite aux builds avec chacune des balises spécifiées. Espace séparé.
• top : nombre maximal de builds à répertorier.

Exemple

La commande suivante répertorie les trois premières exécutions de pipeline qui ont un étatterminé et un résultat réussi, et retourne le résultat au format de tableau.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Afficher les détails de l’exécution du pipeline

Affichez les détails d’une exécution de pipeline dans votre projet avec la commande az pipelines runs show . Pour commencer, consultez Bien démarrer avec l’interface CLI Azure DevOps.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Paramètres

• ID : obligatoire. ID de l’exécution de pipeline.
• open : facultatif. Ouvre la page des résultats de la build dans votre navigateur web.
• org : URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=ORG_URL. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config. Exemple : --org https://dev.azure.com/MyOrganizationName/.
• projet : nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=NAME_OR_ID. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config.

Exemple

La commande suivante présente les détails de l’exécution du pipeline avec l’ID 123 et retourne les résultats au format de tableau. Elle ouvre également votre navigateur web à la page des résultats de la génération.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Ajouter une étiquette à une exécution de pipeline

Ajoutez une balise à une exécution de pipeline dans votre projet avec la commande az pipelines runs tag add . Pour commencer, consultez Bien démarrer avec l’interface CLI Azure DevOps.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Paramètres

• run-id : obligatoire. ID de l’exécution de pipeline.
• balises: obligatoire. Balises à ajouter à l’exécution du pipeline (valeurs séparées par des virgules).
• org : URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=ORG_URL. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config. Exemple : --org https://dev.azure.com/MyOrganizationName/.
• projet : nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=NAME_OR_ID. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config.

Exemple

La commande suivante ajoute la balise YAML à l’exécution du pipeline avec l’ID 123 et retourne le résultat au format JSON.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Répertorier les exécutions de pipeline

Répertoriez les balises d’une exécution de pipeline dans votre projet avec la commande az pipelines exécute la liste des balises. Pour commencer, consultez Bien démarrer avec l’interface CLI Azure DevOps.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Paramètres

• run-id : obligatoire. ID de l’exécution de pipeline.
• org : URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=ORG_URL. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config. Exemple : --org https://dev.azure.com/MyOrganizationName/.
• projet : nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=NAME_OR_ID. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config.

Exemple

La commande suivante répertorie les balises de l’exécution du pipeline avec l’ID 123 et retourne les résultats au format de tableau.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Supprimer une balise de l’exécution du pipeline

Ajoutez une balise à une exécution de pipeline dans votre projet avec la commande az pipelines runs tag add . Pour commencer, consultez Bien démarrer avec l’interface CLI Azure DevOps.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Paramètres

• run-id : obligatoire. ID de l’exécution de pipeline.
• balise : obligatoire. Balise à supprimer de l’exécution du pipeline.
• org : URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=ORG_URL. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config. Exemple : --org https://dev.azure.com/MyOrganizationName/.
• projet : nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=NAME_OR_ID. Obligatoire en l’absence d’une configuration par défaut ou d’une récupération à l’aide de git config.

Exemple

La commande suivante supprime la balise YAML de l’exécution du pipeline avec l’ID 123.

az pipelines runs tag delete --run-id 123 --tag YAML