Bewaarbeleid instellen voor builds, releases en tests

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

Met bewaarbeleid kunt u instellen hoe lang uitvoeringen, releases en tests in het systeem moeten worden bewaard. Als u opslagruimte wilt besparen, wilt u oudere uitvoeringen, tests en releases verwijderen.

De volgende bewaarbeleidsregels zijn beschikbaar in Azure DevOps in uw Project-instellingen:

1. Pijplijn : stel in hoe lang artefacten, symbolen, bijlagen, uitvoeringen en pull-aanvragen moeten worden bewaard.
2. Release (klassiek): stel in of builds moeten worden opgeslagen en of de standaard- en maximale bewaarinstellingen moeten worden weergegeven.
3. Test - Stel in hoe lang geautomatiseerde en handmatige testuitvoeringen, resultaten en bijlagen moeten worden bewaard.

Notitie

Als u een on-premises server gebruikt, kunt u ook de standaardinstellingen voor bewaarbeleid voor een project opgeven en wanneer releases permanent worden vernietigd. Verderop in dit artikel vindt u meer informatie over het bewaren van de release.

Vereisten

Standaard kunnen leden van de groepen Inzenders, Build-beheerders, Projectbeheerders en Releasebeheerders bewaarbeleid beheren.

Om bewaarbeleid te beheren, moet u een van de volgende abonnementen hebben:

• Enterprise
• Testexpert
• MSDN Platforms

U kunt ook maandelijkse toegang kopen tot Azure Test Plans en het toegangsniveau Basis + Testplannen toewijzen. Zie Toegang testen op gebruikersrol.

Bewaarbeleid configureren

1. Meld u aan bij uw project.

2. Ga naar het tabblad Instellingen van de instellingen van uw project.

3. Selecteer Instellingen of retentie vrijgeven onder Pijplijnen of Bewaren onder Test.

   • Klik op Instellingen om retentiebeleid te configureren voor uitvoeringen, artefacten, symbolen, bijlagen en pull-aanvragen.
   • Selecteer Releaseretentie om uw releaseretentiebeleid in te stellen en te configureren wanneer releases moeten worden verwijderd of permanent moeten worden vernietigd.
   • Selecteer Retentie om in te stellen hoe lang handmatige en geautomatiseerde testuitvoeringen moeten worden bewaard.

   

Bewaarbeleid voor taakuitvoering instellen

In de meeste gevallen hoeft u voltooide uitvoeringen niet langer te bewaren dan een bepaald aantal dagen. Met bewaarbeleid kunt u bepalen hoeveel dagen u elke uitvoering wilt behouden voordat u deze verwijdert.

1. Ga naar het tabblad Instellingen van de instellingen van uw project.

2. Selecteer Instellingen in de sectie Pijplijnen.

   • Stel het aantal dagen in om artefacten, symbolen en bijlagen te bewaren.
   • Het aantal dagen instellen om uitvoeringen te behouden
   • Het aantal dagen instellen om pull-aanvraaguitvoeringen te behouden
   • Het aantal recente uitvoeringen instellen dat voor elke pijplijn moet worden bewaard

Waarschuwing

Azure DevOps biedt geen ondersteuning meer voor bewaarregels per pijplijn. De enige manier om bewaarbeleid voor YAML- en klassieke pijplijnen te configureren, is via de projectinstellingen die hierboven worden beschreven. U kunt bewaarbeleid per pijplijn niet meer configureren.

De instelling voor het aantal recente uitvoeringen dat voor elke pijplijn moet worden bewaard, vereist een beetje meer uitleg. De interpretatie van deze instelling is afhankelijk van het type opslagplaats dat u in uw pijplijn bouwt.

• Azure Repos: Azure Pipelines behoudt het geconfigureerde aantal meest recente uitvoeringen voor de standaardvertakking van de pijplijn en voor elke beveiligde vertakking van de opslagplaats. Een vertakking waarvoor een vertakkingsbeleid is geconfigureerd, wordt beschouwd als een beveiligde vertakking.

  Denk bijvoorbeeld aan een opslagplaats met twee vertakkingen main en release. Stel dat de pipeline's default branch tak de main tak is en dat de release tak een vertakkingsbeleid heeft, waardoor het een beveiligde tak is. Als u in dit geval het beleid hebt geconfigureerd om drie uitvoeringen te behouden, worden zowel de laatste drie uitvoeringen van main als de laatste drie uitvoeringen van de release-vertakking behouden. Daarnaast worden de laatste drie uitvoeringen van deze pijplijn (ongeacht de vertakking) ook bewaard.

  Om deze logica verder te verduidelijken, laten we zeggen dat de lijst met uitvoeringen voor deze pijplijn als volgt is, met de meest recente uitvoering bovenaan. In de tabel ziet u welke uitvoeringen worden bewaard als u de laatste drie uitvoeringen hebt geconfigureerd (waarbij het effect van de instelling voor het aantal dagen wordt genegeerd):

  Rennen #	Filiaal	Behouden /Niet behouden	Waarom?
  Uitvoering 10	main	Behouden	Laatste 3 voor hoofd en laatste 3 voor pijplijn
  Run 9	branch1	Behouden	De laatste 3 voor de pijplijn
  Run 8	branch2	Behouden	Nieuwste 3 voor pijplijn
  Run 7	main	Behouden	Nieuwste 3 voor hoofdpagina
  Run 6	main	Behouden	Nieuwste 3 voor hoofdgedeelte
  Run 5	main	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, noch voor pijplijn
  Run 4	main	Niet behouden	Geen van de nieuwste 3 voor de hoofdversie, noch voor de pipeline
  Uitvoering 3	branch1	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, noch voor pijplijn
  Run 2	loslaten	Behouden	Nieuwste 3 voor release
  Uitvoering 1	main	Niet behouden	Geen van de laatste 3 voor hoofdlijn, noch voor pijplijn

• Alle andere Git-opslagplaatsen: Azure Pipelines behoudt het geconfigureerde aantal meest recente uitvoeringen voor de hele pijplijn.

• TFVC: Azure Pipelines behoudt het geconfigureerde aantal meest recente uitvoeringen voor de hele pijplijn, ongeacht de vertakking.

Welke onderdelen van de uitvoering worden verwijderd

De volgende informatie wordt verwijderd wanneer een proces wordt verwijderd:

• Logboeken
• Alle pijplijn- en build-artefacten
• Alle symbolen
• Binaire bestanden
• Testresultaten
• Metagegevens uitvoeren
• Bronlabels (TFVC) of tags (Git)

Universele pakketten, NuGet, npm en andere pakketten zijn niet gekoppeld aan retentie van pijplijnen.

Wanneer worden runs verwijderd

Uw bewaarbeleid wordt eenmaal per dag verwerkt. Het tijdstip waarop de verwerking van beleid plaatsvindt, varieert, omdat we het werk gedurende de dag spreiden voor taakverdeling. Er is geen optie om dit proces te wijzigen.

Een uitvoering wordt verwijderd als aan alle volgende voorwaarden wordt voldaan:

• Het overschrijdt het aantal dagen dat is geconfigureerd in de bewaarinstellingen
• Het is niet een van de recente uitvoeringen zoals geconfigureerd in de bewaarinstellingen
• Het is niet gemarkeerd om voor onbepaalde tijd te worden bewaard
• Het wordt niet bewaard door een vrijgave

Automatisch de retentielease instellen voor pijplijnuitvoeringen

Bewaarleases worden gebruikt voor het beheren van de levensduur van pijplijnuitvoeringen buiten de geconfigureerde bewaarperioden. Retentieleases kunnen worden toegevoegd aan of verwijderd in een pijplijn die wordt uitgevoerd door de Lease-API aan te roepen. Deze API kan worden aangeroepen in de pijplijn met behulp van een script en met behulp van vooraf gedefinieerde variabelen voor runId en definitionId.

Een retentielease kan gedurende een bepaalde periode worden toegevoegd aan een pijplijnuitvoering. Een pijplijnuitvoering die in een testomgeving wordt geïmplementeerd, kan bijvoorbeeld korter worden bewaard terwijl een uitvoering die in een productieomgeving wordt geïmplementeerd, langer kan worden bewaard.

Handmatig retentielease instellen voor pijplijnruns

U kunt handmatig een pijplijnuitvoering instellen die moet worden bewaard met behulp van het menu Meer acties op de pagina 'Details van pijplijnuitvoering'.

Een uitvoering verwijderen

U kunt uitvoeringen verwijderen met behulp van het Meer acties menu op de pagina pijplijnuitvoering Details.

Notitie

Als bewaarbeleidsregels momenteel van toepassing zijn op de uitvoering, moeten ze worden verwijderd voordat de uitvoering kan worden verwijderd. Zie voor instructies Details van uitvoering van een pijplijn - verwijder een uitvoering.

Het productteam werkt actief aan het verbeteren van gegevensverwijderingstijden. Mogelijk ziet u een verwerkingsvertraging van meerdere dagen bij het verwijderen van gegevens als er meerdere testpunten aan uw host zijn gekoppeld.

Bewaarbeleid voor release instellen

Het bewaarbeleid voor een release van een klassieke releasepijplijn bepaalt hoe lang een release en de bijbehorende uitvoering worden bewaard. Met behulp van deze beleidsregels kunt u bepalen hoeveel dagen u elke release wilt behouden nadat deze voor het laatst is gewijzigd of geïmplementeerd en het minimale aantal releases dat voor elke pijplijn moet worden bewaard.

De bewaartimer voor een release wordt telkens opnieuw ingesteld wanneer een release wordt gewijzigd of geïmplementeerd in een fase. Het minimale aantal releases dat de instelling moet behouden, heeft voorrang op het aantal dagen. Als u bijvoorbeeld opgeeft dat minimaal drie releases moeten worden bewaard, worden de meest recente drie voor onbepaalde tijd bewaard, ongeacht het aantal opgegeven dagen. U kunt deze releases echter handmatig verwijderen wanneer u ze niet meer nodig hebt. Zie de veelgestelde vragen hieronder voor meer informatie over de werking van releaseretentie.

Als auteur van een releasepijplijn kunt u het bewaarbeleid voor releases van uw pijplijn aanpassen op het tabblad Retentie.

Het bewaarbeleid voor YAML en build-pijplijnen is hetzelfde. U kunt de bewaarinstellingen van uw pijplijn bekijken in Projectinstellingen voor pijplijnen in de sectie Instellingen .

Beleid voor het bewaren van wereldwijde releases

Als u een on-premises Team Foundation Server of Azure DevOps Server gebruikt, kunt u de standaardwaarden en maximumwaarden voor het bewaarbeleid voor een project opgeven. U kunt ook opgeven wanneer releases permanent worden vernietigd (verwijderd van het tabblad Verwijderd in de buildverkenner).

Als u Azure DevOps Services gebruikt, kunt u deze instellingen voor uw project bekijken, maar niet wijzigen.

Algemene instellingen voor bewaarbeleid voor release kunnen worden gecontroleerd vanuit de bewaarinstellingen voor release van uw project:

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

Met het maximale bewaarbeleid wordt de bovengrens ingesteld voor hoe lang releases kunnen worden bewaard voor alle release-pijplijnen. Auteurs van release-pijplijnen kunnen geen instellingen voor hun definities configureren buiten de waarden die hier zijn opgegeven.

Met het standaardretentiebeleid worden de standaardretentiewaarden voor alle release-pijplijnen ingesteld. Auteurs van build-pijplijnen kunnen deze waarden overschrijven.

Het vernietigingsbeleid helpt u de releases gedurende een bepaalde periode te behouden nadat ze zijn verwijderd. Dit beleid kan niet worden overschreven in afzonderlijke release-pijplijnen.

Gebruik de taak Bestanden kopiëren om gegevens langer op te slaan

U kunt de taak Bestanden kopiëren gebruiken om uw build- en artefactgegevens langer op te slaan dan wat is ingesteld in de bewaarbeleid. De taak Bestanden kopiëren heeft de voorkeur boven de taak BuildArtefacten publiceren, omdat gegevens die zijn opgeslagen met de taak BuildArtefacten publiceren periodiek worden opgeschoond en verwijderd.

YAML

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

Klassiek

1. Voeg de taak Bestanden kopiëren toe aan uw pijplijn.

2. Configureer de Bestanden kopiëren-taak.

Veelgestelde vragen

Als ik een uitvoering of een release markeer die voor onbepaalde tijd moet worden bewaard, is het bewaarbeleid nog steeds van toepassing?

Nee Wanneer u een afzonderlijke uitvoering of release markeert die voor onbepaalde tijd moet worden bewaard, worden noch het bewaarbeleid van de pijplijn, noch de maximumlimieten die door de beheerder zijn ingesteld, toegepast. Het zal blijven totdat u het niet meer oneindig bewaart.

Hoe kan ik opgeven dat uitvoeringen die in productie worden geïmplementeerd, langer worden bewaard?

Als u klassieke releases gebruikt om te implementeren in productie, past u het bewaarbeleid voor de release-pijplijn aan. Geef het aantal dagen op dat releases die in productie zijn geïmplementeerd, moeten worden bewaard. Daarnaast geeft u aan dat de uitvoeringen die aan die release zijn gekoppeld, behouden moeten blijven. Hiermee wordt het retentiebeleid voor de uitvoering overschreven.

Als u YAML-pijplijnen met meerdere fasen gebruikt om te implementeren in productie, bevindt het enige bewaarbeleid dat u kunt configureren zich in de projectinstellingen. U kunt retentie niet aanpassen op basis van de omgeving waarin de build is geïmplementeerd.

Ik heb geen reeksen gemarkeerd om voor onbepaalde tijd te worden bewaard. Ik zie echter dat er een groot aantal runs wordt bewaard. Hoe kan ik dit voorkomen?

Dit kan een van de volgende redenen hebben:

• De uitvoeringen worden door iemand in uw project gemarkeerd om voor onbepaalde tijd te worden bewaard.
• De uitvoeringen worden verbruikt door een release en de release bevat een bewaarvergrendeling op deze uitvoeringen. Pas het bewaarbeleid voor de release aan zoals hierboven wordt uitgelegd.

Als u denkt dat de uitvoeringen niet meer nodig zijn of als de releases al zijn verwijderd, kunt u de uitvoeringen handmatig verwijderen.

Hoe werkt de instelling 'minimale releases om te behouden'?

Minimale releases die moeten worden bewaard, zijn op faseniveau gedefinieerd. Het geeft aan dat Azure DevOps altijd het opgegeven aantal laatst geïmplementeerde releases voor een fase behoudt, zelfs als de releases buiten de bewaarperiode vallen. Een release wordt beschouwd onder minimale releases die alleen voor een fase moeten worden bewaard wanneer de implementatie in die fase is gestart. Zowel geslaagde als mislukte implementaties worden overwogen. Releases die in afwachting van goedkeuring zijn, worden niet in beschouwing genomen.

Hoe wordt de bewaarperiode bepaald wanneer de release wordt geïmplementeerd in meerdere fasen met een andere bewaarperiode?

De uiteindelijke bewaarperiode wordt bepaald door de bewaardagen van de instellingen van alle fasen waarop de release wordt uitgerold te evalueren en de maximale bewaarduur daaruit te kiezen. Minimale releases die moeten worden bewaard , worden op faseniveau beheerd en worden niet gewijzigd op basis van de release die in meerdere fasen is geïmplementeerd of niet. Gekoppelde artefacten behouden zijn van toepassing wanneer de release wordt geïmplementeerd in een fase waarvoor het waar is ingesteld.

Ik heb een fase verwijderd waarvoor ik een aantal oude uitgaven heb. Welke bewaarperiode wordt in aanmerking genomen voor deze zaak?

Wanneer de fase wordt verwijderd, zijn de bewaarinstellingen voor faseniveau dus nu niet van toepassing. Azure DevOps valt terug op standaardretentie op projectniveau voor dergelijke gevallen.

Mijn organisatie vereist dat we builds en releases langer bewaren dan is toegestaan in de instellingen. Hoe kan ik een langere retentie aanvragen?

De enige manier om een uitvoering of een release langer te bewaren dan wat is toegestaan via bewaarinstellingen, is om deze handmatig te markeren om voor onbepaalde tijd te worden bewaard. Er is geen manier om handmatig een langere bewaarinstelling te configureren. Neem contact op met de ondersteuning van Azure DevOps voor hulp.

U kunt ook de mogelijkheid verkennen om de REST API's te gebruiken om informatie en artefacten over de uitvoeringen te downloaden en deze te uploaden naar uw eigen opslag- of artefactopslagplaats.

Ik verloor wat punten. Is er een manier om ze terug te krijgen?

Als u denkt dat u runs hebt verloren vanwege een fout in de service, maak dan onmiddellijk een supportticket aan om de verloren gegevens te herstellen. Als een builddefinitie meer dan een week eerder handmatig is verwijderd, is het niet mogelijk om deze te herstellen. Als de runs zoals verwacht vanwege een bewaarbeleid zijn verwijderd, is het niet mogelijk de verloren runs te herstellen.

Hoe kan ik de Build.Cleanup functionaliteit van agenten gebruiken?

Als u een Build.Cleanup capaciteit instelt op agentes, worden de opschoontaken van de pool alleen naar die agentes geleid, waardoor de rest vrij blijft om normaal werk te doen. Wanneer een pipeline-run wordt verwijderd, worden artefacten die buiten Azure DevOps zijn opgeslagen, opgeschoond via een taak die door de agents wordt uitgevoerd. Wanneer de agentpool verzadiging krijgt met opschoontaken, kan dit een probleem veroorzaken. De oplossing hiervoor is om een subset van agents in de pool aan te wijzen die de opschoonagents zijn. Als er agents zijn waarvan de Build.Cleanup zijn ingesteld, zullen alleen die agents de opschoontaken uitvoeren, terwijl de rest van de agents vrij blijft om de pijplijntaken uit te voeren. De functie Opschonen kan worden ingeschakeld door te navigeren naar Agent>Mogelijkheden en de instelling Build.Cleanup gelijk te zetten aan 1.

Wat gebeurt er met bestandsshareartefacten wanneer de build wordt verwijderd

Wanneer een build met gedeelde bestandartefacten wordt verwijderd, wordt er een nieuwe build-taak in de wachtrij geplaatst op een buildagent om die bestanden op te schonen. Er wordt een agent gekozen om deze taak uit te voeren op basis van de volgende criteria: Is er een agent met Build.Cleanup de mogelijkheid beschikbaar? Is de agent die de build heeft uitgevoerd beschikbaar? Is er een agent uit dezelfde pool beschikbaar? Is er een agent uit een vergelijkbare pool beschikbaar? Is er een agent beschikbaar?

Worden geautomatiseerde testresultaten die worden gepubliceerd als onderdeel van een release bewaard totdat de release wordt verwijderd?

Testresultaten die worden gepubliceerd in een fase van een release, worden bewaard zoals opgegeven door het bewaarbeleid dat is geconfigureerd voor de testresultaten. De testresultaten worden niet vastgehouden tot de release is vastgehouden. Als u de testresultaten nodig hebt zolang de release is uitgevoerd, stelt u de bewaarinstellingen in voor geautomatiseerde testuitvoeringen in de Project-instellingen dienovereenkomstig op Nooit verwijderen. Dit zorgt ervoor dat de testresultaten alleen worden verwijderd wanneer de release wordt verwijderd.

Worden handmatige testresultaten verwijderd?

Nee Handmatige testresultaten worden niet verwijderd.

Hoe kan ik mijn labels of tags voor versiebeheer behouden?

Let op

Versiebeheerlabels of tags die worden toegepast tijdens een build-pijplijn die niet automatisch worden gemaakt op basis van de taak Bronnen, blijven behouden, zelfs als de build wordt verwijderd. Alle labels of tags voor versiebeheer die tijdens een build automatisch worden gemaakt op basis van de taak Bronnen, worden echter beschouwd als onderdeel van de buildartefacten en worden verwijderd wanneer de build wordt verwijderd.

Als versiebeheerlabels of -tags zelfs moeten worden behouden wanneer de build wordt verwijderd, moeten ze worden toegepast als onderdeel van een taak in de pijplijn of handmatig worden gelabeld buiten de pijplijn, of de build moet voor onbepaalde tijd worden bewaard.

Wat gebeurt er met pijplijnen die worden gebruikt in andere pijplijnen?

Klassieke releases behouden pijplijnen die ze automatisch gebruiken.

Verwante artikelen:

• Bepalen hoe lang testresultaten moeten worden bewaard
• Testartefacten verwijderen
• Het Gebruik van Taken om Uitvoeringen in Azure Pipelines te Behouden