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.

Kommentar

Om du använder en lokal server kan du också ange standardvärden för kvarhållningsprinciper för ett projekt och när versioner förstörs permanent. Läs mer om kvarhållning av versioner senare i den här artikeln.

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.

Konfigurera kvarhållningsprinciper

1. Logga in på projektet.

2. Gå till fliken Inställningar i projektets inställningar.

3. Välj Inställningar eller Släpp kvarhållning under Pipelines eller Kvarhållning under Test.

   • Välj Inställningar för att konfigurera kvarhållningsprinciper för körningar, artefakter, symboler, bifogade filer och pull-begäranden.
   • Välj Versionsbevarande för att konfigurera dina kvarhållningsprinciper för versioner och konfigurera när du vill ta bort eller permanent förstöra versioner.
   • Välj Kvarhållning för att konfigurera hur länge manuella och automatiserade testkörningar ska hållas.

   

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.

1. Gå till fliken Inställningar i projektets inställningar.

2. Välj Inställningar i avsnittet Pipelines.

   • Ange antalet dagar för att behålla artefakter, symboler och bifogade filer.
   • Ange hur många dagar som körningar ska behållas
   • Ange antalet dagar för att behålla pull-begärandekörningar
   • Ange antalet senaste körningar som ska behållas för varje pipeline

Varning

Azure DevOps stöder inte längre kvarhållningsregler per pipeline. Det enda sättet att konfigurera kvarhållningsprinciper för YAML och klassiska pipelines är genom de projektinställningar som beskrivs ovan. Du kan inte längre konfigurera kvarhållningsprinciper per pipeline.

Inställningen för antalet senaste körningar som ska behållas för varje pipeline kräver lite mer förklaring. Tolkningen av den här inställningen varierar beroende på vilken typ av lagringsplats du skapar i din pipeline.

• Azure Repos: Azure Pipelines behåller det konfigurerade antalet senaste körningar för pipelinens standardgren och för varje skyddad gren av lagringsplatsen. En gren som har några konfigurerade grenprinciper anses vara en skyddad gren.

  Tänk dig till exempel en lagringsplats med två grenar main och release. Anta att pipeline's default branch är grenen main och att grenen release har en grenprincip, vilket gör den till en skyddad gren. Om du i det här fallet har konfigurerat principen för att behålla tre körningar behålls både de tre senaste körningarna av main och de senaste tre körningarna av grenen release . Dessutom behålls även de tre senaste körningarna av den här pipelinen (oavsett gren).

  För att ytterligare förtydliga den här logiken kan vi säga att listan över körningar för den här pipelinen är följande, med den senaste körningen överst. Tabellen visar vilka körningar som ska behållas om du har konfigurerat att behålla de tre senaste körningarna (ignorera effekten av inställningen antal dagar):

  Springa #	Filial	Behålls/behålls inte	Varför?
  Kör 10	main	Behållit	Senaste 3 för huvud- och senaste 3 för pipeline
  Kör 9	branch1	Behållit	Senaste 3 för pipeline
  Kör 8	branch2	Behållit	Senaste 3 för pipeline
  Kör 7	main	Behållit	Senaste 3 för main
  Kör 6	main	Behållit	Senaste 3 för main
  Kör 5	main	Behålls inte	Varken senaste 3 för main eller pipeline
  Kör 4	main	Behålls inte	Varken senaste 3 för main eller pipeline
  Kör 3	branch1	Behålls inte	Varken senaste 3 för main eller pipeline
  Kör 2	släppa	Behållit	Senaste 3 för lansering
  Kör 1	main	Behålls inte	Varken senaste 3 för main eller pipeline

• Alla andra Git-lagringsplatser: Azure Pipelines behåller det konfigurerade antalet senaste körningar för hela pipelinen.

• TFVC: Azure Pipelines behåller det konfigurerade antalet senaste körningar för hela pipelinen, oavsett gren.

Vilka delar av körningen tas bort

Följande information tas bort när en körning tas bort:

• Loggar
• Alla pipeline- och byggartefakter
• Alla symboler
• Binärfiler
• Testresultat
• Köra metadata
• Källetiketter (TFVC) eller taggar (Git)

Universella paket, NuGet, npm och andra paket är inte knutna till kvarhållning av pipelines.

När tas körningar bort

Kvarhållningsprinciperna bearbetas en gång om dagen. Den tid då principerna får bearbetade variabler eftersom vi sprider arbetet under dagen i belastningsutjämningssyfte. Det finns inget alternativ för att ändra den här processen.

En körning tas bort om alla följande villkor är uppfyllda:

• Det överskrider antalet dagar som konfigurerats i kvarhållningsinställningarna
• Det är inte en av de senaste körningarna som konfigurerats i kvarhållningsinställningarna
• Den är inte markerad för att behållas på obestämd tid
• Den behålls inte av en version

Ange automatiskt kvarhållningslån för pipelinekörningar

Kvarhållningslån används för att hantera livslängden för pipelinekörningar utöver de konfigurerade kvarhållningsperioderna. Kvarhållningslån kan läggas till eller tas bort på en pipelinekörning genom att anropa lease-API:et. Det här API:et kan anropas i pipelinen med hjälp av ett skript och använda fördefinierade variabler för runId och definitionId.

Ett kvarhållningslån kan läggas till på en pipelinekörning under en viss period. En pipelinekörning som distribueras till en testmiljö kan till exempel behållas under en kortare tid medan en körning som distribueras till produktionsmiljön kan behållas längre.

Ange kvarhållningslån manuellt för pipelinekörningar

Du kan ange att en pipelinekörning ska behållas manuellt med hjälp av menyn Fler åtgärder på sidan Information om pipelinekörning.

Ta bort en körning

Du kan ta bort körningar med menyn Fler åtgärder på sidan Information om pipelinekörning.

Kommentar

Om några kvarhållningsprinciper för närvarande gäller för körningen måste de tas bort innan körningen kan tas bort. Anvisningar finns i Information om pipelinekörning – ta bort en körning.

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 .

Kvarhållningsprincipen för YAML- och bygg-pipelines är densamma. Du kan se din pipelines kvarhållningsinställningar i Projektinställningar för pipelines i avsnittet Inställningar .

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.

Använd aktiviteten Kopiera filer för att spara data längre

Du kan använda aktiviteten Kopiera filer för att spara bygg- och artefaktdata längre än vad som anges i kvarhållningsprinciperna. Aktiviteten Kopiera filer är att föredra framför aktiviteten Publicera byggartefakter eftersom data som sparats med aktiviteten Publicera byggartefakter rensas regelbundet och tas bort.

YAML

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

Klassisk

1. Lägg till aktiviteten Kopiera filer i pipelinen.

2. Konfigurera aktiviteten Kopiera filer.

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.

Hur gör jag för att bevara mina etiketter eller taggar för versionskontroll?

Varning

Alla versionskontrolletiketter eller taggar som tillämpas under en bygg-pipeline som inte skapas automatiskt från aktiviteten Källor bevaras, även om bygget tas bort. Alla etiketter eller taggar för versionskontroll som skapas automatiskt från aktiviteten Sources under kompileringen betraktas dock som en del av byggartefakterna och tas bort när bygget tas bort.

Om etiketter eller taggar för versionskontroll måste bevaras, även när bygget tas bort, måste de antingen tillämpas som en del av en aktivitet i pipelinen, manuellt märkta utanför pipelinen, eller så måste bygget bevaras på obestämd tid.

Vad händer med pipelines som används i andra pipelines?

Klassiska versioner behåller pipelines som de använder automatiskt.

Relaterade artiklar

• Kontrollera hur länge testresultaten ska behållas
• Ta bort testartefakter