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.

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.

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.

Parties de l’exécution supprimées

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

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.

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.

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

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.

Articles connexes

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