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

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.

Notes

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 :

• Entreprise
• Test Professional
• Plateformes MSDN

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 Paramè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.

   

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.

1. Accédez à l’onglet Paramè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

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

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.

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.

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.

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).

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.

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.

YAML

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

Classique

1. Ajoutez la tâche Copier des fichiers à votre pipeline.

2. Configurez la tâche Copier des fichiers.

Forum aux questions

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.

Articles connexes

• Contrôler la durée de conservation des résultats des tests
• Supprimer les artefacts de test