Ustawianie zasad przechowywania dla kompilacji, wydań i testów

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Zasady przechowywania umożliwiają ustawienie czasu utrzymywania przebiegów, wydań i testów przechowywanych w systemie. Aby zaoszczędzić miejsce do magazynowania, chcesz usunąć starsze przebiegi, testy i wydania.

Następujące zasady przechowywania są dostępne w usłudze Azure DevOps w ustawieniach projektu:

1. Potok — określa czas przechowywania artefaktów, symboli, załączników, przebiegów i przebiegów żądań ściągnięcia.
2. Wydanie (wersja klasyczna) — określ, czy mają być zapisywane kompilacje, i wyświetlać domyślne i maksymalne ustawienia przechowywania.
3. Test — określ, jak długo zachować przebiegi testów automatycznych i ręcznych, wyniki i załączniki.

Uwaga

Jeśli używasz serwera lokalnego, możesz również określić domyślne ustawienia zasad przechowywania dla projektu i kiedy wydania zostaną trwale zniszczone. Dowiedz się więcej o przechowywaniu wersji w dalszej części tego artykułu.

Wymagania wstępne

Domyślnie członkowie grup Współautorzy, Administratorzy kompilacji, Administratorzy projektu i Administratorzy wydania mogą zarządzać zasadami przechowywania.

Aby zarządzać zasadami przechowywania, musisz mieć jedną z następujących subskrypcji:

• Przedsiębiorstwo
• Test Professional
• Platformy MSDN

Możesz również kupić miesięczny dostęp do oferty Azure Test Plans i przypisać poziom dostępu Basic + Test Plans. Zobacz temat Testowanie dostępu według roli użytkownika.

Konfigurowanie zasad przechowywania

1. Zaloguj się do projektu.

2. Przejdź do karty Ustawienia ustawień projektu.

3. Wybierz pozycję Ustawienia lub Przechowywanie wersji w obszarze Potoki lub Przechowywanie w obszarze Test.

   • Wybierz pozycję Ustawienia , aby skonfigurować zasady przechowywania dla przebiegów, artefaktów, symboli, załączników i przebiegów żądań ściągnięcia.
   • Wybierz pozycję Przechowywanie wersji, aby skonfigurować zasady przechowywania wersji i skonfigurować, kiedy usunąć lub trwale zniszczyć wydania.
   • Wybierz pozycję Przechowywanie , aby skonfigurować czas przechowywania przebiegów testów ręcznych i automatycznych.

   

Ustawianie zasad przechowywania przebiegów

W większości przypadków nie trzeba zachowywać ukończonych przebiegów dłużej niż określona liczba dni. Korzystając z zasad przechowywania, możesz kontrolować liczbę dni , przez które chcesz zachować każdy przebieg przed jego usunięciem.

1. Przejdź do karty Ustawienia ustawień projektu.

2. Wybierz pozycję Ustawienia w sekcji Potoki.

   • Ustaw liczbę dni, aby zachować artefakty, symbole i załączniki.
   • Ustawianie liczby dni przechowywania przebiegów
   • Ustawianie liczby dni przechowywania przebiegów żądań ściągnięcia
   • Ustawianie liczby ostatnich przebiegów do zachowania dla każdego potoku

Ostrzeżenie

Usługa Azure DevOps nie obsługuje już reguł przechowywania potoku. Jedynym sposobem skonfigurowania zasad przechowywania dla potoków YAML i klasycznych jest sposób użycia ustawień projektu opisanych powyżej. Nie można już skonfigurować zasad przechowywania potoku.

Ustawienie liczby ostatnich przebiegów do zachowania dla każdego potoku wymaga nieco więcej wyjaśnień. Interpretacja tego ustawienia różni się w zależności od typu repozytorium utworzonego w potoku.

• Azure Repos: usługa Azure Pipelines zachowuje skonfigurowaną liczbę najnowszych uruchomień dla domyślnej gałęzi potoku i dla każdej chronionej gałęzi repozytorium. Gałąź, która ma skonfigurowane zasady gałęzi, jest uważana za gałąź chronioną.

  Rozważmy na przykład repozytorium z dwoma gałęziami main i release. Wyobraź sobie, że pipeline's default branch main gałąź jest gałęzią, a release gałąź ma zasady gałęzi, co czyni ją chronioną gałęzią. W takim przypadku, jeśli skonfigurowano zasady do przechowywania trzech uruchomień, zostaną zachowane oba trzy ostatnie uruchomienia i ostatnie trzy uruchomienia main release gałęzi. Ponadto zachowywane są również trzy ostatnie uruchomienia tego potoku (niezależnie od gałęzi).

  Aby dokładniej wyjaśnić tę logikę, załóżmy, że lista przebiegów dla tego potoku jest następująca, z najnowszym uruchomieniem u góry. W tabeli przedstawiono przebiegi, które zostaną zachowane, jeśli skonfigurowano zachowanie najnowszych trzech przebiegów (ignorując efekt ustawienia liczby dni):

  Biegać #	Oddział	Zachowane/nieutrzymne	Dlaczego?
  Uruchom 10	main	Zachowywane	Najnowsze 3 dla potoku głównego i najnowszego 3
  Uruchamianie 9	branch1	Zachowywane	Najnowsze 3 dla potoku
  Uruchamianie 8	branch2	Zachowywane	Najnowsze 3 dla potoku
  Uruchamianie 7	main	Zachowywane	Najnowsze 3 dla głównej wersji
  Uruchamianie 6	main	Zachowywane	Najnowsze 3 dla głównej wersji
  Uruchom 5	main	Nie zachowano	Ani najnowsze 3 dla serwera głównego, ani potoku
  Uruchom 4	main	Nie zachowano	Ani najnowsze 3 dla serwera głównego, ani potoku
  Uruchom 3	branch1	Nie zachowano	Ani najnowsze 3 dla serwera głównego, ani potoku
  Przebieg 2	zwolnić	Zachowywane	Najnowsza 3 wersja
  Przebieg 1	main	Nie zachowano	Ani najnowsze 3 dla serwera głównego, ani potoku

• Wszystkie inne repozytoria Git: usługa Azure Pipelines zachowuje skonfigurowaną liczbę najnowszych przebiegów dla całego potoku.

• TfVC: usługa Azure Pipelines zachowuje skonfigurowaną liczbę najnowszych przebiegów dla całego potoku, niezależnie od gałęzi.

Jakie części przebiegu zostaną usunięte

Następujące informacje są usuwane po usunięciu przebiegu:

• Dzienniki
• Wszystkie artefakty potoku i kompilacji
• Wszystkie symbole
• Pliki binarne
• Wyniki testu
• Uruchamianie metadanych
• Etykiety źródłowe (TFVC) lub tagi (Git)

Pakiety uniwersalne, NuGet, npm i inne pakiety nie są powiązane z przechowywaniem potoków.

Po usunięciu przebiegów

Zasady przechowywania są przetwarzane raz dziennie. Czas przetwarzania zmiennych przez zasady, ponieważ rozkładamy pracę przez cały dzień na potrzeby równoważenia obciążenia. Nie ma możliwości zmiany tego procesu.

Przebieg zostanie usunięty, jeśli spełnione są wszystkie następujące warunki:

• Przekracza on liczbę dni skonfigurowanych w ustawieniach przechowywania
• Nie jest to jeden z ostatnich przebiegów skonfigurowanych w ustawieniach przechowywania
• Nie jest on oznaczony jako zachowany na czas nieokreślony
• Nie jest on zachowywany przez wydanie

Automatyczne ustawianie dzierżawy przechowywania w uruchomieniach potoków

Dzierżawy przechowywania są używane do zarządzania okresem istnienia potoku wykracza poza skonfigurowane okresy przechowywania. Dzierżawy przechowywania można dodawać lub usuwać w przebiegu potoku , wywołując interfejs API dzierżawy. Ten interfejs API można wywołać w potoku przy użyciu skryptu i używać wstępnie zdefiniowanych zmiennych dla identyfikatorów runId i definitionId.

Dzierżawę przechowywania można dodać do uruchomienia potoku przez określony okres. Na przykład uruchomienie potoku, które jest wdrażane w środowisku testowym, może być przechowywane przez krótszy czas, podczas gdy uruchomienie wdrożenia w środowisku produkcyjnym może być przechowywane dłużej.

Ręczne ustawianie dzierżawy przechowywania w uruchomieniach potoku

Możesz ręcznie ustawić przebieg potoku do zachowania przy użyciu menu Więcej akcji na stronie Szczegóły przebiegu potoku.

Usuwanie przebiegu

Uruchomienia można usunąć, korzystając z menu Więcej akcji na stronie Szczegóły przebiegu potoku.

Uwaga

Jeśli jakiekolwiek zasady przechowywania mają obecnie zastosowanie do przebiegu, należy je usunąć przed usunięciem przebiegu. Aby uzyskać instrukcje, zobacz Szczegóły przebiegu potoku — usuwanie przebiegu.

Ustawianie zasad przechowywania wersji

Zasady przechowywania wersji dla klasycznego potoku wydania określają, jak długo jest przechowywana wersja i połączony z nim przebieg. Korzystając z tych zasad, możesz kontrolować , ile dni chcesz zachować każdą wersję po ostatniej modyfikacji lub wdrożeniu, oraz minimalną liczbę wydań , które powinny być przechowywane dla każdego potoku.

Czasomierz przechowywania w wydaniu jest resetowany za każdym razem, gdy wydanie jest modyfikowane lub wdrażane na etapie. Minimalna liczba wersji do zachowania ustawienia ma pierwszeństwo w ciągu liczby dni. Jeśli na przykład określisz, że zachowasz co najmniej trzy wersje, najnowsze trzy zostaną zachowane na czas nieokreślony — niezależnie od określonej liczby dni. Można jednak ręcznie usunąć te wersje, gdy nie są już potrzebne. Zobacz często zadawane pytania poniżej, aby uzyskać więcej informacji na temat sposobu działania przechowywania wersji.

Jako autor potoku wydania możesz dostosować zasady przechowywania dla wydań potoku na karcie Przechowywanie .

Zasady przechowywania dla potoków YAML i kompilacji są takie same. Ustawienia przechowywania potoku można wyświetlić w sekcji Ustawienia projektu dla potoków.

Globalne zasady przechowywania wersji

Jeśli używasz lokalnego serwera Team Foundation Server lub serwera Azure DevOps Server, możesz określić domyślne i maksymalne wartości zasad przechowywania wydania dla projektu. Można również określić, kiedy wydania zostaną trwale zniszczone (usunięte z karty Usunięte w Eksploratorze kompilacji).

Jeśli używasz usług Azure DevOps Services, możesz wyświetlić te ustawienia, ale nie zmienić tych ustawień dla projektu.

Ustawienia globalnych zasad przechowywania wersji można przeglądać w ustawieniach przechowywania wersji projektu:

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

Zasady maksymalnego przechowywania określają górny limit czasu przechowywania wydań dla wszystkich potoków wydania. Autorzy potoków wydania nie mogą konfigurować ustawień dla ich definicji poza wartościami określonymi tutaj.

Domyślne zasady przechowywania ustawiają domyślne wartości przechowywania dla wszystkich potoków wydania. Autorzy potoków kompilacji mogą zastąpić te wartości.

Zasady niszczenia pomagają zachować wydania przez określony czas po ich usunięciu. Tych zasad nie można zastąpić w poszczególnych potokach wydania.

Użyj zadania Kopiowania plików, aby dłużej zapisywać dane

Możesz użyć zadania Kopiowanie plików, aby zapisać dane kompilacji i artefaktu dłużej niż to, co zostało ustawione w zasadach przechowywania. Zadanie Kopiuj pliki jest preferowane w zadaniu Publikowanie artefaktów kompilacji, ponieważ dane zapisane za pomocą zadania Publikuj artefakty kompilacji będą okresowo czyszczone i usuwane.

YAML

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

Klasyczny

1. Dodaj zadanie Kopiuj pliki do potoku.

2. Skonfiguruj zadanie Kopiuj pliki.

Często zadawane pytania

Czy jeśli oznaczę przebieg lub wydanie do zachowania na czas nieokreślony, czy zasady przechowywania nadal mają zastosowanie?

L.p. Ani zasady przechowywania potoku, ani maksymalne limity ustawione przez administratora nie są stosowane po oznaczeniu pojedynczego uruchomienia lub wydania do zachowania na czas nieokreślony. Pozostanie ona do czasu zatrzymania jego przechowywania na czas nieokreślony.

Jak mogę określić, że przebiegi wdrożone w środowisku produkcyjnym będą przechowywane dłużej?

Jeśli używasz wersji klasycznych do wdrażania w środowisku produkcyjnym, dostosuj zasady przechowywania w potoku wydania. Określ liczbę dni, przez które wydania wdrożone w środowisku produkcyjnym muszą być zachowywane. Ponadto należy wskazać, że uruchomienia skojarzone z tą wersją mają być zachowywane. Spowoduje to zastąpienie zasad przechowywania przebiegów.

Jeśli używasz wieloetapowych potoków YAML do wdrożenia w środowisku produkcyjnym, jedynymi zasadami przechowywania, które można skonfigurować, są ustawienia projektu. Nie można dostosować przechowywania na podstawie środowiska, w którym wdrożono kompilację.

Nie oznaczyłem przebiegów do zachowania na czas nieokreślony. Widzę jednak dużą liczbę przebiegów zachowywanych. Jak temu zapobiec?

Może to być z jednego z następujących powodów:

• Przebiegi są oznaczone przez osobę w projekcie, która ma zostać zachowana na czas nieokreślony.
• Uruchomienia są używane przez wydanie, a wydanie przechowuje blokadę przechowywania tych przebiegów. Dostosuj zasady przechowywania wersji zgodnie z powyższym wyjaśnieniem.

Jeśli uważasz, że przebiegi nie są już potrzebne lub jeśli wydania zostały już usunięte, możesz ręcznie usunąć przebiegi.

Jak działa ustawienie "minimalne wydania do utrzymania"?

Minimalne wersje, które mają być zachowywane, są definiowane na poziomie etapu. Oznacza to, że usługa Azure DevOps będzie zawsze przechowywać daną liczbę ostatnio wdrożonych wersji na etapie, nawet jeśli wersje nie są przechowywane. Wydanie będzie brane pod uwagę w ramach minimalnych wersji, aby zachować etap tylko wtedy, gdy wdrożenie rozpoczęło się na tym etapie. Rozważane są wdrożenia zakończone powodzeniem i niepowodzeniem. Wydania oczekujące na zatwierdzenie nie są brane pod uwagę.

W jaki sposób okres przechowywania jest ustalany, gdy wydanie jest wdrażane na wielu etapach o różnym okresie przechowywania?

Ostateczny okres przechowywania jest ustalany przez rozważenie dni przechowywania ustawień wszystkich etapów, na których jest wdrażana wersja, i trwa maksymalnie kilka dni, aby zachować między nimi. Minimalne wersje do utrzymania są zarządzane na poziomie etapu i nie zmieniają się na podstawie wersji wdrożonej na wielu etapach lub nie. Zachowanie skojarzonych artefaktów będzie stosowane, gdy wydanie zostanie wdrożone na etapie, dla którego ustawiono wartość true.

Usunięto etap, dla którego mam stare wersje. Jakie przechowywanie będzie brane pod uwagę w tym przypadku?

Po usunięciu etapu ustawienia przechowywania na poziomie etapu nie mają teraz zastosowania. Usługa Azure DevOps powróci do domyślnego przechowywania na poziomie projektu w takim przypadku.

Moja organizacja wymaga zachowania kompilacji i wydań dłużej niż to, co jest dozwolone w ustawieniach. Jak mogę przedłużyć okres przechowywania?

Jedynym sposobem zachowania przebiegu lub wydania dłuższego niż to, co jest dozwolone za pomocą ustawień przechowywania, jest ręczne oznaczenie go do przechowywania na czas nieokreślony. Nie ma możliwości ręcznego skonfigurowania ustawienia dłuższego przechowywania. Skontaktuj się z pomocą techniczną usługi Azure DevOps, aby uzyskać pomoc.

Możesz również zapoznać się z możliwością używania interfejsów API REST w celu pobrania informacji i artefaktów dotyczących przebiegów oraz przekazania ich do własnego magazynu lub repozytorium artefaktów.

Straciłem kilka przebiegów. Czy istnieje sposób, aby je odzyskać?

Jeśli uważasz, że utracono przebiegi z powodu usterki w usłudze, utwórz bilet pomocy technicznej natychmiast, aby odzyskać utracone informacje. Jeśli definicja kompilacji została ręcznie usunięta ponad tydzień wcześniej, nie będzie można go odzyskać. Jeśli przebiegi zostały usunięte zgodnie z oczekiwaniami z powodu zasad przechowywania, nie będzie możliwe odzyskanie utraconych przebiegów.

Jak mogę korzystać z Build.Cleanup możliwości agentów?

Build.Cleanup Ustawienie możliwości agentów spowoduje, że zadania oczyszczania puli będą kierowane tylko do tych agentów, pozostawiając resztę bezpłatną do regularnej pracy. Po usunięciu przebiegu potoku artefakty przechowywane poza usługą Azure DevOps są czyszczone za pośrednictwem zadania uruchomionego na agentach. Gdy pula agentów zostanie nasycony zadaniami oczyszczania, może to spowodować problem. Rozwiązaniem jest wyznaczenie podzbioru agentów w puli, które są agentami oczyszczania. Jeśli jakikolwiek agent ma Build.Cleanup ustawiony, tylko ci agenci będą uruchamiać zadania oczyszczania, pozostawiając pozostałych agentów wolnych do kontynuowania uruchamiania zadań potoku. Funkcję Oczyszczania można włączyć, przechodząc do opcji Możliwości agenta>i ustawiając Build.Cleanup wartość równą 1.

Co się stanie z udziałem plików Artefakty po usunięciu kompilacji

Gdy kompilacja z udziałem plików Artifacts zostanie usunięta, nowe zadanie kompilacji jest w kolejce na agencie kompilacji w celu oczyszczenia tych plików. Agent jest wybierany do wykonania tego zadania na podstawie następujących kryteriów: Czy istnieje agent z dostępną Build.Cleanup możliwością? Czy agent, który uruchomił kompilację, jest dostępny? Czy agent z tej samej puli jest dostępny? Czy agent z podobnej puli jest dostępny? Czy jakikolwiek agent jest dostępny?

Czy wyniki testów automatycznych, które są publikowane w ramach wydania, są zachowywane do momentu usunięcia wydania?

Wyniki testów opublikowane na etapie wydania są zachowywane zgodnie z zasadami przechowywania skonfigurowanymi dla wyników testu. Wyniki testów nie są zachowywane, dopóki wydanie nie zostanie zachowane. Jeśli potrzebujesz wyników testu, o ile wydanie, ustaw ustawienia przechowywania dla przebiegów testów automatycznych w ustawieniach projektu odpowiednio na Wartość Nigdy nie usuwaj. Dzięki temu wyniki testu są usuwane tylko wtedy, gdy wydanie zostanie usunięte.

Czy wyniki testów ręcznych są usuwane?

L.p. Wyniki testów ręcznych nie są usuwane.

Jak mogę zachować etykiety lub tagi kontroli wersji?

Uwaga

Wszystkie etykiety kontroli wersji lub tagi stosowane podczas potoku kompilacji, które nie są automatycznie tworzone z zadania Źródła, zostaną zachowane, nawet jeśli kompilacja zostanie usunięta. Jednak etykiety lub tagi kontroli wersji, które są automatycznie tworzone z zadania Źródła podczas kompilacji, są traktowane jako część artefaktów kompilacji i zostaną usunięte po usunięciu kompilacji.

Jeśli potrzeba zachować etykiety lub tagi kontroli wersji nawet po usunięciu kompilacji, należy zastosować je w ramach zadania w potoku, ręcznie oznaczyć poza potokiem lub przechowywać kompilację przez czas nieokreślony.

Co się stanie z potokami, które są używane w innych potokach?

Wersje klasyczne zachowują potoki, z których korzystają automatycznie.

Powiązane artykuły

• Kontrolowanie czasu przechowywania wyników testów
• Usuwanie artefaktów testowych