Agents Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Remarque

Microsoft Visual Studio Team Foundation Server 2018 et les versions antérieures présentent les différences suivantes en termes de nommage :

  • Les pipelines de build et de mise en production sont appelés définitions
  • Les exécutions sont appelées builds
  • Les connexions de service sont appelées points de terminaison de service
  • Les phases sont appelées environnements
  • Les travaux sont appelés phases

Pour générer votre code ou déployer votre logiciel à l’aide d’Azure Pipelines, vous devez disposer d’au moins un agent. Au fur et à mesure que vous ajouterez du code et des utilisateurs, vous en aurez peut-être besoin de plus.

Quand votre pipeline s’exécute, le système démarre un ou plusieurs travaux. Un agent est une infrastructure informatique avec un logiciel agent installé, qui exécute les travaux un par un.

Azure Pipelines fournit plusieurs types d’agent différents.

Type d’agent Description Disponibilité
Agents hébergés par Microsoft Agents hébergés et gérés par Microsoft Azure DevOps Services
Agents auto-hébergés Les agents que vous configurez et gérez, hébergés sur vos machines virtuelles Azure DevOps Services, Azure DevOps Server, TFS
Agents Microsoft Azure Virtual Machine Scale Sets Forme d’agents autohébergés, utilisant des groupes de machines virtuelles identiques Azure, qui sont mis à l’échelle automatiquement en fonction de vos exigences Azure DevOps Services

Les travaux peuvent être exécutés directement sur la machine hôte de l’agent ou dans un conteneur.

Agents hébergés par Microsoft

Si vos pipelines se trouvent dans Azure Pipelines, vous disposez d’une option pratique pour exécuter vos tâches à l’aide d’un agent hébergé par Microsoft. Avec les agents hébergés par Microsoft, la maintenance et les mises à niveau sont effectuées pour vous. Vous obtenez toujours la dernière version de l’image de machine virtuelle que vous spécifiez dans votre pipeline. Chaque fois que vous exécutez un pipeline, vous obtenez une nouvelle machine virtuelle pour chaque travail du pipeline. La machine virtuelle est abandonnée après un travail (ce qui signifie que toute modification apportée par un travail au système de fichiers de machine virtuelle, comme l’extraction du code, n’est pas disponible pour le travail suivant). Les agents hébergés par Microsoft peuvent exécuter des travaux directement sur la machine virtuelle ou dans un conteneur.

Azure Pipelines fournit un pool d’agents prédéfini appelé Azure Pipelines avec des agents hébergés par Microsoft.

Pour de nombreuses équipes, il s’agit du moyen le plus simple d’exécuter les travaux. Vous pouvez essayer cette méthode en premier pour voir si elle est adaptée à vos besoins de génération et de déploiement. Si ce n’est pas le cas, vous pouvez utiliser des agents de groupe identique ou un agent auto-hébergé.

Conseil

Vous pouvez essayer gratuitement un agent hébergé par Microsoft.

En savoir plus sur les agents hébergés par Microsoft.

Agents auto-hébergés

Un agent autohébergé est un agent que vous configurez et gérez vous-même pour exécuter des travaux. Vous pouvez utiliser des agents autohébergés dans Azure Pipelines ou Azure DevOps Server, anciennement nommé Team Foundation Server (TFS). Des agents autohébergés vous donnent davantage de contrôle pour installer les logiciels dépendants nécessaires pour vos builds et vos déploiements. En outre, les caches et la configuration au niveau de la machine persistent d’une exécution à l’autre, ce qui permet d’améliorer la vitesse.

Notes

Bien que plusieurs agents puissent être installés par machine, nous vous recommandons vivement d’installer un seul agent par machine. Il est possible que l’installation de deux agents ou plus nuise au niveau de performance et au résultat de vos pipelines.

Conseil

Avant d’installer un agent auto-hébergé, vous devez déterminer si un pool d’agents hébergé par Microsoft convient à votre projet. Dans de nombreux cas, il s’agit de la façon la plus simple de se lancer. Faites un essai.

Vous pouvez installer un agent sur des machines Linux, macOS ou Windows, Vous pouvez également installer un agent sur un conteneur Docker Linux. Pour plus d’informations sur l’installation d’un agent autohébergé, consultez :

Notes

Sur macOS, vous devez effacer l’attribut spécial sur l’archive de téléchargement pour empêcher que la protection Gatekeeper s’affiche pour chaque assembly dans le fichier tar lors de l’exécution de ./config.sh. La commande suivante efface l’attribut étendu sur le fichier :

xattr -c vsts-agent-osx-x64-V.v.v.tar.gz  ## replace V.v.v with the version in the filename downloaded.

# then unpack the gzip tar file normally:

tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz

Après avoir installé l’agent sur une machine, vous y installez également tous les autres logiciels nécessaires pour vos travaux.

Remarque

Les agents offrent généralement une compatibilité descendante. Toute version de l’agent doit être compatible avec la version d’Azure DevOps de votre choix jusqu’à ce qu’Azure DevOps exige une version ultérieure de l’agent.

Nous prenons uniquement en charge la version la plus récente de l’agent, car il s’agit de la seule version garantie qui dispose de l’ensemble des correctifs et résolutions de bogues à jour.

Versions de l’exécuteur Node

L’agent est fourni avec plusieurs versions des bibliothèques NodeJS pour prendre en charge des tâches cibles qui utilisent différents gestionnaires Node.

Toutes les tâches Azure DevOps officielles utilisent Node 10 comme gestionnaire universel. Toutefois, les clients peuvent toujours utiliser des tâches personnalisées qui utilisent la bibliothèque Node 6 obsolète. Pour prendre en charge la compatibilité descendante avec Node qui a atteint actuellement la fin de vie, nous fournissons les méthodes en libre-service suivantes pour installer manuellement l’exécuteur Node désigné.

  • Installez manuellement l’exécuteur Node 6. Pour obtenir plus d’informations sur l’installation manuelle de l’exécuteur Node 6, consultez la Prise en charge de Node 6.

  • Utilisez la tâche NodeTaskRunnerInstaller@0 dans vos pipelines qui nécessitent la bibliothèque Node 6 obsolète.

  • Installez un package d’agent qui inclut Node 6.

    Azure Pipelines fournit deux versions de packages d’agent.

    • Les packages vsts-agent-* prennent en charge Node 6.
    • Les packages pipelines-agent-* ne prennent pas en charge Node 6. Cette version du package deviendra le package d’agent par défaut à l’avenir.

    Si vous savez que vous n’utilisez aucune tâche dépendante de Node 6 et que vous ne souhaitez pas que Node 6 soit installé sur votre ordinateur agent, vous pouvez installer l’agent à partir de la section Autres téléchargements de l’agent de https://github.com/microsoft/azure-pipelines-agent/releases.

Agents de groupe de machines virtuelles identiques Azure

Les agents de groupe de machines virtuelles identiques Azure sont un type d’agents autohébergés qui peuvent être mis à l’échelle automatiquement selon vos exigences. Cette élasticité réduit votre besoin d’exécuter des agents dédiés tout le temps. Contrairement aux agents hébergés par Microsoft, vous disposez d’une flexibilité sur la taille et l’image des ordinateurs sur lesquels les agents s’exécutent.

Vous spécifiez un groupe de machines virtuelles identiques, un nombre d’agents à conserver en veille, un nombre maximal de machines virtuelles dans le groupe et Azure Pipelines gère la mise à l’échelle de vos agents pour vous.

Pour plus d’informations, consultez Agents de groupes de machines virtuelles identiques Azure.

Travaux parallèles

Les travaux parallèles représentent le nombre de travaux que vous pouvez exécuter simultanément dans votre organisation. Si votre organisation dispose d’un seul travail parallèle, vous pouvez exécuter un seul travail à la fois dans votre organisation. Les travaux simultanés supplémentaires sont alors mis en file d’attente jusqu’à la fin du premier travail. Pour exécuter deux travaux simultanément, vous avez besoin de deux travaux parallèles. Dans Azure Pipelines, vous pouvez exécuter des travaux parallèles sur une infrastructure hébergée par Microsoft ou sur votre propre infrastructure (auto-hébergée).

Microsoft fournit un niveau de service gratuit par défaut dans chaque organisation comprenant au moins un travail parallèle. Selon le nombre de pipelines simultanés à exécuter, vous pouvez avoir besoin de travaux parallèles supplémentaires pour utiliser plusieurs agents hébergés par Microsoft ou auto-hébergés simultanément. Pour plus d’informations sur les travaux parallèles et les différents niveaux de service gratuits, consultez Travaux parallèles dans Azure Pipelines.

Vous avez peut-être besoin de travaux parallèles supplémentaires pour utiliser plusieurs agents simultanément :

Important

À partir d’Azure DevOps Server 2019, les travaux simultanés auto-hébergés dans les mises en production ne sont pas facturés. Vous êtes limité uniquement par le nombre d’agents dont vous disposez.

Fonctionnalités

Chaque agent auto-hébergé présente un ensemble de capacités indiquant les opérations possibles. Les capacités sont des paires nom-valeur qui sont soit découvertes automatiquement par le logiciel de l’agent (elles sont alors appelées capacités système), soit définies par vous-même (dans ce cas, elles sont appelées capacités utilisateur).

Le logiciel de l’agent détermine automatiquement différentes capacités système comme le nom de la machine, le type de système d’exploitation et les versions de certains logiciels installés sur la machine. En outre, les variables d’environnement définies dans la machine apparaissent automatiquement dans la liste des capacités du système.

Remarque

Le stockage des variables d’environnement en tant que capacités signifie que les valeurs de capacité stockées sont utilisées pour définir les variables d’environnement quand un agent s’exécute. En outre, les modifications apportées aux variables d’environnement pendant l’exécution de l’agent ne sont ni récupérées ni utilisées par aucune tâche. Si vous disposez de variables d’environnement sensibles qui changent et que vous ne souhaitez pas les stocker en tant que capacités, vous pouvez les ignorer en définissant la variable d’environnement VSO_AGENT_IGNORE, avec une liste délimitée par des virgules de variables à ignorer. Par exemple, PATH est une variable critique que vous pouvez ignorer si vous installez un logiciel.

Quand vous créez un pipeline, vous spécifiez certaines exigences de l’agent. Le système envoie le travail uniquement aux agents dont les capacités correspondent aux exigences spécifiées dans le pipeline. Par conséquent, les capacités de l’agent permettent de diriger les travaux vers des agents spécifiques.

Remarque

Les demandes et les fonctionnalités sont conçues pour être utilisées avec des agents autohébergés afin que les travaux puissent être mis en correspondance avec un agent qui répond à leurs demandes. Si vous avez recours à des agents hébergés par Microsoft, vous sélectionnez pour l’agent une image adaptée aux exigences du travail. Par conséquent, les fonctionnalités ne sont pas nécessaires avec ce type d’agent, bien qu’il soit possible de lui en ajouter.

Configurer des demandes

Pour ajouter une demande à votre pipeline de build YAML, ajoutez la ligne demands: à la section pool.

pool:
  name: Default
  demands: SpecialSoftware # exists check for SpecialSoftware

Vous pouvez vérifier l’existence d’une fonctionnalité ou effectuer une comparaison avec la valeur d’une fonctionnalité. Pour obtenir plus d’informations, consultez Schéma YAML – Demandes.

Les pipelines YAML sont pris en charge dans Azure DevOps Server 2019 et versions ultérieures.

Configurer les capacités de l’agent

Vous pouvez afficher les détails d’un agent, notamment la version et les capacités système, ainsi que gérer les capacités utilisateur, en accédant à Pools d’agents et en sélectionnant l’onglet Capacités de l’agent souhaité.

  1. Dans votre navigateur web, accédez aux pools d’agents :

    1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

    2. Choisissez Azure DevOps, Paramètres de l’organisation.

      Choose Organization settings.

    3. Choisissez Pools d’agents.

      Choose Agent pools tab.

    1. Connectez-vous à votre collection de projets (http://your-server/DefaultCollection).

    2. Choisissez Azure DevOps, Paramètres de la collection.

      Choose Collection settings.

    3. Choisissez Pools d’agents.

      Choose Agent pools.

    1. Choisissez Azure DevOps, Paramètres de la collection.

      Collection settings, 2019.

    2. Choisissez Pools d’agents.

      Choose Agent pools, 2019.

    1. Accédez à votre projet et choisissez Paramètres (icône d’engrenage) >Files d’attente d’agents.

      Choose Settings, Agent Queues, 2018.

    2. Choisissez Gérer les pools.

      Choose Manage pools, 2018.

  2. Accédez à l’onglet Capacités :

    1. Sous l’onglet Pools d’agents, sélectionnez le pool d’agents souhaité.

      From Agent pools, select the desired agent pool.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Select Agents and choose the agent.

    3. Choisissez l’onglet Fonctionnalités.

      Choose the Capabilities tab.

      Notes

      Les agents hébergés par Microsoft n’affichent pas de fonctionnalités système. Pour obtenir la liste des logiciels installés sur des agents hébergés par Microsoft, consultez Utiliser un agent hébergé par Microsoft.

    1. Sous l’onglet Pools d’agents, sélectionnez le pool souhaité.

      Select the desired pool.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Select Agents and choose the desired agent.

    3. Choisissez l’onglet Fonctionnalités.

      Agent capabilities tab.

    1. Sous l’onglet Pools d’agents, sélectionnez le pool souhaité.

      Select the desired tab, 2019.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Choose the desired agent, 2019.

    3. Choisissez l’onglet Fonctionnalités.

      Choose the Capabilities tab, 2019.

    Sélectionnez l’agent souhaité, puis choisissez l’onglet Fonctionnalités.

    Agent capabilities tab, 2018.

  3. Pour inscrire une nouvelle capacité auprès de l’agent, choisissez Ajouter une nouvelle capacité.

Conseil

Après avoir installé un nouveau logiciel sur un agent auto-hébergé, vous devez redémarrer l’agent pour que la nouvelle capacité s’affiche. Pour plus d’informations, consultez Redémarrer l’agent Windows, Redémarrer l’agent Linux et Redémarrer l’agent Mac.

Communication

Communication avec Azure Pipelines

Communication avec Azure DevOps Server

Communication avec TFS

L’agent communique avec Azure Pipelines ou Azure DevOps Server pour déterminer quel travail il doit exécuter et signaler les journaux et l’état du travail. Cette communication est toujours lancée par l’agent. Tous les messages de l’agent à destination d’Azure Pipelines ou Azure DevOps Server utilisent le protocole HTTPS, selon la façon dont vous configurez l’agent. Ce modèle de tirage permet à l’agent d’être configuré dans différentes topologies, comme indiqué ci-dessous.

Agent topologies in on-premises installations.

Agent topologies in Azure DevOps Services.

Voici un modèle de communication courant entre l’agent et Azure Pipelines ou Azure DevOps Server.

  1. L’utilisateur inscrit un agent auprès d’Azure Pipelines ou d’Azure DevOps Server en l’ajoutant à un pool d’agents. Vous devez être un administrateur de pool d’agents pour inscrire un agent dans ce pool d’agents. L’identité de l’administrateur du pool d’agents est uniquement requise au moment de l’inscription. Elle n’est pas conservée sur l’agent ni utilisée dans les communications suivantes entre l’agent et Azure Pipelines ou Azure DevOps Server. Une fois l’inscription terminée, l’agent télécharge un jeton OAuth d’écouteur et l’utilise pour écouter la file d’attente des travaux.

  2. L’agent écoute si une nouvelle demande de travail a été publiée pour celle-ci dans la file d’attente de travaux dans Azure Pipelines/Azure DevOps Server à l’aide d’un sondage http long. Quand un travail est disponible, l’agent le télécharge, ainsi qu’un jeton OAuth spécifique au travail. Ce jeton est généré par Azure Pipelines/Azure DevOps Server pour l’identité limitée spécifiée dans le pipeline. Ce jeton est de courte durée et est utilisé par l’agent pour accéder aux ressources (par exemple, le code source) ou pour modifier les ressources (par exemple, pour charger les résultats des tests) sur Azure Pipelines ou Azure DevOps Server au sein de ce travail.

  3. Une fois le travail terminé, l’agent abandonne le jeton OAuth spécifique au travail et vérifie s’il existe une nouvelle demande de travail en utilisant le jeton OAuth de l’écouteur.

La charge utile des messages échangés entre l’agent et Azure Pipelines/Azure DevOps Server est sécurisée avec un chiffrement asymétrique. Chaque agent possède une paire de clés publique/privée et la clé publique est échangée avec le serveur lors de l’inscription. Le serveur utilise la clé publique pour chiffrer la charge utile du travail avant de l’envoyer à l’agent. L’agent déchiffre le contenu du travail avec sa clé privée. C’est ainsi que les secrets stockés dans des pipelines ou des groupes de variables sont sécurisés au fur et à mesure qu’ils sont échangés avec l’agent.

Remarque

L’agent prend en charge la sortie d’encodage du client UTF-8. Toutefois, si votre système a un encodage autre qu’UTF-8, vous pouvez rencontrer des problèmes avec la sortie des journaux. Par exemple, les journaux d’activité peuvent contenir des caractères qui ne sont pas reconnus par l’encodage de votre système et ils peuvent donc apparaître comme symboles tronqués ou manquants.

Communiquer pour effectuer un déploiement sur des serveurs cibles

Quand vous utilisez l’agent pour déployer des artefacts sur un ensemble de serveurs, il doit disposer d’une connectivité « à visibilité directe » à ces serveurs. Par défaut, les pools d’agents hébergés par Microsoft disposent d’une connectivité aux sites web et serveurs Azure s’exécutant dans Azure.

Notes

Si vos ressources Azure s’exécutent dans un Réseau virtuel Azure, vous pouvez obtenir les plages d’adresses IP de l’agent où les agents hébergés par Microsoft sont déployés afin de configurer les règles de pare-feu de votre réseau virtuel Azure et d’autoriser l’agent à y accéder.

Si vos environnements locaux n’ont pas de connectivité à un pool d’agents hébergés par Microsoft (ce qui est généralement le cas en raison de pare-feu intermédiaires), vous devez configurer manuellement un agent autohébergé sur des ordinateurs locaux. Les agents doivent disposer d’une connectivité aux environnements locaux cibles et d’un accès à Internet pour se connecter à Azure Pipelines ou Team Foundation Server, comme indiqué dans le schéma suivant.

Agent connectivity for on-premises environments

Authentification

Pour inscrire un agent, vous devez disposer du rôle Administrateur dans le pool d’agents. L’identité de l’administrateur du pool d’agents est uniquement requise au moment de l’inscription. Elle n’est pas conservée sur l’agent ni utilisée dans les communications suivantes entre l’agent et Azure Pipelines ou Azure DevOps Server. En outre, vous devez être administrateur local sur le serveur pour configurer l’agent.

Lorsque vous enregistrez un agent, choisissez parmi les types d'authentification suivants et la configuration de l'agent vous invite à fournir les informations supplémentaires spécifiques requises pour chaque type d'authentification. Pour plus d'informations, consultez Options d'authentification de l'agent auto-hébergé.

  • Jeton d’accès personnel
  • Connectez-vous alternativement à Azure DevOps Server ou TFS à l’aide de l’authentification De base. Lorsque vous sélectionnez Alternative, vous serez invité à fournir vos informations d'identification.

Les agents Windows disposent des deux options d'authentification supplémentaires suivantes sur Azure DevOps Server et TFS.

  • Négocier Connexion à TFS en tant qu’utilisateur autre que l’utilisateur connecté selon un schéma d’authentification Windows tel que NTLM ou Kerberos. Quand vous sélectionnez Négocier, vous êtes invité à entrer vos informations d’identification.
  • Intégré (par défaut) Connexion d’un agent Windows à TFS avec les informations d’identification de l’utilisateur connecté selon un schéma d’authentification Windows tel que NTLM ou Kerberos. Quand vous choisissez cette méthode, vos informations d’identification ne vous sont pas demandées.

Important

Votre serveur doit être configuré pour prendre en charge la méthode d'authentification afin d'utiliser l'authentification alternative, négociée ou intégrée.

La méthode d'authentification utilisée pour enregistrer l'agent est utilisée uniquement lors de l'enregistrement de l'agent. Pour en savoir plus sur la manière dont les agents communiquent avec Azure Pipelines après l'inscription, consultez Communication avec Azure Pipelines ou TFS.

Service interactif et service

Vous pouvez exécuter votre agent autohébergé en tant que service ou processus interactif. Une fois l’agent configuré, nous vous recommandons de l’essayer en mode interactif pour s’assurer qu’il fonctionne. Ensuite, pour une utilisation en production, nous vous recommandons d’exécuter l’agent dans l’un des modes suivants afin qu’il s’exécute de manière fiable. Ces modes garantissent également que l’agent démarre automatiquement si la machine est redémarrée.

  1. En tant que service. Vous pouvez utiliser le gestionnaire de service du système d’exploitation pour gérer le cycle de vie de l’agent. En outre, l’expérience de la mise à niveau automatique de l’agent est plus efficace quand il est exécuté en tant que service.

  2. En tant que processus interactif avec ouverture de session automatique activée. Dans certains cas, vous devrez peut-être exécuter l’agent de manière interactive pour une utilisation en production, par exemple pour exécuter des tests de l’interface utilisateur. Quand l’agent est configuré pour s’exécuter dans ce mode, l’écran de veille est également désactivé. Il est possible que certaines stratégies vous empêchent d’activer l’ouverture de session automatique ou la désactivation de l’écran de veille. Dans de tels cas, vous devrez peut-être rechercher une exemption dans la stratégie de domaine ou exécuter l’agent sur un ordinateur de groupe de travail où les stratégies de domaine ne s’appliquent pas.

    Remarque

    Activer l’ouverture de session automatique ou désactiver l’économiseur d’écran présente des risques, car vous permettez à d’autres utilisateurs d’utiliser l’ordinateur et le compte qui se connecte automatiquement. Si vous configurez l’agent pour qu’il s’exécute de cette manière, vous devez vous assurer que l’ordinateur est physiquement protégé, par exemple, situé dans une installation sécurisée. Si vous utilisez Bureau à distance pour accéder à l’ordinateur sur lequel un agent s’exécute avec l’ouverture de session automatique, le simple fait de fermer le Bureau à distance entraîne le verrouillage de l’ordinateur et l’échec éventuel de tous les tests de l’interface utilisateur qui s’exécutent sur cet agent. Pour éviter cela, utilisez la commande tscon pour vous déconnecter du Bureau à distance. Par exemple :

    %windir%\System32\tscon.exe 1 /dest:console

Compte de l’agent

Vous pouvez choisir le compte d’ordinateur à utiliser pour exécuter l’agent que vous l’exécutiez en tant que service ou interactivement. (Notez que ces informations diffèrent des informations d’identification que vous utilisez pour inscrire l’agent auprès d’Azure Pipelines ou d’Azure DevOps Server.) Le choix du compte d’agent dépend uniquement des besoins des tâches qui s’exécutent dans vos travaux de build et de déploiement.

Par exemple, pour exécuter des tâches qui utilisent l’Authentification Windows afin d’accéder à un service externe, vous devez exécuter l’agent à l’aide d’un compte ayant accès à ce service. Toutefois, si vous exécutez des tests d’interface utilisateur comme des tests Selenium ou codés qui nécessitent un navigateur, celui-ci est lancé dans le contexte du compte de l’agent.

Sur Windows, vous devez envisager d’utiliser un compte de service comme Service réseau ou Service local. Ces comptes disposent d’autorisations limitées et leurs mots de passe n’expirent pas, ce qui signifie que l’agent nécessite moins de gestion au fil du temps.

Version et mises à niveau de l’agent

Nous mettons à jour le logiciel de l’agent à un intervalle de quelques semaines dans Azure Pipelines. Nous indiquons la version de l’agent au format {major}.{minor}. Par exemple, si la version de l’agent est 2.1, la version principale est 2 et la version mineure est 1.

Les agents hébergés par Microsoft sont toujours tenus à jour. Si la version la plus récente de l’agent diffère uniquement en tant que version mineure, les agents auto-hébergés peuvent généralement être mis à jour automatiquement par Azure Pipelines (configurez ce paramètre dans Pools d’agents, sélectionnez votre agent, Paramètres – la valeur par défaut est activée). Une mise à niveau est nécessaire quand une fonctionnalité de la plateforme ou l’une des tâches utilisées dans le pipeline nécessite une version plus récente de l’agent.

Si vous exécutez un agent auto-hébergé de manière interactive ou si une version majeure plus récente de l’agent est disponible, il est possible que vous deviez mettre à niveau les agents de manière manuelle. Vous pouvez effectuer cette opération facilement à partir de l’onglet Pools d’agents sous votre organisation. Vos pipelines ne s’exécutent pas tant qu’ils ne peuvent pas cibler un agent compatible.

Pour mettre à jour les agents auto-hébergés

  1. Accédez à Paramètres du projet, Pools d’agents.

    Project settings, Agent pools

  2. Sélectionnez votre pool d’agents et choisissez Mettre à jour tous les agents.

    Update all agents

    Vous pouvez également mettre à jour les agents individuellement en choisissant Mettre à jour l’agent dans le menu ....

    Update agent

  3. Sélectionnez Mettre à jour pour confirmer la mise à jour.

    Update all agents confirmation

  4. Une demande de mise à jour est mise en file d’attente pour chaque agent du pool et s’exécute quand les travaux en cours sont terminés. La mise à niveau ne dure généralement que quelques instants : il s’agit du temps nécessaire pour télécharger la dernière version du logiciel de l’agent (environ 200 Mo), la décompresser et redémarrer l’agent avec la nouvelle version. Vous pouvez superviser l’état de vos agents sous l’onglet Agents.

Nous mettons à jour le logiciel de l’agent à chaque mise à jour dans Azure DevOps Server et TFS. Nous indiquons la version de l’agent au format {major}.{minor}. Par exemple, si la version de l’agent est 2.1, la version principale est 2 et la version mineure est 1.

Quand votre serveur Azure DevOps Server ou TFS dispose d’une version plus récente de l’agent et que celui-ci ne diffère qu’en tant que version mineure, il peut généralement être mis à niveau automatiquement. Une mise à niveau est nécessaire quand une fonctionnalité de la plateforme ou l’une des tâches utilisées dans le pipeline nécessite une version plus récente de l’agent. À compter d’Azure DevOps Server 2019, il n’est pas nécessaire d’attendre une nouvelle version du serveur. Vous pouvez charger une nouvelle version de l’agent dans votre couche Application, qui est proposée en tant que mise à niveau.

Si vous exécutez l’agent de manière interactive ou si une version majeure plus récente de l’agent est disponible, il est possible que vous deviez mettre à niveau les agents de manière manuelle. Vous pouvez effectuer cette opération facilement sous l’onglet Pools d’agents dans votre collection de projets. Vos pipelines ne s’exécutent pas tant qu’ils ne peuvent pas cibler un agent compatible.

Vous pouvez consulter la version d’un agent en accédant à Pools d’agents et en sélectionnant l’onglet Capacités de l’agent souhaité, comme décrit à la section Configurer les capacités de l’agent.

Pour déclencher la mise à jour de l’agent programmatiquement, vous pouvez utiliser l’API de mise à jour de l’agent comme décrit dans la section Procédure pour déclencher des mises à jour de l’agent programmatiquement pour un pool d’agents spécifique.

Remarque

Pour les serveurs sans accès à Internet, copiez manuellement le fichier zip de l’agent dans le dossier suivant pour l’utiliser en tant fichier local. Créez le dossier Agents s’il n’est pas présent.

  • Windows : %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux : usr/share/Microsoft/Azure DevOps/Agents
  • MacOS : usr/share/Microsoft/Azure DevOps/Agents

Créez le dossier Agents s’il n’est pas présent.

FAQ

Comment vérifier que j’ai bien la dernière version de l’agent v2 ?

  1. Accédez à l’onglet Pools d’agents :

    1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

    2. Choisissez Azure DevOps, Paramètres de l’organisation.

      Choose Organization settings.

    3. Choisissez Pools d’agents.

      Choose Agent pools tab.

    1. Connectez-vous à votre collection de projets (http://your-server/DefaultCollection).

    2. Choisissez Azure DevOps, Paramètres de la collection.

      Choose Collection settings.

    3. Choisissez Pools d’agents.

      Choose Agent pools.

    1. Choisissez Azure DevOps, Paramètres de la collection.

      Collection settings, 2019.

    2. Choisissez Pools d’agents.

      Choose Agent pools, 2019.

    1. Accédez à votre projet et choisissez Paramètres (icône d’engrenage) >Files d’attente d’agents.

      Choose Settings, Agent Queues, 2018.

    2. Choisissez Gérer les pools.

      Choose Manage pools, 2018.

  2. Cliquez sur le pool qui contient l’agent.

  3. Vérifiez que l’agent est activé.

  4. Accédez à l’onglet Capacités :

    1. Sous l’onglet Pools d’agents, sélectionnez le pool d’agents souhaité.

      From Agent pools, select the desired agent pool.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Select Agents and choose the agent.

    3. Choisissez l’onglet Fonctionnalités.

      Choose the Capabilities tab.

      Notes

      Les agents hébergés par Microsoft n’affichent pas de fonctionnalités système. Pour obtenir la liste des logiciels installés sur des agents hébergés par Microsoft, consultez Utiliser un agent hébergé par Microsoft.

    1. Sous l’onglet Pools d’agents, sélectionnez le pool souhaité.

      Select the desired pool.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Select Agents and choose the desired agent.

    3. Choisissez l’onglet Fonctionnalités.

      Agent capabilities tab.

    1. Sous l’onglet Pools d’agents, sélectionnez le pool souhaité.

      Select the desired tab, 2019.

    2. Sélectionnez Agents et choisissez l’agent souhaité.

      Choose the desired agent, 2019.

    3. Choisissez l’onglet Fonctionnalités.

      Choose the Capabilities tab, 2019.

    Sélectionnez l’agent souhaité, puis choisissez l’onglet Fonctionnalités.

    Agent capabilities tab, 2018.

  5. Recherchez la capacité Agent.Version. Vous pouvez vérifier cette valeur en la comparant à la dernière version publiée de l’agent. Consultez Agent Azure Pipelines et recherchez le numéro de version le plus élevé dans la page.

  6. Chaque agent est mis à jour automatiquement quand il exécute une tâche nécessitant une version plus récente de l’agent. Si vous souhaitez mettre à jour manuellement certains agents, cliquez avec le bouton droit sur le pool, puis sélectionnez Mettre à jour tous les agents.

Puis-je mettre à jour mes agents v2 qui font partie d’un pool Azure DevOps Server ?

Oui. À partir d’Azure DevOps Server 2019, vous pouvez configurer votre serveur pour rechercher les fichiers de package d’agent sur un disque local. Cette configuration remplace la version par défaut fournie avec le serveur au moment de sa publication. Ce scénario s’applique également quand le serveur n’a pas accès à Internet.

  1. À partir d’un ordinateur disposant d’un accès Internet, téléchargez la dernière version des fichiers de package d’agent (au format .zip ou .tar.gz) à partir de la page GitHub des versions d’agent Azure Pipelines.

  2. Transférez les fichiers de package téléchargés vers chaque couche Application d’Azure DevOps Server avec la méthode de votre choix (par exemple, lecteur USB, transfert réseau, etc.). Placez les fichiers de l’agent sous le dossier %ProgramData%\Microsoft\Azure DevOps\Agents. Créez le dossier Agents s’il n’est pas présent.

  3. Vous êtes prêt à commencer ! Votre serveur Azure DevOps Server utilise désormais les fichiers locaux à chaque mise à jour des agents. Chaque agent est mis à jour automatiquement quand il exécute une tâche nécessitant une version plus récente de l’agent. Toutefois, si vous souhaitez mettre à jour manuellement certains agents, cliquez avec le bouton droit sur le pool, puis choisissez Mettre à jour tous les agents.

Les agents auto-hébergés présentent-ils des avantages en termes de performances par rapport aux agents hébergés par Microsoft ?

Dans de nombreux cas, oui. Plus précisément :

  • Si vous utilisez un agent auto-hébergé, vous pouvez exécuter des builds incrémentielles. Par exemple, si vous définissez un pipeline qui ne nettoie pas le référentiel et n’effectue pas de nettoyage de build, vos builds s’exécutent généralement plus rapidement. Vous ne bénéficiez pas de ces avantages quand vous utilisez un agent hébergé par Microsoft (sauf si vous utilisez des fonctionnalités telles que la mise en cache), car l’agent est détruit une fois que le pipeline de build ou de mise en production est terminé.

  • Un agent hébergé par Microsoft peut prendre plus de temps pour démarrer votre build. Même s’il ne faut que quelques secondes pour que votre travail soit attribué à un agent hébergé par Microsoft, l’allocation d’un agent peut parfois prendre plusieurs minutes, en fonction de la charge sur notre système.

Puis-je installer plusieurs agents auto-hébergés sur la même machine ?

Oui. Cette approche peut fonctionner correctement pour les agents exécutant des travaux qui ne consomment pas de nombreuses ressources partagées. Par exemple, vous pouvez l’essayer pour les agents qui exécutent des versions qui orchestrent principalement des déploiements et ne font pas grand-chose sur l’agent lui-même.

Dans les autres cas, vous pouvez constater que l’exécution de plusieurs agents sur la même machine n’améliore pas sensiblement l’efficacité. Cette approche peut par exemple être superflue pour les agents exécutant des builds qui consomment de nombreuses ressources de disque et d’E/S.

Vous pouvez également rencontrer des problèmes si des travaux de build parallèles utilisent le même déploiement d’outil singleton, comme les packages npm. Par exemple, une build peut mettre à jour une dépendance alors qu’une autre build est en train de l’utiliser, ce qui peut entraîner des résultats non fiables et des erreurs.

Quel est le comportement des agents quand les travaux de pipeline sont annulés ?

Pour les agents hébergés par Microsoft, l’agent est détruit et renvoyé au pool Azure Pipelines.

Pour les agents auto-hébergés :

Quand un pipeline est annulé, l’agent envoie une séquence de commandes au processus qui exécute l’étape actuelle. La première commande est envoyée avec un délai d’expiration de 7,5 secondes. Si le processus n’est pas terminé, une deuxième commande est envoyée avec un délai d’expiration de 2,5 secondes. Si le processus n’est pas terminé, l’agent émet une commande pour tuer le processus. Si le processus ne respecte pas les deux demandes d’arrêt initiales, il est tué. Le processus dure environ 10 secondes de la demande initiale à l’arrêt.

Les commandes émises pour le processus afin d’annuler le pipeline diffèrent selon le système d’exploitation de l’agent.

  • macOS et Linux : les commandes envoyées sont SIGINT, suivies de SIGTERM, puis de SIGKILL.
  • Windows : les commandes envoyées au processus sont Ctrl+C, suivies de Ctrl+Arrêt, puis de Process.Kill.

Procédure pour déclencher des mises à jour de l’agent programmatiquement pour un pool d’agents spécifique

Vous pouvez déclencher des mises à jour de l’agent pour le pool en tirant parti de l’API suivante :

POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0
POST https://{server url}/tfs/{collection}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

Remarque

Pour obtenir plus d’informations sur l’API et le mappage de version AZURE DevOps Server et TFS, consulter API et mappage de version TFS

Paramètres URI

Nom Dans Obligatoire Type Description
agentId query False string Agent à mettre à jour. Si la valeur n’est pas spécifiée, la mise à jour est déclenchée pour tous les agents.
organization path True string Nom de l’organisation Azure DevOps.
poolId path True entier int32 Pool d’agents à utiliser
api-version query False string Version de l’API à utiliser. Cette valeur doit être définie sur « 6.0 » pour utiliser cette version de l’API.

Pour déclencher la mise à jour de l’agent, le corps de la demande doit être vide.

Remarque

L’agent Azure Pipelines est en open source sur GitHub.

En savoir plus

Pour plus d’informations sur les agents, consultez les modules suivants du parcours d’apprentissage Créer des applications avec Azure DevOps.