Ange kvarhållningsprinciper för byggen, versioner och tester

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Med lagringspolicyer kan du ange hur länge körningar, versioner och tester ska lagras i systemet. Om du vill spara lagringsutrymme vill du ta bort äldre körningar, tester och versioner.

Följande kvarhållningsprinciper är tillgängliga i Azure DevOps i dina Project-inställningar:

1. Pipeline – Ange hur länge artefakter, symboler, bifogade filer, körningar och pull-begäranden ska köras.
2. Release (klassisk) – Ställ in om du vill spara byggen och visa standard- och maxinställningar för kvarhållning.
3. Test – Ange hur länge automatiserade och manuella testkörningar, resultat och bifogade filer ska behållas.

Förutsättningar

Som standard kan medlemmar i grupperna Contributors (deltagare), Build Admins (byggadministratörer), Project Admins (projektadministratörer), och Release Admins (versionsadministratörer) hantera kvarhållningsprinciper.

Om du vill hantera kvarhållningsprinciper måste du ha någon av följande prenumerationer:

• Enterprise
• Testspecialist
• MSDN-plattformar

Du kan också köpa månatlig åtkomst till Azure-testplaner och tilldela åtkomstnivån Basic + Test Plans. Se Testning av åtkomst efter användarroll.

Ange kvarhållningspolicys för processer

I de flesta fall behöver du inte behålla slutförda körningar längre än ett visst antal dagar. Med hjälp av bevarandeprinciper kan du hantera hur många dagar du vill behålla varje körning innan du tar bort den.

Vilka delar av processen tas bort

När tas körningar bort

Ange kvarhållningsprinciper för versioner

Kvarhållningsprinciperna för en klassisk versionspipeline avgör hur länge en version och körningen som är länkad till den behålls. Med hjälp av dessa principer kan du styra hur många dagar du vill behålla varje version när den senast har ändrats eller distribuerats och det minsta antalet versioner som ska behållas för varje pipeline.

Kvarhållningstimern för en version återställs varje gång en version ändras eller distribueras till en fas. Inställningen för att behålla ett minimalt antal versioner ges företräde över antalet dagar. Om du till exempel anger att minst tre versioner ska behållas behålls de senaste tre på obestämd tid – oavsett hur många dagar som har angetts. Du kan dock ta bort dessa versioner manuellt när du inte längre behöver dem. Se FAQ nedan för mer information om hur versionshantering fungerar.

Som skapare av en releasepipeline kan du anpassa principerna för kvarhållning för releaser av din pipeline på fliken Kvarhållning.

Global retentionspolicy för utgåvor

Om du använder en lokal Team Foundation Server eller Azure DevOps Server kan du ange standardinställningar för versionsbevarandeprincip och maxvärden för ett projekt. Du kan också ange när versioner förstörs permanent (tas bort från fliken Borttaget i build explorer).

Om du använder Azure DevOps Services kan du visa men inte ändra de här inställningarna för projektet.

Inställningar för global versionskvarhållningsprincip kan granskas från projektets inställningar för versionskvarhållning.

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

Den maximala kvarhållningsprincipen anger den övre gränsen för hur länge utgåvor får behållas för alla publiceringspipelines. Skapare av utgivningspipelines kan inte konfigurera inställningar för sina definitioner utöver de konfigurationsvärden som anges i det här sammanhanget.

Standardkvarhållningspolicyn anger de förvalda kvarhållningsvärdena för alla releasepipelines. Skapare av byggpipelines kan åsidosätta dessa värden.

Destruktionsprincipen hjälper dig att behålla versionerna under en viss tidsperiod efter att de har tagits bort. Den här policyn kan inte åsidosättas i enskilda releasepipelines.

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

Vanliga frågor

Gäller kvarhållningsprincipen fortfarande om jag markerar en körning eller en utgåva att behållas på obestämd tid?

Nej. Varken pipelinens lagringsprincip eller de maximigränser som angetts av administratören tillämpas när du markerar att en enskild körning eller version ska behållas på obestämd tid. Den förblir tills du slutar behålla den på obestämd tid.

Hur gör jag för att ange att körningar som distribueras till produktion ska behållas längre?

Om du använder klassiska versioner för att distribuera till produktionsmiljö, anpassa kvarhållningsprincipen i versionspipelinen. Ange hur många dagar versioner som distribueras till produktion måste behållas. Ange dessutom att körningar som är associerade med den versionen ska behållas. Detta åsidosätter kvarhållningsprincipen för körning.

Om du använder YAML-pipelines i flera steg för att distribuera till produktion finns den enda kvarhållningsprincip som du kan konfigurera i projektinställningarna. Du kan inte anpassa lagring baserat på den miljö där bygget distribueras.

Jag har inte markerat körningar som ska behållas utan tidsgräns. Jag ser dock att ett stort antal körningar behålls. Hur kan jag förhindra detta?

Detta kan bero på någon av följande orsaker:

• Körningarna markeras av någon i ditt projekt för att behållas för obestämd tid.
• Körningarna förbrukas av en version, och versionen har ett kvarhållningslås på dessa körningar. Anpassa kvarhållningspolicyn för utgivning enligt beskrivningen ovan.

Om du anser att körningarna inte längre behövs eller om versionerna redan har raderats, kan du ta bort körningarna manuellt.

Hur fungerar inställningen "minsta antal versioner att behålla"?

Minsta antal versioner som ska behållas definieras på stegnivå. Det innebär att Azure DevOps alltid kommer att behålla det angivna antalet senaste distribuerade releaser för ett steg, även om dessa releaser är utanför lagringsperioden. En utgåva kommer att övervägas bland de minimala utgåvor som ska behållas för ett steg först när distributionen började i det steget. Både lyckade och misslyckade distributioner beaktas. Versioner som väntar på godkännande beaktas inte.

Hur avgörs kvarhållningsperioden när versionen distribueras till flera faser med olika kvarhållningsperiod?

Den slutliga kvarhållningsperioden fastställs genom att ta hänsyn till de dagar som behövs för att behålla inställningarna för alla faser där versionen distribueras och att välja det maximala antalet dagar för att bevara dem. Minsta antal versioner som ska behållas styrs på fasnivå och ändras inte baserat på lansering som distribuerats till flera faser eller inte. Behåll associerade artefakter är tillämpligt när versionen distribueras till en etapp där det är inställt på sant.

Jag har tagit bort en etapp för vilken jag har några gamla versioner. Vilken kvarhållning kommer att övervägas för det här fallet?

När fasen tas bort är kvarhållningsinställningarna på stegnivå inte tillämpliga nu. Azure DevOps återgår till standardinställning för kvarhållning på projektnivå för sådana fall.

Min organisation kräver att vi behåller byggdistributioner och versioner längre än vad som tillåts i inställningarna. Hur kan jag begära en längre kvarhållningstid?

Det enda sättet att behålla en körning eller en version längre än vad som tillåts genom kvarhållningsinställningarna är att manuellt markera den för att behållas på obestämd tid. Det går inte att konfigurera en längre kvarhållningsinställning manuellt. Kontakta Azure DevOps-supporten om du behöver hjälp.

Du kan också utforska möjligheten att använda REST API:er för att ladda ned information och artefakter om körningarna och ladda upp dem till din egen lagrings- eller artefaktlagringsplats.

Jag förlorade några löprundor. Finns det något sätt att få dem tillbaka?

Om du tror att du har förlorat körningar på grund av en bugg i tjänsten, skapa omedelbart ett supportärende för att återställa den förlorade informationen. Om en versionsdefinition togs bort manuellt mer än en vecka tidigare går det inte att återställa den. Om körningarna togs bort som förväntat på grund av en retentionspolicy kommer det inte att vara möjligt att återställa de förlorade körningarna.

Hur gör jag för att använda Build.Cleanup agenternas kapacitet?

Om du ställer in en Build.Cleanup funktion på agenter kommer poolens rensningsjobb att dirigeras till bara dessa agenter, vilket gör att resten kan utföra regelbundet arbete. När en pipelinekörning tas bort rensas artefakter som lagras utanför Azure DevOps genom att ett jobb körs på agenterna. När agentpoolen blir mättad med rensningsjobb kan detta orsaka ett problem. Lösningen på detta är att utse en delmängd av agenter i poolen som är rensningsagenter. Om några agenter har Build.Cleanup angetts kommer endast dessa agenter att utföra rensningsjobben, vilket innebär att resten av agenterna är fria att fortsätta köra pipelinejobb. Rensningsfunktionen kan aktiveras genom att gå till Agent>Kapaciteter och ställa in Build.Cleanup till 1.

Vad händer med filresursartefakter när bygget tas bort

När en version med fildelningsartefakter tas bort placeras en ny bygguppgift i kö på en byggagent för att rensa dessa filer. En agent väljs för att utföra den här uppgiften baserat på följande villkor: Finns det en agent med Build.Cleanup tillgänglig kapacitet? Är agenten som genomförde bygget tillgänglig? Är en agent från samma pool tillgänglig? Är en agent från en liknande pool tillgänglig? Är någon agent tillgänglig?

Behålls automatiserade testresultat som publiceras som en del av en version tills versionen har tagits bort?

Testresultat som publicerats i ett steg i en version behålls enligt den kvarhållningsprincip som konfigurerats för testresultaten. Testresultaten arkiveras inte förrän utgåvan sparas. Om du behöver testresultaten så länge som släppet kvarstår, ställ in kvarhållningsinställningarna för automatiserade testkörningar i projektinställningarna till Aldrig ta bort. Detta säkerställer att testresultaten endast tas bort när versionen tas bort.

Tas manuella testresultat bort?

Nej. Manuella testresultat tas inte bort.

Relaterade artiklar

• Kontrollera hur länge testresultaten ska behållas
• Ta bort testartefakter
• Använda aktiviteter för att behålla körningar i Azure Pipelines