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

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Med kvarhållningsprinciper 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) – Ange om du vill spara byggen och visa standardinställningarna för och maximal 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ållningsprinciper för körning

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 kvarhållningsprinciper kan du styra hur många dagar du vill behålla varje körning innan du tar bort den.

Vilka delar av körningen 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. Det minsta antalet versioner som ska behållas har företräde framför 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 Vanliga frågor och svar nedan för mer information om hur kvarhållning av versioner fungerar.

Som författare till en versionspipeline kan du anpassa kvarhållningsprinciper för versioner av din pipeline på fliken Kvarhållning .

Global kvarhållningsprincip för versioner

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 kvarhållningsprincip för versioner kan granskas från inställningarna för kvarhållning av versioner i projektet:

• 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 versioner kan behållas för alla versionspipelines. Författare av versionspipelines kan inte konfigurera inställningar för sina definitioner utöver de värden som anges här.

Standardkvarhållningsprincipen anger standardkvarhållningsvärdena för alla versionspipelines. Författare 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 principen kan inte åsidosättas i enskilda versionspipelines.

- 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 version som ska behållas på obestämd tid?

Nej. Varken pipelinens kvarhållningsprincip eller de maximala grä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 anger jag att körningar som distribueras till produktion ska behållas längre?

Om du använder klassiska versioner för att distribuera till produktion anpassar du kvarhållningsprincipen på versionspipelinen. Ange hur många dagar som 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 kvarhållning baserat på den miljö som bygget distribueras till.

Jag har inte markerat körningar som ska behållas på obestämd tid. 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 projektet som ska behållas på obestämd tid.
• Körningarna används av en version och versionen innehåller ett kvarhållningslås på dessa körningar. Anpassa kvarhållningsprincipen för versioner enligt beskrivningen ovan.

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

Hur fungerar inställningen "minsta versioner för att behålla"?

Minsta antal versioner som ska behållas definieras på stegnivå. Det anger att Azure DevOps alltid behåller det angivna antalet senast distribuerade versioner för en fas även om versionerna inte är kvar. En version kommer att övervägas under lägsta versioner som ska behållas i ett steg först när distributionen startade på den fasen. 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 bestäms genom att överväga dagar för att behålla inställningarna för alla faser där versionen distribueras och det tar maximalt dagar att behålla 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 kommer att gälla när versionen distribueras till en fas där den är inställd på sant.

Jag har tagit bort en fas där 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 standardkvarhållning på projektnivå för sådana fall.

Min organisation kräver att vi behåller versioner 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 som är längre än vad som tillåts via kvarhållningsinställningar är att manuellt markera att den ska 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 körningar. 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 skapar du en supportbegäran omedelbart 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 kvarhållningsprincip går det inte att återställa de förlorade körningarna.

Hur använder jag agenternas Build.Cleanup 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 en jobbkörning 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 köra rensningsjobben, vilket gör att resten av agenterna kan fortsätta köra pipelinejobb. Rensningsfunktionen kan aktiveras genom att gå till Agentfunktioner> och ange Build.Cleanup lika 1med .

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

När en version med filresursartefakter tas bort placeras en ny bygguppgift i kö på en byggagent för att rensa filerna. 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 kö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 behålls inte förrän versionen behålls. Om du behöver testresultatet så länge som versionen anger du kvarhållningsinställningarna för automatiserade testkörningar i Project-inställningarna enligt Ta aldrig 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