Définir des stratégies de rétention pour les builds, les mises en production et les tests

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

Les Stratégies de rétention vous permettent de définir la durée de conservation des exécutions, des mises en production et des tests stockés dans le système. Pour économiser de l’espace de stockage, vous devez supprimer les exécutions, les tests et les mises en production plus anciennes.

Les stratégies de rétention suivantes sont disponibles dans Azure DevOps dans les paramètres de votre projet :

  1. Pipeline : définissez la durée de conservation des artefacts, des symboles, des pièces jointes, des exécutions et des exécutions de demandes de tirage.
  2. Mise en production (classique) : définissez si les builds doivent être enregistrées et afficher les paramètres de rétention par défaut et maximum.
  3. Test : définissez la durée de conservation des séries de tests manuels et automatisés, les résultats et les pièces jointes.

Project settings retention policies

Remarque

Si vous utilisez un serveur local, vous pouvez également spécifier des stratégies de rétention par défaut pour un projet et déterminer quand les mises en production sont détruites définitivement. Découvrez plus en détail la rétention des mises en production ultérieurement dans cet article.

Prérequis

Par défaut, des membres des groupes Contributeurs, Administrateurs de build, Administrateurs de projet et Administrateurs de mise en production peuvent gérer des stratégies de rétention.

Pour gérer des stratégies de rétention, vous devez disposer de l’un des abonnements suivants :

Vous pouvez également acheter un accès mensuel à Azure Test Plans et attribuer le niveau d’accès De base + Test Plans. Consultez Test d’accès par rôle d’utilisateur.

Configurer les stratégies de rétention

  1. Connectez-vous à votre projet.

  2. Accédez à l’onglet gear iconParamètres des paramètres de votre projet.

  3. Sélectionnez Rétention des mises en production sous Pipelines ou Rétention sous Test.

    • Sélectionnez Rétention des mises en production pour configurer vos stratégies de rétention des mises en production et déterminer quand supprimer ou détruire les mises en production définitivement.
    • Sélectionnez Rétention pour définir la durée de conservation des séries de tests manuels et automatisés.

    Screenshot of retention settings in Project settings for DevOps 2019.

Configurer les stratégies de rétention

  1. Connectez-vous à votre projet.

  2. Accédez à l’onglet gear iconParamètres des paramètres de votre projet.

  3. Sélectionnez Paramètres ou Rétention des mises en production sous Pipelines ou Rétention sous Test.

    • Sélectionnez Paramètres pour configurer des stratégies de rétention pour les exécutions, les artefacts, les symboles, les pièces jointes et les exécutions de demandes de tirage.
    • Sélectionnez Rétention des mises en production pour configurer vos stratégies de rétention des mises en production et déterminer quand supprimer ou détruire les mises en production définitivement.
    • Sélectionnez Rétention pour définir la durée de conservation des séries de tests manuels et automatisés.

    Screenshot of retention settings in Project settings.

Important

Azure Pipelines ne prend plus en charge les stratégies de rétention par pipeline. Nous vous recommandons d’utiliser des règles de rétention au niveau du projet.

Définir des stratégies de rétention des exécutions

Dans la plupart des cas, vous n’avez pas besoin de conserver les exécutions terminées plus longtemps qu’un nombre défini de jours. Les stratégies de rétention permettent de déterminer le nombre de jours pendant lesquels vous souhaitez conserver chaque exécution avant de la supprimer.

En plus du nombre de jours de conservation des exécutions, vous pouvez également déterminer le nombre minimal d’exécutions à conserver pour chaque pipeline.

  1. Accédez à l’onglet gear iconParamètres des paramètres de votre projet.

  2. Sélectionnez Paramètres dans la section Pipelines.

    • Définissez le nombre de jours de conservation des artefacts, symboles et pièces jointes.
    • Définir le nombre de jours de conservation des exécutions
    • Définir le nombre de jours de conservation des exécutions de demandes de tirage
    • Définir le nombre d’exécutions récentes à conserver pour chaque pipeline

Avertissement

Azure DevOps ne prend plus en charge les règles de rétention par pipeline. La seule façon de configurer des stratégies de rétention pour les pipelines YAML et classiques consiste à utiliser les paramètres de projet décrits ci-dessus. Vous ne pouvez plus configurer de stratégies de rétention par pipeline.

Le paramètre définissant le nombre d’exécutions récentes à conserver pour chaque pipeline nécessite un peu plus d’explication. L’interprétation de ce paramètre varie en fonction du type de référentiel que vous générez dans votre pipeline.

  • Azure Repos : Azure Pipelines conserve le nombre configuré d’exécutions les plus récentes pour la branche par défaut du pipeline et pour chaque branche protégée du référentiel. Une branche sur laquelle des stratégies de branche sont configurées est considérée comme une branche protégée.

    Prenons l’exemple d’un référentiel comportant deux branches : main et release. Imaginez que pipeline's default branch est la branche main et que la branche release dispose d’une stratégie de branche qui la définit comme une branche protégée. Dans ce cas, si vous avez configuré la stratégie pour conserver trois exécutions, les trois dernières exécutions de main et les trois dernières exécutions de la branche release sont conservées. En outre, les trois dernières exécutions de ce pipeline (indépendamment de la branche) sont également conservées.

    Pour clarifier cette logique plus en détails, imaginons la liste des exécutions de ce pipeline suivante, avec l’exécution la plus récente en haut. Le tableau indique les exécutions qui sont conservées si votre configuration indique de conserver les trois dernières exécutions (en ignorant l’effet du paramètre de nombre de jours) :

    Exécution no Branche Conservé/non conservé Pourquoi ?
    Exécution 10 main Retenu Trois dernières pour la branche primaire et trois dernières pour le pipeline
    Exécution 9 branch1 Retenu Trois dernières pour le pipeline
    Exécution 8 branch2 Retenu Trois dernières pour le pipeline
    Exécution 7 main Retenu Trois dernières pour la branche primaire
    Exécution 6 main Retenu Trois dernières pour la branche primaire
    Exécution 5 main Éléments non conservés Ni les trois dernières pour la branche primaire ni pour le pipeline
    Exécution 4 main Éléments non conservés Ni les trois dernières pour la branche primaire ni pour le pipeline
    Exécution 3 branch1 Éléments non conservés Ni les trois dernières pour la branche primaire ni pour le pipeline
    Exécution 2 release Retenu Trois dernières pour la mise en production
    Exécution 1 main Éléments non conservés Ni les trois dernières pour la branche primaire ni pour le pipeline
  • Tous les autres référentiels Git : Azure Pipelines conserve le nombre configuré d’exécutions les plus récentes pour l’ensemble du pipeline.

  • TFVC : Azure Pipelines conserve le nombre configuré d’exécutions les plus récentes pour l’ensemble du pipeline, quelle que soit la branche.

Parties de l’exécution supprimées

Quand les stratégies de rétention marquent une build à des fins de suppression, vous pouvez déterminer les informations relatives à la build à supprimer :

  • Enregistrement de build : vous pouvez choisir de supprimer l’intégralité de l’enregistrement de build ou de conserver des informations de base sur la build même après sa suppression.
  • Étiquette source : si vous étiquetez des sources dans le cadre de la build, vous pouvez choisir de supprimer la balise (pour Git) ou l’étiquette (pour TFVC) créée par une build.
  • Résultats des tests automatisés : vous pouvez choisir de supprimer les résultats des tests automatisés associés à la build (par exemple les résultats publiés par la tâche de build Publier les résultats des tests).

Les informations suivantes sont supprimées quand une build est supprimée :

  • Journaux d’activité
  • Artefacts publiés
  • Symboles publiés

Les informations suivantes sont supprimées quand une exécution est supprimée :

  • Journaux d’activité
  • Tous les artefacts de pipeline et de build
  • Tous les symboles
  • Composants binaires
  • Résultats des tests
  • Métadonnées de l’exécution
  • Étiquettes sources (TFVC) ou balises (Git)

Les packages universels, NuGet, npm et autres packages ne sont pas liés à la rétention des pipelines.

Quand les exécutions sont-elles supprimées ?

Vos stratégies de rétention sont traitées une fois par jour. L’heure de traitement des stratégies varie, car nous répartissons le travail tout au long de la journée à des fins d’équilibrage de charge. Il n’est pas possible de modifier ce processus.

Une exécution est supprimée si toutes les conditions suivantes ont la valeur true :

  • Le nombre de jours configuré dans les paramètres de rétention est dépassé
  • Il ne s’agit pas d’une exécution récente conformément aux paramètres de rétention configurés
  • Elle n’est pas marquée pour être conservé indéfiniment
  • Elle n’est pas conservée par une mise en production

Vos stratégies de rétention s’exécutent tous les jours à 3 h 00 UTC. Il n’est pas possible de modifier l’heure d’exécution des stratégies.

Définir automatiquement le bail de rétention sur les exécutions de pipeline

Les baux de rétention permettent de gérer la durée de vie des exécutions de pipeline au-delà des périodes de rétention configurées. Appelez l’API Lease pour ajouter ou supprimer les baux de rétention sur un pipeline exécuté. Vous pouvez appeler cette API dans le pipeline à l’aide d’un script et de variables prédéfinies pour runId et definitionId.

Un bail de rétention peut être ajouté sur une exécution de pipeline pour une période spécifique. Une exécution de pipeline déployée dans un environnement de test peut être conservée pendant une durée plus courte, tandis qu’une exécution déployée dans un environnement de production peut être conservée plus longtemps.

Définir manuellement le bail de rétention sur les exécutions de pipeline

Vous pouvez définir manuellement une exécution de pipeline à conserver à l’aide du menu Autres actions sur la page Détails de l’exécution de pipeline.

manually retain a run

Supprimer une exécution

Vous pouvez supprimer des exécutions via le menu Autres actions de la page Détails de l’exécution de pipeline.

Notes

Si des stratégies de rétention s’appliquent actuellement à l’exécution, elles doivent être supprimées pour pouvoir supprimer l’exécution. Pour obtenir des instructions, consultez Informations sur une exécution de pipeline – supprimer une exécution.

delete a run

Définir des stratégies de rétention des mise en productions

Les stratégies de rétention des mises en production pour un pipeline de mise en production déterminent la durée pendant laquelle la mise en production et l’exécution liée sont conservées. À l’aide de ces stratégies, vous pouvez déterminer le nombre de jours pendant lesquels vous souhaitez conserver chaque mise en production après la dernière modification ou le déploiement, ainsi que le nombre minimal de mises en production à conserver pour chaque pipeline.

Le minuteur de rétention d’une mise en production est réinitialisé chaque fois que celle-ci est modifiée ou déployée vers une phase. Le nombre minimal de mises en production à conserver est prioritaire par rapport au nombre de jours. Par exemple, si vous définissez la conservation de trois mises en production minimum, les trois dernières sont conservées indéfiniment, quel que soit le nombre de jours spécifié. Toutefois, vous pouvez supprimer ces versions manuellement quand vous n’en avez plus besoin. Pour plus d’informations sur le fonctionnement de la rétention des mises en production, consultez les questions fréquentes (FAQ) ci-dessous.

En tant qu’auteur d’un pipeline de mise en production, vous pouvez personnaliser les stratégies de rétention pour les mises en production de votre pipeline sous l’onglet Rétention.

La stratégie de rétention pour YAML et les pipelines de build est identique. Vous pouvez consulter les paramètres de rétention de votre pipeline dans Paramètres du projet pour les Pipelines dans la section Paramètres.

Vous pouvez également découvrir comment personnaliser ces stratégies phase par phase ultérieurement dans cet article.

Stratégies globales de rétention des mises en production

Si vous utilisez Team Foundation Server ou Azure DevOps Server localement, vous pouvez spécifier les valeurs par défaut et les valeurs maximales de la stratégie de rétention des mises en production d’un projet. Vous pouvez également spécifier quand les mises en production doivent être détruites définitivement (supprimées dans l’onglet Supprimé dans l’Explorateur de builds).

On premises release retention settings

Si vous utilisez Azure DevOps Services, vous pouvez afficher mais pas modifier ces paramètres pour votre projet.

Les paramètres des stratégies globales de rétention des mises en production peuvent être consultés dans les paramètres de rétention des mises en production de votre projet :

  • Azure DevOps Services : https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
  • Localement : https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub

La stratégie de rétention maximale définit la durée maximale de rétention des mises en production pour l’ensemble des pipelines de mise en production. Les auteurs de pipelines de mise en production ne peuvent pas configurer les paramètres de leurs définitions au-delà des valeurs spécifiées ici.

La stratégie de rétention par défaut définit les valeurs de rétention par défaut pour l’ensemble des pipelines de mise en production. Les auteurs des pipelines de build peuvent écraser ces valeurs.

La stratégie de destruction permet de conserver les mises en production pendant une période donnée après leur suppression. Il n’est pas possible d’écraser cette stratégie dans les pipelines de mise en production individuels.

Définir des stratégies de rétention au niveau de la collection

Pour les serveurs locaux, vous pouvez également définir les stratégies de rétention au niveau de la collection grâce à des règles de rétention personnalisées. Ces stratégies de rétention s’appliquent aux pipelines de build classiques. La page à l’emplacement https://{your_server}/{collection_name}/_settings/buildqueue régit vos valeurs maximales et les valeurs par défaut.

A screenshot showing how to configure collection level retention policies.

Remarque

Dans TFS, la gestion de la rétention des mises en production se limite à spécifier le nombre de jours. Elle est disponible uniquement dans TFS 2015.3 et versions ultérieures.

Stratégies de rétention spécifiques à la phase

Vous souhaitez peut-être conserver des mises en production supplémentaires qui ont été déployées lors de phases spécifiques. Votre équipe souhaite par exemple peut-être conserver les éléments suivants :

  • Mises en production déployées en production pendant 60 jours, avec les trois dernières versions déployées minimum.
  • Mises en production déployées en préproduction pendant 15 jours, avec une dernière version déployée minimum.
  • Mises en production déployées vers la phase AQ pendant 30 jours, avec les deux dernières versions déployées minimum.
  • Mises en production déployées vers la phase de développement pendant 10 jours, une dernière version déployée minimum.

L’exemple de stratégie de rétention suivant d’un pipeline de mise en production répond aux exigences ci-dessus :

Configuring the release retention setting for a release pipeline

Dans cet exemple, si une version déployée vers la phase de développement n’est pas promue vers AQ pendant 10 jours, elle est potentiellement candidate à la suppression. Toutefois, si cette mise en production est déployée vers la phase AQ huit jours après avoir été déployée vers la phase développement, son minuteur de rétention est réinitialisé et elle est conservée dans le système pendant 30 jours supplémentaires.

Quand vous spécifiez des stratégies personnalisées par pipeline, vous ne pouvez pas dépasser les limites maximales définies par l’administrateur.

Interaction entre les stratégies de rétention des builds et mises en production

La build liée à une mise en production a sa propre stratégie de rétention, qui peut être plus courte que celle de la mise en production. Si vous souhaitez conserver la build pendant la même période que la mise en production, cochez la case Conserver les artefacts associés des phases appropriées. Cette action écrase la stratégie de rétention de la build et permet de s’assurer que les artefacts sont disponibles si vous devez redéployer cette mise en production.

Quand vous supprimez un pipeline de mise en production ou une mise en production, ou lorsque la stratégie de rétention supprime automatiquement une mise en production, la stratégie de rétention de la build associée détermine à quel moment cette build est supprimée.

Notes

Dans TFS, l’interaction entre la rétention des builds et des mises en production est disponible dans TFS 2017 et versions ultérieures.

Définir des stratégies de rétention des tests

Vous pouvez définir des stratégies pour les séries de tests manuels et automatisés.

Stratégies de rétention des séries de tests manuels

Pour supprimer les résultats des tests manuels au bout d’un nombre spécifique de jours, définissez la limite de rétention au niveau du projet. Azure DevOps conserve les résultats des tests manuels liés aux builds, même après la suppression de ces builds. De cette façon, les stratégies de build ne suppriment pas vos résultats de test avant que vous puissiez analyser les données.

  1. Connectez-vous à Azure DevOps. Vous devez disposer au minimum des autorisations d’administrateur du projet.

  2. Accédez à votre projet, puis sélectionnez gear icon Paramètres du projet en bas de la page.

configure project settings

  1. Dans la page Rétention, sous la section Test, sélectionnez une limite de durée pour la conservation des données des tests manuels.

manual tests retention policies

Stratégies de rétention des séries de tests automatisés

Azure DevOps conserve par défaut les résultats des tests automatisés liés aux builds uniquement tant que vous conservez ces builds. Pour conserver les résultats des tests après avoir supprimé vos builds, modifiez la stratégie de rétention de build. Si vous utilisez Git pour la gestion de version, vous pouvez spécifier la durée de conservation des résultats des tests automatisés en fonction de la branche.

  1. Connectez-vous à Azure DevOps. Pour modifier les pipelines de build, vous avez besoin des autorisations au niveau de la build au minimum.

  2. Accédez à votre projet, puis sélectionnez gear icon Paramètres du projet en bas de la page.

manage project settings

  1. Sélectionnez gear icon Paramètres sous Pipelines et modifiez vos stratégies de rétention.

edit project settings

Autres résultats des tests automatisés

Pour nettoyer les résultats des tests automatisés issus de builds supprimées ou les résultats de tests qui ne sont pas liés aux builds (par exemple les résultats publiés à partir de systèmes de test externes), définissez les limites de rétention au niveau du projet, comme expliqué dans la section Stratégies de rétention des séries de tests manuels

Définir des stratégies de rétention d’artefacts

Vous pouvez définir des stratégies de rétention d’artefacts pour les exécutions de pipeline dans les paramètres du pipeline.

  1. Connectez-vous à votre projet, pour Azure DevOps Services, le chemin d’URL est https://dev.azure.com/{yourorganization}/{yourproject}.

  2. Accédez à l’onglet gear iconParamètres des paramètres de votre projet.

  3. Sélectionnez Paramètres dans Pipelines.

  4. Modifiez Nombre de jours de conservation des artefacts, des symboles et des pièces jointes.

Utiliser la tâche Copier des fichiers pour enregistrer des données plus longtemps

La tâche Copier des fichiers permet d’enregistrer vos données de build et d’artefact plus longtemps que la durée définie dans les stratégies de rétention. Il est préférable d’utiliser la tâche Copier des fichiers plutôt que la tâche Publier les artefacts de build, car les données enregistrées via la tâche Publier les artefacts de build sont régulièrement nettoyées et supprimées.

- task: CopyFiles@2
  displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '_buildOutput/**'
    TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'

Vous pouvez également personnaliser ces stratégies branche par branche si vous effectuez une génération à partir de référentiels Git.

Stratégie globale de rétention de build

Vous pouvez spécifier les valeurs par défaut et les valeurs maximales de stratégie de rétention de build d’une collection de projets. Vous pouvez également spécifier quand les builds doivent être détruites définitivement (supprimées dans l’onglet Supprimé dans l’Explorateur de builds).

  • TFS 2018 : https://{your_server}/tfs/DefaultCollection/_admin/_buildQueue

La stratégie de rétention maximale définit la durée maximale de rétention des exécutions pour l’ensemble des pipelines de build. Les auteurs des pipelines de build ne peuvent pas configurer les paramètres de leurs définitions au-delà des valeurs spécifiées ici.

La stratégie de rétention par défaut définit les valeurs de rétention par défaut pour l’ensemble des pipelines de build. Les auteurs des pipelines de build peuvent écraser ces valeurs.

L’option Détruire définitivement les mises en production permet de conserver les exécutions pendant une période donnée après leur suppression. Il n’est pas possible d’écraser cette stratégie dans les pipelines de build individuels.

Référentiels Git

Si le type de référentiel est l’un des suivants, vous pouvez définir plusieurs stratégies de rétention comprenant des filtres de branche :

  • Azure Repos Git ou TFS Git.
  • GitHub.
  • Autre/Git externe.

Votre équipe souhaite par exemple peut-être conserver les éléments suivants :

  • Les builds de la branche utilisateur pendant cinq jours, avec un minimum d’une seule build réussie ou partiellement réussie pour chaque branche.
  • Les builds de la branche primaire et de la branche de fonctionnalité pendant 10 jours, avec au moins trois builds réussies ou partiellement réussies pour chacune de ces branches. Vous excluez une branche de fonctionnalité spéciale que vous souhaitez conserver plus longtemps.
  • Les builds de la branche de fonctionnalité spéciale et de toutes les autres branches pendant 15 jours, avec au minimum une build réussie ou partiellement réussie pour chaque branche.

L’exemple de stratégie de rétention suivant d’un pipeline de build répond aux exigences ci-dessus :

define git retention policies

Quand vous spécifiez des stratégies personnalisées pour chaque pipeline, vous ne pouvez pas dépasser les limites maximales définies par l’administrateur.

Nettoyer les builds de demande de tirage (pull request)

Si vous protégez vos branches Git avec des builds de demande de tirage, vous pouvez utiliser des stratégies de rétention pour supprimer automatiquement les builds terminées. Pour cela, ajoutez une stratégie qui conserve au minimum 0 build avec le filtre de branche suivant :

  refs/pull/*

retention policies for PR builds

Référentiels TFVC et Subversion

Pour les types de référentiels TFVC et Subversion, vous pouvez modifier une stratégie unique en définissant les options comme indiqué ci-dessus.

Ordre des stratégies

Quand le système supprime définitivement les anciennes builds, il évalue chaque build par rapport aux stratégies dans l’ordre spécifié. Vous pouvez glisser-déplacer une stratégie vers le haut ou vers le bas dans la liste pour modifier cet ordre.

La stratégie « Toutes les branches » est ajoutée automatiquement en tant que dernière stratégie dans l’ordre d’évaluation pour appliquer les limites maximales à toutes les autres branches.

define git retention policy max shown in pipeline

FAQ

Si je marque une exécution ou une mise en production pour la conserver indéfiniment, la stratégie de rétention s’applique-t-elle toujours ?

Non. Ni la stratégie de rétention du pipeline ni les limites maximales définies par l’administrateur ne s’appliquent quand vous marquez une exécution ou une mise en production individuelle pour les conserver indéfiniment. Ces éléments sont conservés jusqu’à ce que vous arrêtiez de les conserver indéfiniment.

Comment spécifier que les exécutions déployées en production doivent être conservées plus longtemps ?

Si vous utilisez des mises en production classiques pour le déploiement en production, personnalisez la stratégie de rétention sur le pipeline de mise en production. Spécifiez le nombre de jours pendant lesquels les mises en production déployées en production doivent être conservées. En outre, indiquez que les exécutions associées à cette mise en production doivent être conservées. Cette opération remplace la stratégie de rétention des exécutions.

Si vous utilisez des pipelines YAML multiphases pour effectuer le déploiement en production, vous pouvez configurer uniquement la stratégie de rétention dans les paramètres du projet. Vous ne pouvez pas personnaliser la rétention en fonction de l’environnement de déploiement de la build.

Je n’ai pas marqué les exécutions pour qu’elles soient conservées indéfiniment. Toutefois, je vois qu’un grand nombre d’exécutions sont conservées. Comment éviter ce comportement ?

Plusieurs raisons sont possibles :

  • Les exécutions sont marquées par un utilisateur de votre projet pour être conservées indéfiniment.
  • Les exécutions sont consommées par une mise en production qui contient un verrou de rétention pour ces exécutions. Personnalisez la stratégie de rétention des mises en production comme expliqué ci-dessus.

Si vous pensez que les exécutions ne sont plus nécessaires ou si les mises en production ont déjà été supprimées, vous pouvez supprimer les exécutions manuellement.

Comment fonctionne le paramètre « Nombre minimal de mises en production à conserver » ?

Le nombre minimal de mises en production à conserver est défini au niveau de la phase. Cela indique qu’Azure DevOps conserve toujours le nombre donné des dernières mises en production déployées d’une phase, même si les mises en production ne font pas partie de la période de rétention. Une mise en production est considérée comme faisant partie des mises en production minimales à conserver d’une phase uniquement une fois que le déploiement a démarré à cette phase. Les déploiements réussis et ceux ayant échoué sont pris en compte. Les mises en production en attente d’approbation ne sont pas prises en compte.

Comment la période de rétention est-elle déterminée quand la mise en production est déployée sur des phases multiples présentant une période de rétention différente ?

La période de rétention finale est déterminée en prenant en compte les jours de rétention des paramètres de toutes les phases sur lesquelles la mise en production est déployée et en choisissant la valeur maximale. Le nombre minimal de mises en production à conserver est régi au niveau de la phase et il ne varie pas en fonction du fait que la mise en production soit déployée sur des phases multiples ou non. La conservation des artefacts associés s’applique quand la mise en production est déployée sur une phase avec le paramètre défini sur true.

J’ai supprimé une phase pour laquelle je dispose de mises en production anciennes. Quelle est la rétention prise en compte dans ce cas ?

Comme la phase est supprimée, les paramètres de rétention au niveau de la phase ne sont désormais pas applicables. Dans ce cas, Azure DevOps repasse à la rétention par défaut au niveau du projet.

Mon organisation exige de conserver les builds et les mises en production plus longtemps que la durée autorisée dans les paramètres. Comment puis-je demander une conservation plus longue ?

La seule manière de conserver une exécution ou une mise en production pendant plus longtemps que la durée autorisée via les paramètres de rétention consiste à la marquer manuellement en vue de la conserver indéfiniment. Il n’existe aucun moyen de configurer manuellement un paramètre de conservation plus longue. Veuillez contacter le Azure DevOps Support pour obtenir de l'aide.

Vous pouvez également envisager d’utiliser les API REST afin de télécharger des informations et des artefacts sur les exécutions et de les charger dans votre propre stockage ou référentiel d’artefacts.

J’ai perdu des exécutions. Existe-t-il un moyen de les récupérer ?

Si vous pensez avoir perdu les exécutions en raison d’un bogue du service, créez un ticket de support immédiatement pour récupérer les informations perdues. Si une définition de build a été supprimée manuellement il y a plus d’une semaine, il n’est pas possible de la récupérer. Si les exécutions ont été supprimées comme prévu en raison d’une stratégie de rétention, il n’est pas possible de récupérer les exécutions perdues.

Comment utiliser la capacité Build.Cleanup des agents ?

Si vous définissez une capacité Build.Cleanup sur les agents, les travaux de nettoyage du pool sont dirigés uniquement vers ces agents. Les autres agents peuvent ainsi effectuer les travaux courants. Quand une exécution de pipeline est supprimée, les artefacts stockés en dehors d’Azure DevOps sont nettoyés via une exécution de travail sur les agents. Quand le pool d’agents est saturé en raison d’un grand nombre de travaux de nettoyage, un problème peut survenir. La solution consiste à désigner un sous-ensemble d’agents dans le pool qui sont les agents de nettoyage. Si Build.Cleanup est défini sur des agents, seuls ces agents exécutent les travaux de nettoyage. Les autres agents peuvent ainsi continuer à exécuter les travaux de pipeline. La fonctionnalité de nettoyage peut être activée en accédant à Agent>Capacités et en définissant Build.Cleanup sur la valeur égale à 1.

Qu’arrive-t-il aux artefacts de partage de fichiers quand la build est supprimée ?

Quand une build comprenant des artefacts de partage de fichiers est supprimée, une nouvelle tâche de build est mise en file d’attente sur un agent de build pour nettoyer ces fichiers. Un agent est choisi pour effectuer cette tâche selon les critères suivants : existe-t-il un agent avec la capacité Build.Cleanup disponible ? L’agent qui a exécuté la build est-il disponible ? Un agent du même pool est-il disponible ? Un agent d’un pool similaire est-il disponible ? Un agent est-il disponible ?

Les résultats des tests automatisés publiés dans le cadre d’une version sont-ils conservés jusqu’à ce que la version soit supprimée ?

Les résultats des tests publiés au sein d’une phase d’une mise en production sont conservés comme spécifié par la stratégie de rétention configurée pour les résultats des tests. Les résultats des tests ne sont pas conservés tant que la mise en production n’est pas conservée. Si vous avez besoin des résultats du test aussi longtemps que de la mise en production, définissez les paramètres de rétention pour les séries de tests automatisés dans les paramètres du projet sur Ne jamais supprimer. Cela permet de s’assurer que les résultats des tests sont supprimés uniquement quand la mise en production est supprimée.

Les résultats des tests manuels sont-ils supprimés ?

Non. Les résultats des tests manuels ne sont pas supprimés.

Comment faire pour conserver mes étiquettes ou balises de contrôle de version ?

Attention

Toutes les étiquettes ou balises de contrôle de version appliquées au cours d’un pipeline de build qui ne sont pas créées automatiquement à partir de la tâche Sources seront conservées, même en cas de suppression de la build. Toutefois, toutes les étiquettes ou balises de contrôle de version créées automatiquement à partir de la tâche Sources pendant une build sont considérées comme faisant partie des artefacts de build et seront supprimées lorsque la build est supprimée.

Si les étiquettes ou balises de contrôle de version doivent être conservées, même lorsque la build est supprimée, elles doivent être appliquées dans le cadre d’une tâche dans le pipeline, étiquetées manuellement en dehors du pipeline, ou la build doit être conservée indéfiniment.

Que se passe-t-il pour les pipelines qui sont consommés dans d’autres pipelines ?

Les mises en production classiques conservent automatiquement les pipelines qu’elles consomment.

Que se passe-t-il pour les pipelines qui sont consommés dans d’autres pipelines ?

Les mises en production classiques conservent automatiquement les pipelines qu’elles consomment. Si vous utilisez YAML, vous pouvez également créer un pipeline YAML à phases multiples pour représenter votre mise en production et consommer un autre pipeline YAML en tant que ressource. Le pipeline de ressources est conservé automatiquement aussi longtemps que le pipeline de mise en production.