Agents Azure Pipelines

  • Article
  • 27 minutes de lecture

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

Notes

Dans Microsoft Team Foundation Server (TFS) 2018 et les versions antérieures, 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 et 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.

Lorsque votre pipeline s’exécute, le système commence un ou plusieurs travaux. Un agent est une infrastructure informatique avec un logiciel d’agent installé qui exécute un travail à la fois.

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

agents hébergés par Microsoft

Si vos pipelines se trouvent dans Azure Pipelines, vous avez une option pratique pour exécuter vos travaux à 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. Chaque fois que vous exécutez un pipeline, vous obtenez une nouvelle machine virtuelle pour chaque travail dans le pipeline. La machine virtuelle est ignorée après un travail (ce qui signifie que toute modification apportée par un travail au système de fichiers de la machine virtuelle, telle que l’extraction de code, ne sera pas disponible pour le travail suivant). Microsoft agents hébergés peuvent exécuter des travaux directement sur la machine virtuelle ou dans un conteneur.

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

Pour de nombreuses équipes, il s’agit du moyen le plus simple d’exécuter vos 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, utilisez un agent autohébergé.

Conseil

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

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

Agents auto-hébergés

Un agent que vous configurez et gérez vous-même pour exécuter des travaux est un agent auto-hébergé. 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 l’ordinateur sont conservés d’une exécution à l’autre, ce qui peut augmenter la vitesse.

Notes

Bien que plusieurs agents puissent être installés par machine, nous vous recommandons vivement d’installer un seul agent par machine. L’installation de deux agents ou plus peut nuire aux performances et au résultat de vos pipelines.

Conseil

Avant d’installer un agent auto-hébergé, vous souhaiterez peut-être voir si un pool d’agents hébergés par Microsoft fonctionnera pour vous. Dans de nombreux cas, il s’agit de la façon la plus simple d’aller de l’avant. Essayez-le.

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 la protection Gatekeeper de s’afficher pour chaque assembly dans le fichier tar lors ./config.sh de l’exécution. 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.

Notes

Les agents sont largement rétrocompatibles. Toute version de l’agent doit être compatible avec n’importe quelle version d’Azure DevOps tant qu’Azure DevOps ne demande pas une version supé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 pour avoir tous les correctifs et correctifs de bogues à jour.

Agents de groupe de machines virtuelles identiques Azure

Les agents de groupe de machines virtuelles identiques Azure sont une forme d’agents auto-hébergés qui peuvent être mis à l’échelle automatiquement pour répondre à vos besoins. 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 identique, 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 en même temps 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, tout travail simultané supplémentaire étant mis en file d’attente jusqu’à ce que le premier travail soit terminé. Pour exécuter deux travaux en même temps, vous avez besoin de deux travaux parallèles. Dans Azure Pipelines, vous pouvez exécuter des travaux parallèles sur Microsoft’infrastructure hébergée ou sur votre propre infrastructure (auto-hébergée).

Microsoft fournit un niveau de service gratuit par défaut dans chaque organisation qui comprend au moins un travail parallèle. Selon le nombre de pipelines simultanés que vous devez exécuter, vous aurez peut-être besoin d’un plus grand nombre de travaux parallèles pour utiliser plusieurs agents hébergés Microsoft ou auto-hébergés en même temps. 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 aurez peut-être besoin d’un plus grand nombre de travaux parallèles pour utiliser plusieurs agents en même temps :

Important

À compter de Azure DevOps Server 2019, vous n’avez pas à payer pour les travaux simultanés auto-hébergés dans les versions. Vous n’êtes limité que par le nombre d’agents dont vous disposez.

Fonctionnalités

Chaque agent auto-hébergé a un ensemble de fonctionnalités qui indiquent ce qu’il peut faire. Les fonctionnalités sont des paires nom-valeur qui sont découvertes automatiquement par le logiciel de l’agent, auquel cas elles sont appelées fonctionnalités système, ou celles que vous définissez, auquel cas elles sont appelées fonctionnalités utilisateur.

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

Notes

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

Lorsque vous créez un pipeline, vous spécifiez certaines demandes de l’agent. Le système envoie le travail uniquement aux agents qui ont des fonctionnalités correspondant aux demandes spécifiées dans le pipeline. Par conséquent, les fonctionnalités de l’agent vous permettent de diriger des travaux vers des agents spécifiques.

Notes

Les demandes et les fonctionnalités sont conçues pour être utilisées avec des agents auto-hébergés afin que les travaux puissent être mis en correspondance avec un agent qui répond aux exigences du travail. Lorsque vous utilisez des agents hébergés Microsoft, vous sélectionnez une image pour l’agent qui correspond aux exigences du travail. Par conséquent, bien qu’il soit possible d’ajouter des fonctionnalités à un agent hébergé Microsoft, vous n’avez pas besoin d’utiliser des fonctionnalités avec des agents hébergés Microsoft.

Configurer les fonctionnalités de l’agent

Vous pouvez afficher les détails d’un agent, notamment sa version et ses fonctionnalités système, et gérer ses fonctionnalités utilisateur, en accédant à Pools d’agents et en sélectionnant l’onglet Fonctionnalités de l’agent souhaité.

  1. Dans votre navigateur web, accédez à Pools d’agents :

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

      Choisissez Paramètres de l’organisation.

    2. Choisissez Pools d’agents.

      Choisissez l’onglet Pools d’agents.

    1. Choisissez Azure DevOps, Paramètres du regroupement.

      Choisissez Paramètres du regroupement.

    2. Choisissez Pools d’agents.

      Choisissez Pools d’agents.

    1. Choisissez Azure DevOps, Paramètres du regroupement.

      Paramètres de collection, 2019.

    2. Choisissez Pools d’agents.

      Choisissez Pools d’agents, 2019.

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

      Choisissez Paramètres, Files d’attente de l’agent, 2018.

    2. Choisissez Gérer les pools.

      Choisissez Gérer les pools, 2018.

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

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

      Dans Pools d’agents, sélectionnez le pool d’agents souhaité.

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

      Sélectionnez Agents et choisissez l’agent.

    3. Choisissez l’onglet Fonctionnalités .

      Choisissez l’onglet Fonctionnalités.

      Notes

      Microsoft agents hébergés n’affichent pas les fonctionnalités système. Pour obtenir la liste des logiciels installés sur les 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é.

      Sélectionnez le pool souhaité.

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

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

    3. Choisissez l’onglet Fonctionnalités .

      Onglet Fonctionnalités de l’agent.

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

      Sélectionnez l’onglet souhaité, 2019.

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

      Choisissez l’agent souhaité, 2019.

    3. Choisissez l’onglet Fonctionnalités .

      Choisissez l’onglet Fonctionnalités, 2019.

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

    Onglet Fonctionnalités de l’agent, 2018.

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

Conseil

Après avoir installé de nouveaux logiciels sur un agent auto-hébergé, vous devez redémarrer l’agent pour que la nouvelle fonctionnalité 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 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.

Topologies d’agent dans les installations locales.

Topologies d’agent dans 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 de Azure DevOps Server en l’ajoutant à un pool d’agents. Vous devez être 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. Lorsqu’un travail est disponible, l’agent télécharge le travail ainsi qu’un jeton OAuth spécifique au travail. Ce jeton est généré par Azure Pipelines/Azure DevOps Server pour l’identité étendue 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.

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ù sont déployés les agents hébergés par Microsoft afin de pouvoir configurer les règles de pare-feu de votre réseau virtuel Azure afin d’autoriser l’accès par l’agent.

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.

Connectivité de l’agent pour les environnements locaux

Authentification

Pour inscrire un agent, vous devez être membre 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.

Votre agent peut s’authentifier auprès d’Azure Pipelines en utilisant l’une des méthodes suivantes :

Votre agent peut s’authentifier auprès de Azure DevOps Server ou TFS à l’aide de l’une des méthodes suivantes :

Jeton d’accès personnel (PAT) :

Générez et utilisez un PAT pour connecter un agent à Azure Pipelines ou TFS 2017 et versions ultérieures. Le PAT est le seul schéma qui fonctionne avec Azure Pipelines. Le PAT doit avoir une étendue pools d’agents (lecture, gestion) (pour un agent de groupe de déploiement , le PAT doit avoir l’étendue Groupe de déploiement (lecture, gestion) et bien qu’un seul PAT puisse être utilisé pour inscrire plusieurs agents, le PAT est utilisé uniquement au moment de l’inscription de l’agent, et non pour la communication ultérieure. Pour plus d’informations, consultez la section Authentifier avec un jeton d’accès personnel (PAT) dans les articles sur les agents auto-hébergés Windows, Linux ou macOS .

Pour utiliser un PAT avec Azure DevOps Server, votre serveur doit être configuré avec HTTPS. Consultez Paramètres et sécurité du site web.

Intégré

Connectez un agent Windows à TFS à l’aide des informations d’identification de l’utilisateur connecté via un schéma de Authentification Windows tel que NTLM ou Kerberos.

Pour utiliser cette méthode d’authentification, vous devez d’abord configurer votre serveur TFS.

  1. Connectez-vous à l’ordinateur sur lequel vous exécutez TFS.

  2. Démarrez le Gestionnaire des services Internet (IIS). Sélectionnez votre site TFS et vérifiez que l’authentification Windows est activée avec un fournisseur valide tel que NTLM ou Kerberos.

Authentification windows IIS TFS

Authentification windows IIS TFS avec le fournisseur ntlm

Negotiate

Connectez-vous à TFS en tant qu’utilisateur autre que l’utilisateur connecté via un schéma de Authentification Windows tel que NTLM ou Kerberos.

Pour utiliser cette méthode d’authentification, vous devez d’abord configurer votre serveur TFS.

  1. Connectez-vous à l’ordinateur sur lequel vous exécutez TFS.

  2. Démarrez le Gestionnaire des services Internet (IIS). Sélectionnez votre site TFS et vérifiez que l’authentification Windows est activée avec le fournisseur Negotiate et avec une autre méthode telle que NTLM ou Kerberos.

Authentification windows IIS TFS

Authentification windows IIS TFS avec le fournisseur négocier et ntlm

Alterner

Connectez-vous à TFS à l’aide de l’authentification de base. Pour utiliser cette méthode, vous devez d’abord configurer HTTPS sur TFS.

Pour utiliser cette méthode d’authentification, vous devez configurer votre serveur TFS comme suit :

  1. Connectez-vous à l’ordinateur sur lequel vous exécutez TFS.

  2. Configurez l’authentification de base. Consultez Utilisation tfx par rapport à Team Foundation Server 2015 à l’aide de l’authentification de base.

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é. Certaines stratégies de domaine peuvent vous empêcher d’activer l’ouverture de session automatique ou de désactiver l’écran de veille. Dans ce cas, vous devrez peut-être rechercher une exemption de 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.

    Notes

    Il existe des risques de sécurité lorsque vous activez l’ouverture de session automatique ou désactivez l’économiseur d’écran, car vous permettez à d’autres utilisateurs d’aller jusqu’à l’ordinateur et d’utiliser 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 le Bureau à distance pour accéder à l’ordinateur sur lequel un agent s’exécute avec ouverture de session automatique, la simple fermeture du Bureau à distance entraîne le verrouillage de l’ordinateur et les tests d’interface utilisateur qui s’exécutent sur cet agent peuvent échouer. Pour éviter cela, utilisez la commande tscon pour vous déconnecter du Bureau à distance. Par exemple :

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

Compte d’agent

Que vous exécutiez un agent en tant que service ou de manière interactive, vous pouvez choisir le compte d’ordinateur que vous utilisez pour exécuter l’agent. (Notez que cela diffère des informations d’identification que vous utilisez lorsque vous inscrivez l’agent auprès d’Azure Pipelines ou Azure DevOps Server.) Le choix du compte d’agent dépend uniquement des besoins des tâches exécutées dans vos travaux de génération et de déploiement.

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

Sur Windows, vous devez envisager d’utiliser un compte de service tel que Service réseau ou Service local. Ces comptes ont des autorisations restreintes 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 toutes les 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.

Microsoft agents hébergés sont toujours tenus à jour. Si la version la plus récente de l’agent est uniquement différente en version mineure , les agents auto-hébergés peuvent généralement être mis à jour automatiquement (configurez ce paramètre dans pools d’agents, sélectionnez votre agent, Paramètres - la valeur par défaut est activée) par Azure Pipelines. Une mise à niveau est demandée lorsqu’une fonctionnalité de 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, vous devrez peut-être mettre à niveau manuellement les agents. Vous pouvez le faire 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.

    Paramètres de projet, Pools d’agents

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

    Mettre à jour tous les agents

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

    Mettre à jour l’agent

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

    Mettre à jour la confirmation de tous les agents

  4. Une demande de mise à jour est mise en file d’attente pour chaque agent dans le pool et s’exécute lorsque les travaux en cours d’exécution sont terminés. La mise à niveau ne prend généralement que quelques instants, assez longtemps 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 surveiller l’état de vos agents sous l’onglet Agents .

Nous mettons à jour le logiciel de l’agent avec 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.

Lorsque votre serveur Azure DevOps Server ou TFS dispose d’une version plus récente de l’agent et que cet agent plus récent n’est différent que dans la version mineure, il peut généralement être mis à niveau automatiquement. Une mise à niveau est demandée lorsqu’une fonctionnalité de plateforme ou l’une des tâches utilisées dans le pipeline nécessite une version plus récente de l’agent. À compter de Azure DevOps Server 2019, vous n’avez pas besoin d’attendre une nouvelle version du serveur. Vous pouvez charger une nouvelle version de l’agent dans votre couche Application, et cette version sera proposée en tant que mise à niveau.

Si vous exécutez l’agent de manière interactive ou s’il existe une version majeure plus récente de l’agent disponible, vous devrez peut-être mettre à niveau manuellement les agents. Vous pouvez le faire facilement à partir de l’onglet Pools d’agents sous votre collection de projets. Vos pipelines ne s’exécutent pas tant qu’ils ne peuvent pas cibler un agent compatible.

Vous pouvez afficher la version d’un agent en accédant à Pools d’agents et en sélectionnant l’onglet Fonctionnalités de l’agent souhaité, comme décrit dans Configurer les fonctionnalités de l’agent.

Pour déclencher la mise à jour de l’agent par programme, vous pouvez utiliser l’API de mise à jour de l’agent comme décrit dans la section Comment déclencher des mises à jour de l’agent par programmation pour un pool d’agents spécifique ?.

Notes

Pour les serveurs sans accès à Internet, copiez manuellement le fichier zip de l’agent sur pour C:\ProgramData\Microsoft\Azure DevOps\Agents\ l’utiliser en tant que fichier local.

Questions fréquentes (FAQ)

Comment faire vérifier que je dispose de la dernière version de l’agent v2 ?

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

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

      Choisissez Paramètres de l’organisation.

    2. Choisissez Pools d’agents.

      Choisissez l’onglet Pools d’agents.

    1. Choisissez Azure DevOps, Paramètres du regroupement.

      Choisissez Paramètres du regroupement.

    2. Choisissez Pools d’agents.

      Choisissez Pools d’agents.

    1. Choisissez Azure DevOps, Paramètres du regroupement.

      Paramètres de collection, 2019.

    2. Choisissez Pools d’agents.

      Choisissez Pools d’agents, 2019.

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

      Choisissez Paramètres, Files d’attente de l’agent, 2018.

    2. Choisissez Gérer les pools.

      Choisissez Gérer les pools, 2018.

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

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

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

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

      Dans Pools d’agents, sélectionnez le pool d’agents souhaité.

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

      Sélectionnez Agents et choisissez l’agent.

    3. Choisissez l’onglet Fonctionnalités .

      Choisissez l’onglet Fonctionnalités.

      Notes

      Microsoft agents hébergés n’affichent pas les 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é.

      Sélectionnez le pool souhaité.

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

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

    3. Choisissez l’onglet Fonctionnalités .

      Onglet Fonctionnalités de l’agent.

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

      Sélectionnez l’onglet souhaité, 2019.

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

      Choisissez l’agent souhaité, 2019.

    3. Choisissez l’onglet Fonctionnalités .

      Choisissez l’onglet Fonctionnalités, 2019.

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

    Onglet Fonctionnalités de l’agent, 2018.

  5. Recherchez la Agent.Version fonctionnalité. Vous pouvez vérifier cette valeur par rapport à la dernière version publiée de l’agent. Consultez Agent Azure Pipelines et consultez la page pour connaître le numéro de version le plus élevé répertorié.

  6. Chaque agent se met automatiquement à jour lorsqu’il exécute une tâche qui nécessite 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. À compter de Azure DevOps Server 2019, vous pouvez configurer votre serveur pour rechercher les fichiers de package d’agent sur un disque local. Cette configuration remplacera la version par défaut qui était fourni avec le serveur au moment de sa publication. Ce scénario s’applique également lorsque 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 (sous forme .zip ou .tar.gz) à partir de la page Versions GitHub de l’agent Azure Pipelines.

  2. Transférez les fichiers de package téléchargés vers chaque Azure DevOps Server niveau Application à l’aide d’une méthode de votre choix (par exemple, lecteur USB, transfert réseau, etc.). Placez les fichiers de l’agent sous le %ProgramData%\Microsoft\Azure DevOps\Agents dossier .

  3. Tu es prêt ! Votre Azure DevOps Server utilise désormais les fichiers locaux chaque fois que les agents sont mis à jour. Chaque agent se met automatiquement à jour lorsqu’il exécute une tâche qui nécessite 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 dépôt et n’effectue pas de build propre, vos builds s’exécutent généralement plus rapidement. Lorsque vous utilisez un agent hébergé Microsoft, vous ne bénéficiez pas de ces avantages, car l’agent est détruit une fois le pipeline de build ou de mise en production terminé.

  • Un agent hébergé par Microsoft peut prendre plus de temps pour démarrer votre build. Bien qu’il ne prenne souvent que quelques secondes pour que votre travail soit affecté à 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 qui exécutent des travaux qui ne consomment pas beaucoup de 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.

Vous pouvez constater que dans d’autres cas, vous n’obtenez pas beaucoup d’efficacité en exécutant plusieurs agents sur le même ordinateur. Par exemple, cela peut ne pas être utile pour les agents qui exécutent des builds qui consomment beaucoup de disques et de ressources d’E/S.

Vous pouvez également rencontrez des problèmes si des travaux de génération parallèles utilisent le même déploiement d’outil singleton, par exemple des 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 lorsque les travaux de pipeline sont annulés ?

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

Pour les agents auto-hébergés :

Lorsqu’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 arrêter le processus. Si le processus ne respecte pas les deux demandes d’arrêt initiales, il est supprimé. De la demande initiale à l’arrêt prend environ 10 secondes.

Les commandes émises pour le processus d’annulation du pipeline diffèrent en fonction du 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.

Comment déclencher des mises à jour de l’agent par programmation pour un pool d’agents spécifique ?

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

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

Paramètres URI

Nom Dans Obligatoire Type Description
agentId query False string Agent à mettre à jour. Si elle 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.

Notes

L’agent Azure Pipelines est 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 .