Pipelines de mise en production et sources d’artefacts

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

Avec Azure Pipelines, vous pouvez déployer vos artefacts à partir d’un large éventail de sources d’artefacts et intégrer votre workflow à différents types de référentiels d’artefacts. Les mises en production peuvent être liées à plusieurs sources d’artefacts, dont une est désignée comme source principale.

Sources d'artefact

Azure Pipelines prend en charge un large éventail de référentiels, d’outils de contrôle de code source et de systèmes d’intégration continue.

Lors de la création d’une mise en production, vous pouvez spécifier la version de votre source d’artefact. Par défaut, les mises en production utilisent la dernière version de l’artefact source. Vous pouvez également choisir d’utiliser la dernière build d’une branche spécifique en spécifiant les balises, une version spécifique, ou autoriser l’utilisateur à spécifier la version au moment de la création de la mise en production.

Capture d’écran montrant comment ajouter un artefact à un pipeline de mise en production classique.

Si vous liez plusieurs artefacts, vous pouvez spécifier celui qui est la source principale (par défaut). La source d’artefact principale est utilisée pour définir un certain nombre de variables prédéfinies. Elle peut également être utilisée dans les versions de nommage.

Capture d’écran montrant comment définir un artefact source principal.

Notes

Les Default version éléments de la liste déroulante dépendent du type de source de la définition de build liée.

  • Les options suivantes sont prises en charge par tous les types de référentiels : Specify at the time of release creation, Specific version et Latest.

  • Les options Latest from a specific branch with tags et Latest from the build pipeline default branch with tags sont prises en charge par tous les types de référentiels suivants : TfsGit, GitHub, Bitbucket et GitHubEnterprise.

  • Latest from the build pipeline default branch with tags n’est pas pris en charge par XAML les définitions de build.

Les sections suivantes décrivent comment utiliser les différents types de sources d’artefacts.

Sources d’artefacts - Azure Pipelines

Vous pouvez lier un pipeline de mise en production à n’importe quelle build Azure Pipelines. Vous pouvez également lier plusieurs pipelines de build et spécifier leurs valeurs par défaut et configurer des déclencheurs de déploiement sur plusieurs sources de build. Une fois l’une des builds terminée, elle déclenche la création d’une mise en production.

Les fonctionnalités suivantes sont disponibles lors de l’utilisation d’Azure Pipelines comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.
Phases de déploiement La liste récapitulative de build répertorie toutes les étapes de déploiement dans lesquelles l’artefact a été déployé.

Notes

Vous devez inclure une tâche Publier des artefacts dans votre pipeline de build. Pour les pipelines de build YAML, un artefact avec le nom annuler est publié implicitement.

Par défaut, les mises en production s’exécutent avec une étendue d’autorisation de travail au niveau de la collection. Cela signifie que les mises en production peuvent accéder aux ressources de tous les projets de l’organisation (ou de la collection pour Azure DevOps Server). Cela est utile lors de la liaison d’artefacts de build à partir d’autres projets. Vous pouvez activer Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines de mise en production dans les paramètres du projet afin de restreindre l’accès à l’artefact d’un projet.

Pour définir l’étendue d’autorisation de travail pour l’organisation :

  • Accédez à vos paramètres d’organisation.
  • Sélectionnez Paramètres sous Pipelines.
  • Activez le bouton bascule Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production afin de limiter l’étendue au projet actuel. Il s’agit du paramètre recommandé pour une bonne mesure de sécurité.

Pour définir l’étendue d’autorisation de travail pour un projet spécifique :

  • Accédez aux paramètres de votre projet.
  • Sélectionnez Paramètres sous Pipelines.
  • Activez le bouton bascule Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production afin de limiter l’étendue au projet actuel. Il s’agit du paramètre recommandé, car il améliore la sécurité de vos pipelines.

Notes

Si l’étendue est définie sur un projet au niveau de l’organisation, vous ne pouvez pas modifier l’étendue dans chaque projet.

Tous les travaux d’une mise en production s’exécutent avec l’étendue d’autorisation de travail définie sur collection. En d’autres termes, ces travaux ont accès aux ressources de tous les projets de votre collection de projets.

Sources d’artefacts - contrôle de version

Il existe certains scénarios dans lesquels vous pouvez utiliser directement des artefacts à partir de différents contrôles source sans les transmettre par le biais d’un pipeline de build. Par exemple :

  • Développement d’une application PHP ou JavaScript qui ne nécessite pas de pipeline de build explicite.

  • Vous gérez les configurations pour différentes étapes dans différents référentiels de contrôle de version et vous souhaitez utiliser ces fichiers de configuration directement à partir du contrôle de version dans le cadre du pipeline de déploiement.

  • Vous gérez votre infrastructure et votre configuration en tant que code et vous souhaitez gérer ces fichiers dans un référentiel de contrôle de version.

Étant donné que vous pouvez configurer plusieurs sources d’artefacts dans un pipeline de mise en production unique, vous pouvez lier à la fois un pipeline de build qui produit les fichiers binaires de votre application ainsi qu’un référentiel de contrôle de version qui stocke les fichiers de configuration dans le même pipeline et utiliser simultanément les deux ensembles d’artefacts lors du déploiement.

Azure Pipelines prend en charge les référentiels Team Foundation Version Control (TFVC), les référentiels Git et les référentiels GitHub.

Vous pouvez lier un pipeline de mise en production à l’un des référentiels Git ou TFVC dans n’importe quel projet de votre collection (vous aurez besoin d’un accès en lecture à ces référentiels). Aucune configuration supplémentaire n’est requise lors du déploiement d’artefacts de contrôle de version au sein de la même collection.

Lorsque vous liez un dépôt GitHub et que vous sélectionnez une branche, vous pouvez modifier les propriétés par défaut des types d’artefacts une fois l’artefact enregistré. Cela est particulièrement utile dans les scénarios où la branche de la version stable de l’artefact a changé, et où les futures mises en production de livraison continue doivent utiliser cette branche pour obtenir des versions plus récentes de l’artefact. Vous pouvez également spécifier les détails de la validation, par exemple les sous-modules de validation et les fichiers LFS suivis, ainsi que la profondeur d’extraction peu profonde.

Lorsque vous liez une branche TFVC, vous pouvez spécifier l’ensemble de modifications à déployer lors de la création d’une mise en production.

Les fonctionnalités suivantes sont disponibles lors de l’utilisation de TFVC, Git et GitHub comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Par défaut, les mises en production s’exécutent avec une étendue d’autorisation de travail au niveau de la collection. Cela signifie que les mises en production peuvent accéder aux ressources de tous les projets de l’organisation (ou de la collection pour Azure DevOps Server). Cela est utile lors de la liaison d’artefacts de build à partir d’autres projets. Vous pouvez activer Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines de mise en production dans les paramètres du projet afin de restreindre l’accès à l’artefact d’un projet.

Sources d’artefacts - Jenkins

Pour utiliser des artefacts Jenkins, vous devez créer une connexion de service pour vous authentifier auprès de votre serveur Jenkins. Pour plus d’informations, consultez Gérer les connexions de service et Connexion au service Jenkins. Le projet Jenkins doit être configuré avec une action post-build pour publier vos artefacts.

Les fonctionnalités suivantes sont disponibles lors de l’utilisation de Jenkins comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Les artefacts générés par les builds Jenkins sont généralement propagés aux référentiels de stockage à des fins d’archivage et de partage. Le stockage blob Azure est l’un des référentiels pris en charge, ce qui vous permet de consommer des projets Jenkins qui publient sur le stockage Azure en tant que sources d’artefacts dans un pipeline de mise en production. Azure Pipelines télécharge automatiquement les artefacts à partir d’Azure vers l’agent exécutant le pipeline. Dans ce scénario, la connectivité entre l’agent et le serveur Jenkins n’est pas nécessaire. Les agents hébergés par Microsoft peuvent être utilisés sans exposer le serveur à Internet.

Notes

Azure Pipelines peut ne pas être en mesure de contacter votre serveur Jenkins si, par exemple, il se trouve dans votre réseau d’entreprise. Si c’est le cas, vous pouvez intégrer Azure Pipelines à Jenkins en configurant un agent local qui peut accéder au serveur Jenkins. Vous ne pourrez pas voir le nom de vos projets Jenkins lors de la liaison à une build, mais vous pouvez entrer le nom dans le champ de texte URL.

Sources d’artefacts - conteneurs

Quand vous déployez des applications conteneurisées, l’image conteneur est d’abord envoyée (push) à un registre de conteneurs. Vous pouvez ensuite déployer votre image conteneur sur Azure Web App pour conteneurs ou sur un cluster Docker/Kubernetes. Vous devez créer une connexion de service pour vous authentifier auprès d’Azure. Pour plus d’informations, consultez Gérer les connexions de service .

Les fonctionnalités suivantes sont disponibles lors de l’utilisation d’Azure Container comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Notes

Lorsque vous utilisez plusieurs sources d’artefacts, le mappage d’une source d’artefact pour déclencher une phase particulière n’est pas pris en charge. Une mise en production est créée chaque fois qu’il y a un envoi (push) vers l’une des sources d’artefact. Si vous le souhaitez, Azure Pipelines recommande de fractionner votre pipeline de mise en production en plusieurs versions.

Sources d’artefacts - Azure Artifacts

Voici quelques-uns des scénarios dans lesquels vous pouvez utiliser Azure Artifacts comme source d’artefact :

  1. Votre fichier binaire d’application est publié sur Azure Artifacts et vous souhaitez utiliser le package dans un pipeline de mise en production.
  2. Vous avez besoin de packages supplémentaires stockés dans Azure Artifacts dans le cadre de votre workflow de déploiement.

À l’aide d’Azure Artifacts dans votre pipeline de mise en production, vous devez sélectionner le flux, le package et la version par défaut de votre package. Vous pouvez choisir de récupérer la dernière version du package, d’utiliser une version spécifique ou de sélectionner la version au moment de la création de la mise en production. Pendant le déploiement, le package est téléchargé/extrait sur l’agent exécutant votre pipeline.

Les fonctionnalités suivantes sont disponibles lors de l’utilisation d’Azure Pipelines comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Gestion des instantanés Maven

Lorsque vous utilisez des instantanés Maven, plusieurs versions peuvent être téléchargées simultanément (exemple myApplication-2.1.0.BUILD-20190920.220048-3.jar, myApplication-2.1.0.BUILD-20190820.221046-2.jar, myApplication-2.1.0.BUILD-20190820.220331-1.jar). Vous devrez peut-être supprimer l’ancienne version et conserver uniquement la dernière version de l’artefact avant le déploiement. Exécutez la commande PowerShell suivante dans une invite de commandes avec élévation de privilèges pour supprimer toutes les copies, à l’exception de celle qui a la valeur lexicographique la plus élevée :

Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item

Notes

Vous pouvez stocker jusqu’à 30 instantanés Maven dans votre flux. Une fois que vous avez atteint la limite maximale, Azure Artifacts supprime automatiquement les instantanés jusqu’à 25. Ce processus est déclenché automatiquement chaque fois que plus de 30 instantanés sont publiés dans votre flux.

Sources d’artefact - Serveur TFS

Vous pouvez utiliser Azure Pipelines pour déployer des artefacts à partir de serveurs TFS sans avoir à rendre votre serveur détectable sur Internet en configurant un agent d’automatisation local. Les artefacts sont téléchargés sur l’agent local, puis déployés sur les serveurs cibles spécifiés sans quitter votre réseau d’entreprise. C’est l’idéal pour les clients de tirer parti de leurs investissements dans leur infrastructure locale tout en tirant parti des versions d’Azure Pipelines.

Pour utiliser des serveurs TFS comme source d’artefacts, vous devez installer l’extension TFS artifacts for Azure Pipelines à partir de Visual Studio Marketplace, puis créer une connexion de service pour vous authentifier auprès d’Azure Pipelines. Une fois authentifié, vous pouvez lier un pipeline de build TFS à votre pipeline de mise en production et choisir Build TFS externe dans le menu déroulant Type .

Les fonctionnalités suivantes sont disponibles lors de l’utilisation d’Azure Pipelines comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Azure Pipelines peut ne pas être en mesure de contacter un serveur TFS local au cas où il se trouve dans votre réseau d’entreprise. Dans ce cas, vous pouvez intégrer Azure Pipelines à TFS en configurant un agent local qui peut accéder au serveur TFS. Vous ne pourrez pas voir le nom de vos projets TFS ou pipelines de build lors de la liaison à une build, mais vous pouvez inclure ces variables dans les champs de texte d’URL. En outre, lorsque vous créez une mise en production, Azure Pipelines peut ne pas être en mesure d’interroger le serveur TFS pour les numéros de build. Au lieu de cela, entrez l’ID de build (et non le numéro de build) de la build souhaitée dans le champ approprié, ou sélectionnez la dernière build.

Sources d’artefacts - TeamCity

Pour utiliser TeamCity comme source d’artefact, vous devez d’abord installer l’extension TeamCity artifacts for Azure Pipelines à partir de Visual Studio Marketplace.

Une fois l’opération terminée, créez une connexion de service pour vous authentifier auprès de votre serveur TeamCity. Vous pouvez ensuite lier votre artefact de build à un pipeline de mise en production. La configuration de la build TeamCity doit être configurée avec une action pour publier des artefacts.

Les fonctionnalités suivantes sont disponibles lors de l’utilisation de TeamCity comme source d’artefact :

Fonctionnalité Description
Déclenchement automatique des mises en production De nouvelles versions peuvent être créées automatiquement lorsqu’un nouvel artefact de build est disponible (y compris les builds XAML). Pour plus d’informations, consultez Déclencheurs de mise en production.
Variables d’artefact Un certain nombre de variables d’artefact sont prises en charge pour les sources Azure Pipelines.
Éléments de travail et validations Vous pouvez lier des éléments de travail Azure Pipelines qui s’affichent dans les détails des versions. Les validations s’affichent lorsque vous utilisez des contrôles de code source Git ou TFVC.
Téléchargement d'artefacts Par défaut, les artefacts de build sont téléchargés sur l’agent exécutant le pipeline. Vous pouvez également configurer une étape dans votre étape pour ignorer le téléchargement de votre artefact.

Azure Pipelines peut ne pas être en mesure de contacter votre serveur TeamCity si, par exemple, il se trouve dans votre réseau d’entreprise. Dans ce cas, vous pouvez intégrer Azure Pipelines à TFS en configurant un agent local qui peut accéder au serveur TeamCity. Vous ne pourrez pas voir le nom de vos projets TeamCity lors de la liaison à une build, mais vous pouvez le saisir dans le champ de texte URL.

Alias de la source de l'artefact

Pour garantir l’unicité de chaque téléchargement d’artefact, chaque source d’artefact liée à un pipeline de mise en production est automatiquement fournie avec un emplacement de téléchargement spécifique appelé alias source. Cet emplacement est accessible à l’aide de la variable : $(System.DefaultWorkingDirectory)\[source alias]

L’utilisation d’un alias source garantit que le renommage d’une source d’artefact lié ne nécessite pas de modifier les propriétés de la tâche, car l’emplacement de téléchargement défini dans l’agent ne change pas.

Par défaut, l’alias source est le nom de la source de l’artefact précédé d’un trait de soulignement. Selon le type de la source de l’artefact, il s’agit du nom du pipeline de build, du nom du travail, du nom du projet ou du nom du référentiel. Vous pouvez modifier l’alias source à partir de l’onglet Artefacts de votre pipeline de mise en production.

Téléchargement d'artefacts

Lorsqu’un déploiement est terminé sur une étape, les artefacts versionnés de chacune des sources sont téléchargés vers l’agent de pipeline afin que les tâches exécutées dans cette phase puissent accéder à ces artefacts. Les artefacts téléchargés ne sont pas supprimés lorsqu’une mise en production est terminée. Toutefois, lorsque vous lancez la version suivante, les artefacts téléchargés sont supprimés et remplacés par le nouvel ensemble d’artefacts.

Un nouveau dossier unique dans l’agent est créé pour chaque pipeline de mise en production lorsqu’une mise en production est lancée, et les artefacts sont téléchargés dans le dossier suivant :$(System.DefaultWorkingDirectory).

Azure Pipelines n’effectue aucune optimisation pour éviter de télécharger les artefacts inchangés si la même version est redéployé. En outre, étant donné que le contenu téléchargé précédemment est toujours supprimé lorsque vous lancez une nouvelle mise en production, Azure Pipelines ne peut pas effectuer de téléchargements incrémentiels vers l’agent.

Vous pouvez toutefois configurer votre pipeline pour ignorer le téléchargement automatique d’un travail ou d’une étape spécifique si vous le souhaitez.