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.

   • Selecteer Instellingen om bewaarbeleid te configureren voor uitvoeringen, artefacten, symbolen, bijlagen en uitvoeringen van 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 uitvoering 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-opslagplaatsen: 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 vertakking de main vertakking is en dat de vertakking een vertakkingsbeleid heeft, waardoor deze release een beveiligde vertakking is. Als u in dit geval het beleid hebt geconfigureerd om drie uitvoeringen te behouden, blijven zowel de laatste drie uitvoeringen als main 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 #	Vertakking	Behouden /Niet behouden	Waarom?
  Uitvoering 10	main	Behouden	Nieuwste 3 voor hoofd- en laatste 3 voor pijplijn
  Uitvoering 9	branch1	Behouden	Nieuwste 3 voor pijplijn
  Uitvoering 8	branch2	Behouden	Nieuwste 3 voor pijplijn
  Uitvoering 7	main	Behouden	Nieuwste 3 voor hoofd
  Uitvoering 6	main	Behouden	Nieuwste 3 voor hoofd
  Uitvoering 5	main	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, noch voor pijplijn
  Uitvoering 4	main	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, noch voor pijplijn
  Uitvoering 3	branch1	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, noch voor pijplijn
  Uitvoering 2	loslaten	Behouden	Nieuwste 3 voor release
  Uitvoering 1	main	Niet behouden	Geen van de nieuwste 3 voor hoofdpijplijn, 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 uitvoering wordt verwijderd:

• Logboeken
• Alle pijplijn- en buildartefacten
• 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 uitgevoerd, verwijderd

Uw bewaarbeleid wordt eenmaal per dag verwerkt. Het tijdstip waarop het beleid verwerkte variabelen krijgt, omdat we het werk gedurende de hele dag verspreiden voor taakverdelingsdoeleinden. 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 release

Retentielease automatisch 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.

Retentielease handmatig instellen voor pijplijnuitvoeringen

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 menu Meer acties op de pagina Details van pijplijnuitvoering.

Notitie

Als bewaarbeleidsregels momenteel van toepassing zijn op de uitvoering, moeten ze worden verwijderd voordat de uitvoering kan worden verwijderd. Zie Details van pijplijnuitvoering voor instructies : een uitvoering verwijderen.

Bewaarbeleid voor release instellen

Het bewaarbeleid voor de release voor een klassieke release-pijplijn bepaalt hoe lang een release en de uitvoering eraan zijn gekoppeld, behouden blijven. 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 release-pijplijn kunt u bewaarbeleid aanpassen voor releases van uw pijplijn 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 .

Bewaarbeleid voor globale release

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
• On-premises: 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 is ingesteld in het 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 taak Bestanden kopiëren.

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 Het bewaarbeleid van de pijplijn noch de maximumlimieten die door de beheerder zijn ingesteld, worden toegepast wanneer u een afzonderlijke uitvoering of release markeert die voor onbepaalde tijd moet worden bewaard. Het blijft totdat u het voor onbepaalde tijd niet meer behoudt.

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 uitvoeringen die aan die release zijn gekoppeld, moeten worden bewaard. Hiermee wordt het bewaarbeleid voor 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 looptekens 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 gemarkeerd door iemand in uw project die voor onbepaalde tijd moet 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, worden gedefinieerd op faseniveau. 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 behandeling zijn, worden niet meegenomen.

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

De laatste bewaarperiode wordt bepaald door dagen te overwegen om instellingen te bewaren van alle fasen waarop de release wordt geïmplementeerd en het duurt maximaal dagen om ertussen te blijven. 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 stadium verwijderd waarvoor ik een aantal oude releases 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.

Voor mijn organisatie moeten 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 uitvoeringen hebt verloren vanwege een fout in de service, maakt u onmiddellijk een ondersteuningsticket 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 uitvoeringen zijn verwijderd zoals verwacht vanwege een bewaarbeleid, is het niet mogelijk om de verloren uitvoeringen te herstellen.

Hoe kan ik de Build.Cleanup mogelijkheid van agents gebruiken?

Als u een Build.Cleanup mogelijkheid instelt op agents, worden de opschoontaken van de pool omgeleid naar alleen die agents, waardoor de rest vrij blijft om regelmatig werk te doen. Wanneer een pijplijnuitvoering wordt verwijderd, worden artefacten die buiten Azure DevOps zijn opgeslagen, opgeschoond via een taak die op 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 Build.Cleanup ingesteld, worden alleen de opschoontaken uitgevoerd, waardoor de rest van de agents vrij blijven om pijplijntaken uit te voeren. De functie Opschonen kan worden ingeschakeld door te navigeren naar agentmogelijkheden> en de instelling Build.Cleanup gelijk aan .1

Wat gebeurt er met bestandsshareartefacten wanneer de build wordt verwijderd

Wanneer een build met bestandsshareartefacten wordt verwijderd, wordt 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 pas bewaard als de release is behouden. 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