Bewaarbeleid

Bewaarbeleid configureren

Voer de volgende stappen uit om de pagina's met bewaarinstellingen in uw project te openen en het beleidsgebied te kiezen dat u wilt beheren:

1. Meld u aan bij uw Azure DevOps-project.

2. Selecteer >Projectinstellingen.

3. Selecteer een van de volgende opties:

   • Selecteer onder Pijplijneninstellingen voor het configureren van retentie voor uitvoeringen, artefacten, symbolen, bijlagen en pull-aanvraaguitvoeringen.
   • Selecteer onder Pijplijnende optie Releaseretentie om bewaarinstellingen voor releases te configureren, inclusief wanneer releases worden verwijderd of permanent worden vernietigd.
   • Selecteer onder TestenRetentie om te configureren hoe lang handmatige en geautomatiseerde testuitvoeringen worden bewaard.

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

2. Selecteer Instellingen in de sectie Pijplijnen:

   • Stel in hoeveel dagen artefacten, symbolen en bijlagen moeten worden bewaard.
   • Stel in hoeveel dagen de uitvoeringen moeten worden bewaard.
   • Stel in hoeveel dagen pull-aanvragen moeten worden uitgevoerd.
   • Stel het aantal recente uitvoeringen in dat moet worden bewaard voor elke pijplijn.

Het aantal recente uitvoeringen dat voor elke pijplijninstelling moet worden bewaard , wordt anders geïnterpreteerd op basis van het type opslagplaats:

• Azure-opslagplaatsen: Azure-pipelines behoudt het geconfigureerde aantal meest recente uitvoeringen voor de standaardvertakking van pipeline en voor elke beveiligde vertakking in de opslagplaats. Een beveiligde vertakking is een vertakking met vertakkingsbeleid dat is geconfigureerd.

  Denk bijvoorbeeld aan een opslagplaats met twee vertakkingen: main en release. Als de standaardbranch van de pijplijn main is en release een vertakkingsbeleid heeft, wordt release beschouwd als een beveiligde vertakking. Als u retentie configureert om drie uitvoeringen te behouden, zal Azure-pipelines de meest recente drie uitvoeringen voor main, de meest recente drie uitvoeringen voor release en de meest recente drie uitvoeringen voor de gehele pijplijn (ongeacht de vertakking) behouden.

  In het volgende voorbeeld wordt ervan uitgegaan dat de meest recente uitvoering eerst wordt vermeld. Hier ziet u welke uitvoeringen worden bewaard wanneer u retentie configureert om de laatste drie uitvoeringen te behouden (waarbij de instelling op basis van dagen wordt genegeerd).

  Rennen #	Filiaal	Behouden/niet behouden	Waarom?
  Voer 10 tests uit	main	Behouden	Nieuwste 3 voor hoofd- en nieuwste 3 voor pijplijn
  Uitvoeren 9	branch1	Behouden	De laatste 3 voor de pijplijn
  Voer 8 uit	branch2	Behouden	De laatste 3 voor de pijplijn
  Uitvoer 7	main	Behouden	Nieuwste 3 voor hoofdpagina
  Uitvoeren 6	main	Behouden	Nieuwste 3 voor hoofdpagina
  Voer 5 uit	main	Niet behouden	Niet de nieuwste 3 voor hoofd- of pijplijn
  Uitvoeren 4	main	Niet behouden	Niet de nieuwste 3 voor hoofd- of pijplijn
  Run 3	branch1	Niet behouden	Niet de nieuwste 3 voor hoofd- of pijplijn
  Uitvoering 2	loslaten	Behouden	Nieuwste 3 ter publicatie
  Voer 1 uit	main	Niet behouden	Niet de nieuwste 3 voor hoofd- of pijplijn

  Het aantal dagen dat moet worden bewaard, wordt berekend vanaf de datum waarop de uitvoering is voltooid. Er zijn bijvoorbeeld twee uitvoeringen op een hoofdtak op 19 januari. De run die later is voltooid, wordt bewaard.

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

• Team Foundation Version Control (TFVC): Azure-pipelines behoudt het geconfigureerde aantal meest recente uitvoeringen voor de hele pijplijn, ongeacht de vertakking.

Wanneer een uitvoering wordt verwijderd, worden de volgende gegevens verwijderd:

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

Retentie van pijplijnuitvoering is niet van toepassing op Universal Packages, NuGet, npm en andere pakketten.

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

• Het overschrijdt het aantal dagen dat is geconfigureerd in de bewaarinstellingen.
• Het is geen van de recente uitvoeringen zoals geconfigureerd in de bewaarinstellingen.
• Deze is niet gemarkeerd voor onbepaalde retentie.
• Het wordt niet bewaard door een release.

Bewaarbeleid wordt één keer per dag verwerkt. De verwerkingstijd varieert omdat het werk gedurende de dag wordt verdeeld voor taakverdeling. U kunt dit schema niet wijzigen.

Automatisch de retentielease instellen voor pijplijnuitvoeringen

Met retentieleases kunt u de levensduur van pijplijnuitvoeringen verlengen of beheren na geconfigureerde bewaarperioden. U kunt leases voor een pijplijnuitvoering toevoegen of verwijderen met behulp van de Lease-API. U kunt deze API vanuit een pijplijn aanroepen met behulp van een script en vooraf gedefinieerde variabelen voor runId en definitionId.

U kunt een lease voor een specifieke duur instellen. U kunt bijvoorbeeld een run behouden die voor een kortere periode wordt uitgerold in een testomgeving. U kunt een uitvoering die gedurende langere tijd in productie wordt geïmplementeerd, behouden.

Handmatig retentielease instellen voor pijplijnruns

U kunt een pijplijnuitvoering handmatig behouden via het menu Meer acties op de pagina Details van pijplijnuitvoering .

Een uitvoering verwijderen

U kunt uitvoeringen verwijderen uit het menu Meer acties op de pagina met details van de pijplijnuitvoering.

YAML en buildpipelines maken gebruik van hetzelfde bewaarbeleid voor runs. U kunt deze instellingen weergeven onder Project instellingen>Pipelines>Settings.

Beleid voor het bewaren van wereldwijde releases

In Azure DevOps Services kunt u deze instellingen bekijken, maar u kunt ze niet wijzigen op projectniveau.

U kunt de algemene bewaarinstellingen voor release bekijken via de Bewaarretentiepagina van uw project Project:

• Maximaal bewaarbeleid: definieert de bovengrens voor hoe lang u releases in alle release-pijplijnen kunt bewaren. Auteurs van pijplijnen kunnen geen retentie buiten deze limiet configureren.
• Standaardretentiebeleid: definieert de standaardretentiewaarden die worden toegepast op release-pijplijnen. Pijplijnauteurs kunnen deze standaardinstellingen overschrijven.
• Permanente vernietiging van releases: bepaalt hoe lang verwijderde releases worden bewaard vóór permanente verwijdering. Afzonderlijke release-pijplijnen kunnen dit beleid niet overschrijven.

Beleid voor het bewaren van wereldwijde releases

Als u Azure DevOps Server on-premises gebruikt, kunt u de standaardinstellingen en maximumwaarden op projectniveau configureren voor het bewaren van de release. U kunt ook instellen wanneer verwijderde releases permanent worden vernietigd. (Ze worden verwijderd uit het tabblad Verwijderd in Build Explorer.)

• Maximaal bewaarbeleid: definieert de bovengrens voor hoe lang u releases in alle release-pijplijnen kunt bewaren. Auteurs van pijplijnen kunnen geen retentie buiten deze limiet configureren.
• Standaardretentiebeleid: definieert de standaardretentiewaarden die worden toegepast op release-pijplijnen. Pijplijnauteurs kunnen deze standaardinstellingen overschrijven.
• Permanente vernietiging van releases: bepaalt hoe lang verwijderde releases worden bewaard vóór permanente verwijdering. Afzonderlijke release-pijplijnen kunnen dit beleid niet overschrijven.

Bewaarbeleid op verzamelingsniveau instellen

Als u een on-premises server gebruikt, kunt u ook retentie op verzamelingsniveau configureren met aangepaste regels. Deze instellingen zijn van toepassing op klassieke build-pijplijnen en definiëren de standaard- en maximumretentiewaarden voor de verzameling.

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

Als u de build-uitvoer langer wilt bewaren dan de geconfigureerde bewaarperiode, kopieert u deze naar uw eigen opslaglocatie met behulp van de taak Bestanden kopiëren.

Gebruik Bestanden kopiëren in plaats van build-artifacten publiceren omdat gegevens die zijn gepubliceerd als build-artifacten nog steeds onderhevig zijn aan retentie-opschoning.

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

Hoe kan ik mijn labels of tags voor versiebeheer behouden?

Als labels of tags moeten worden bewaard nadat een build is verwijderd, past u deze toe in een pijplijntaak, voegt u deze handmatig toe buiten de pijplijn of behoudt u de build voor onbepaalde tijd.

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

Klassieke releases behouden pijplijnen die ze automatisch gebruiken.

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

Klassieke releases behouden pijplijnen die ze automatisch gebruiken. Als u YAML gebruikt, kunt u ook een multi-stage YAML-pijplijn maken om uw release weer te geven en daarin een andere YAML-pijplijn als resource te gebruiken. De resourcepijplijn wordt automatisch bewaard zolang de release-pijplijn behouden blijft.