Stratégies de rétention

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

Les stratégies de rétention contrôlent la durée d’exécution du pipeline, les versions classiques et les données de test conservées dans Azure DevOps. Ces paramètres vous aident à équilibrer l’utilisation du stockage, la conformité et la traçabilité en définissant quand vous devez supprimer des données plus anciennes et les données que vous devez conserver plus longtemps. Cet article explique les options de rétention disponibles et comment elles s'appliquent aux pipelines, livraisons, et tests.

Prérequis

Product Exigences
Azure DevOps - Organisation Azure DevOps.
- Un projet Azure DevOps.
Permissions - Par défaut, vous pouvez gérer les stratégies de rétention si vous êtes membre des groupes Contributeurs, Administrateurs de build, administrateurs de Project ou administrateurs de mise en production.
- Pour gérer les stratégies de rétention, vous avez besoin de l’un des abonnements suivants : Enterprise, Test Professional ou MSDN Platform.
- Vous pouvez également acheter un accès mensuel Azure Test Plans et attribuer le niveau d’accès Basic + Plans de test. Pour plus d’informations, consultez Test de l’accès par rôle d’utilisateur.

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.

Configurer les stratégies de rétention

Pour ouvrir les pages des paramètres de rétention dans votre projet et choisir la zone de stratégie que vous souhaitez gérer, procédez comme suit :

  1. Connectez-vous à votre projet Azure DevOps.

  2. Sélectionnez l’icône gear>Project settings.

  3. Sélectionnez l’une des options suivantes :

    • Sous Pipelines, sélectionnez Paramètres pour configurer la rétention pour les exécutions, les artefacts, les symboles, les pièces jointes et les exécutions de pull request.
    • Sous Pipelines, sélectionnez Rétention des mises en production pour configurer les paramètres de rétention des mises en production, notamment lorsque les mises en production sont supprimées ou définitivement détruites.
    • Sous Test, sélectionnez Rétention pour configurer la durée pendant laquelle les exécutions manuelles et automatisées sont conservées.

Pipeline exécute des stratégies de rétention

Dans la plupart des cas, vous n'avez pas besoin de garder les parties terminées indéfiniment. Les stratégies de rétention d’exécution vous permettent de définir la durée pendant laquelle les exécutions et les données associées sont conservées avant la suppression.

  1. Accédez à l’ongletgear iconParamètres de l’icône >des paramètres de votre projet.

  2. Dans la section Pipelines , sélectionnez Paramètres :

    • Définissez le nombre de jours pour conserver les artefacts, les symboles et les pièces jointes.
    • Fixe combien de jours il faut faire lescourses.
    • Définissez le nombre de jours pour conserver les exécutions des pull requests.
    • Définissez 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 précédemment. Vous ne pouvez plus configurer de stratégies de rétention par pipeline.

Le nombre d’exécutions récentes à conserver pour chaque paramètre de pipeline est interprété différemment en fonction du type de référentiel :

  • Azure Repos : Azure Pipelines conserve le nombre configuré d'exécutions les plus récentes pour la branche par défaut de pipeline et pour chaque branche protégée dans le référentiel. Une branche protégée est n’importe quelle branche avec des stratégies de branche configurées.

    Par exemple, considérez un référentiel avec deux branches : main et release. Si la branche par défaut du pipeline est main et release a une stratégie de branche, elle release est traitée comme une branche protégée. Si vous configurez la rétention pour conserver trois exécutions, Azure Pipelines conserve les trois dernières exécutions pour main, les trois dernières exécutions pour release et les trois dernières exécutions pour le pipeline dans l’ensemble (indépendamment de la branche).

    L’exemple suivant suppose que l’exécution la plus récente est affichée en premier. Il indique quelles exécutions sont conservées lorsque vous configurez la rétention pour conserver les trois dernières exécutions (en ignorant le paramètre basé sur les 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 Pas les 3 plus récentes pour main ou pour le pipeline
    Exécution 4 main Éléments non conservés Pas les 3 plus récentes pour main ou pour le pipeline
    Run 3 branch1 Éléments non conservés Pas les 3 plus récentes pour main ou 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 Pas les 3 plus récentes pour main ou pour le pipeline

    Le nombre de jours de conservation est calculé à partir de cette date lorsque l’exécution est terminée. Par exemple, il y a deux trajets sur une branche principale le 19 janvier. L’exécution terminée le plus tard est conservée.

  • Tous les autres référentiels Git : Azure Pipelines conserve le nombre configuré d’exécutions les plus récentes pour l'ensemble de la pipeline.

  • Team Foundation Version Control (TFVC) : Azure Pipelines conserve le nombre configuré de dernières exécutions pour l’ensemble du pipeline, quelle que soit la branche.

Quelles parties du processus sont supprimées ?

Lorsqu’une exécution est supprimée, les données suivantes sont supprimées :

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

La conservation des exécutions de pipeline ne régit pas les packages Universal Packages, NuGet, npm et autres packages.

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

Une exécution est supprimée si toutes les conditions suivantes sont remplies :

  • Il dépasse le nombre de jours configurés dans les paramètres de rétention.
  • Il ne s’agit pas de l’une des exécutions récentes configurées dans les paramètres de rétention.
  • Elle n’est pas marquée pour une conservation indéfinie.
  • Elle n’est pas conservée par une mise en production.

Les stratégies de rétention sont traitées une fois par jour. Le temps de traitement varie, car le travail est distribué tout au long de la journée pour l’équilibrage de charge. Vous ne pouvez pas modifier cette planification.

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

Les baux de rétention vous permettent d’étendre ou de contrôler la durée de vie des exécutions de pipeline au-delà des périodes de rétention configurées. Vous pouvez ajouter ou supprimer des baux pour un pipeline exécuté à l’aide de l’API Lease. Vous pouvez appeler cette API à partir d’un pipeline à l’aide d’un script et de variables prédéfinies pour runId et definitionId.

Vous pouvez définir un bail pour une durée spécifique. Par exemple, vous pouvez conserver une exécution qui se déploie sur un environnement de test pour une durée plus courte. Vous pouvez conserver plus longtemps une exécution déployée en production.

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

Vous pouvez conserver manuellement une exécution de pipeline à partir du menu Autres actions dans la page détails de l’exécution du pipeline .

Capture d’écran montrant comment conserver manuellement une exécution.

Supprimer une exécution

Vous pouvez supprimer des exécutions dans le menu Autres actions sur la page des détails de l’exécution du pipeline.

Capture d’écran montrant comment supprimer une exécution.

Note

Si des stratégies de conservation s’appliquent actuellement à l’exécution, vous devez les supprimer avant de pouvoir supprimer l’exécution. Pour obtenir des instructions, consultez les détails de l’exécution du pipeline : Supprimer une exécution.

Publie des politiques de rétention

Les stratégies de rétention des mises en production pour les pipelines de mise en production classiques déterminent la durée pendant laquelle une version et son exécution associée sont conservées. Avec ces stratégies, vous pouvez configurer les deux :

  • Nombre de jours pour conserver chaque version après sa dernière modification ou son déploiement.
  • Le nombre minimum de versions à conserver pour chaque pipeline.

Le minuteur de rétention se réinitialise à chaque modification ou déploiement d’une version à une étape. Le paramètre de mise en production minimale est prioritaire sur le paramètre basé sur les jours. Par exemple, si vous définissez la version minimale sur trois versions, les trois versions les plus récentes sont conservées, quel que soit le nombre de jours configuré. Vous pouvez toujours supprimer ces versions manuellement quand vous n’en avez plus besoin. Pour plus d’informations, consultez le FAQ plus loin dans cet article.

YAML et les pipelines de build utilisent la même politique de rétention de run. Vous pouvez afficher ces paramètres sous Project paramètres>Pipelines>Settings.

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

Dans Azure DevOps Services, vous pouvez afficher ces paramètres, mais vous ne pouvez pas les modifier au niveau du projet.

Vous pouvez consulter les paramètres de rétention globaux des versions à partir de la page de Version dans vos paramètres de Projet :

  • Stratégie de conservation maximale : définit la limite supérieure de durée pendant laquelle vous pouvez conserver les versions dans l’ensemble des pipelines de version. Les auteurs de pipelines ne peuvent pas configurer la rétention au-delà de cette limite.
  • Stratégie de rétention par défaut : définit les valeurs de rétention par défaut appliquées aux pipelines de mise en production. Les auteurs de pipelines peuvent remplacer ces valeurs par défaut.
  • Détruire définitivement les versions : contrôle la durée pendant laquelle les versions supprimées sont conservées avant la suppression définitive. Les pipelines de mise en production individuels ne peuvent pas remplacer cette stratégie.

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

Si vous utilisez Azure DevOps Server localement, vous pouvez configurer les valeurs par défaut et les maximums au niveau du projet pour la rétention des versions. Vous pouvez également définir lorsque les versions supprimées sont définitivement détruites. (Ils sont supprimés de l’onglet Supprimé dans l’Explorateur de builds.)

  • Stratégie de conservation maximale : définit la limite supérieure de durée pendant laquelle vous pouvez conserver les versions dans l’ensemble des pipelines de version. Les auteurs de pipelines ne peuvent pas configurer la rétention au-delà de cette limite.
  • Stratégie de rétention par défaut : définit les valeurs de rétention par défaut appliquées aux pipelines de mise en production. Les auteurs de pipelines peuvent remplacer ces valeurs par défaut.
  • Détruire définitivement les versions : contrôle la durée pendant laquelle les versions supprimées sont conservées avant la suppression définitive. Les pipelines de mise en production individuels ne peuvent pas remplacer cette stratégie.

Screenshot qui affiche les paramètres de stratégie de rétention dans Azure DevOps Server.

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

Si vous utilisez un serveur local, vous pouvez également configurer une conservation au niveau de la collection avec des règles personnalisées. Ces paramètres s’appliquent aux pipelines de build classiques et définissent les valeurs de rétention par défaut et maximale pour la collection.

Capture d’écran montrant comment configurer des politiques de rétention du niveau de la collection.

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

Si vous devez conserver la sortie de build plus longue que votre période de rétention configurée, copiez-la dans votre propre emplacement de stockage à l’aide de la tâche Copier des fichiers.

Utilisez copier des fichiers au lieu de publier des artefacts de build , car les données publiées en tant qu’artefacts de build sont toujours soumises au nettoyage de rétention.

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

Questions fréquentes (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. La stratégie de rétention du pipeline et les limites maximales définies par l’administrateur ne sont pas appliquées lorsque vous marquez une exécution ou une version individuelle à 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 versions classiques pour déployer en production, personnalisez la rétention sur le pipeline de versions. Définissez le nombre de jours pendant lesquels vous souhaitez conserver les versions déployées en production et spécifiez que les exécutions associées à ces versions sont conservées. Ce paramètre remplace la stratégie de conservation des exécutions.

Si vous utilisez des pipelines YAML multistages, vous pouvez configurer la rétention uniquement dans les paramètres du projet. Vous ne pouvez pas configurer la rétention par environnement de déploiement.

Je n’ai pas marqué les exécutions pour une conservation indéfinie, mais de nombreuses exécutions sont conservées. Comment éviter cela ?

Ce comportement peut se produire en raison de l’une des raisons suivantes :

  • Une personne de votre projet a marqué les exécutions pour une conservation indéfinie.
  • Une version consomme les exécutions, et cette version applique un verrou de conservation sur ces exécutions. Personnalisez la stratégie de conservation des versions comme expliqué précédemment.

Si les exécutions ne sont plus nécessaires ou si les versions qui les ont conservées sont déjà supprimées, vous pouvez supprimer manuellement les exécutions.

Comment le paramètre fonctionne-t-il pour les versions minimales à conserver ?

La valeur du nombre minimum de versions à conserver est définie au niveau de l'étape. Azure DevOps conserve toujours ce nombre de versions les plus récentes déployées pour l'étape, même si elles sont en dehors de la période de rétention. Une version est prise en compte dans ce minimum uniquement lorsque le déploiement vers cette étape commence. Les déploiements réussis et ayant échoué sont comptabilisés. Les mises en production en attente d’approbation ne sont pas comptabilisées.

Comment la période de rétention est-elle déterminée lorsque la mise en production est déployée sur plusieurs étapes qui ont des périodes de rétention différentes ?

La période de rétention finale est déterminée par les jours à conserver dans toutes les phases où le déploiement a lieu, en utilisant la valeur maximale parmi ces phases. Les versions minimales à conserver sont spécifiques à l’étape et ne changent pas selon qu’une version a été déployée sur une ou plusieurs étapes. La conservation des artefacts associés ne s’applique que lorsqu’une version est déployée à un stade où cette option est activée.

J'ai supprimé une étape pour laquelle je dispose de versions anciennes. Quelle rétention est prise en compte pour ce cas ?

Une fois qu’une étape est supprimée, ses paramètres de rétention au niveau de l’étape ne s’appliquent plus. Dans ce cas, Azure DevOps utilise les paramètres de rétention par défaut au niveau du projet.

Mon organisation exige de conserver les versions et les mises en production plus longtemps que ce qui est autorisé dans les paramètres. Comment puis-je demander une conservation plus longue ?

Pour conserver une exécution ou une publication plus longtemps que les limites de rétention configurées, marquez-la comme conservée indéfiniment. Il n’existe aucun paramètre pour configurer manuellement une période de rétention plus longue. Pour obtenir de l’aide, contactez Azure DevOps support technique.

Vous pouvez également utiliser des API REST pour télécharger les informations d’exécution et les artefacts, puis les stocker dans votre propre compte de stockage ou dépôt d’artefacts.

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

Si vous pensez que les exécutions ont été perdues en raison d’un bogue de service, créez immédiatement un ticket de support. Si une définition de build a été supprimée manuellement plus d’une semaine plus tôt, vous ne pouvez pas la récupérer. Si les exécutions ont été supprimées comme prévu par la stratégie de rétention, vous ne pouvez pas les récupérer.

Comment utiliser la fonctionnalité Build.Cleanup des agents ?

Définir la Build.Cleanup capacité sur les agents redirige les tâches de nettoyage uniquement vers ces agents, ce qui permet aux autres agents de rester disponibles pour le travail régulier sur les pipelines. Lorsqu’une exécution de pipeline est supprimée, les artefacts stockés en dehors de Azure DevOps sont nettoyés par le biais d’un travail d’agent. Si les travaux de nettoyage saturent votre pool, désignez un sous-ensemble d’agents comme agents de nettoyage. Lorsque des agents ont Build.Cleanup défini, seuls ces agents exécutent des tâches de nettoyage. Pour activer ce paramètre, accédez à l’agent>capabilités et réglez Build.Cleanup sur 1.

Que se passe-t-il pour les artefacts de partage de fichiers lorsque la compilation 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 en fonction des critères suivants :

  • Existe-t-il un agent disponible avec la fonctionnalité Build.Cleanup ?
  • 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 dans une phase de mise en production sont conservés en fonction de la stratégie de rétention des tests, et non de la stratégie de rétention des versions. Si vous avez besoin de résultats de test conservés tant que la version est mise en production, définissez la rétention de l’exécution de test automatisée dans les paramètres Project sur Never delete. Ce paramètre garantit que les résultats des tests sont supprimés uniquement lorsque la version 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 ?

Si les étiquettes ou les balises doivent être conservées après la suppression d’une version, appliquez-les dans une tâche de pipeline, ajoutez-les manuellement en dehors du pipeline ou conservez la version indéfiniment.

Important

Toutes les étiquettes ou étiquettes de contrôle de version appliquées pendant un pipeline de build qui ne sont pas créées automatiquement par la tâche Sources sont conservées, même si la build est supprimée. Les étiquettes ou balises créées automatiquement par la tâche Sources pendant une build sont traitées comme des artefacts de build et sont supprimées avec la build.

Qu'advient-il des pipelines qui sont consommés dans d’autres pipelines ?

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

Qu'advient-il des 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 en plusieurs étapes pour représenter votre version et consommer un autre pipeline YAML dans celui-ci en tant que ressource. Le pipeline de ressources est conservé automatiquement aussi longtemps que le pipeline de mise en production.

Contenu connexe

  • Last updated on