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

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

Zasady przechowywania umożliwiają określenie czasu przechowywania przebiegów, wydań i testów w systemie. Aby zaoszczędzić przestrzeń dyskową, chcesz usunąć starsze przebiegi, testy i wydania.

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

1. Pipeline — Ustawić, jak długo przechowywać artefakty, symbole, załączniki, wykonania i przebiegi żą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 zachowywaniu 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 Ustawienia lub Przechowywanie wersji w obszarze Potoki lub Przechowywanie wersji w obszarze Test.

   • Wybierz pozycję Ustawienia, aby skonfigurować polityki przechowywania dla przebiegów, artefaktów, symboli, załączników i przebiegów pull requestów.
   • 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.

   

Ustaw zasady przechowywania przebiegów

W większości przypadków nie ma potrzeby przechowywania ukończonych przebiegów dłużej niż przez określoną liczbę dni. Korzystając z zasad przechowywania, możesz kontrolować liczbę dni przez które chcesz przechowywać dane dotyczące każdego przebiegu 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
   • Ustaw liczbę ostatnich przebiegów do zachowania dla każdego potoku

Ostrzeżenie

Usługa Azure DevOps nie obsługuje już reguł przechowywania na poziomie poszczególnych potoków. 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 dla poszczególnych potoków.

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 ramach pipeline'u.

• Azure Repos: usługa Azure Pipelines zachowuje skonfigurowaną liczbę najnowszych uruchomień dla domyślnej gałęzi potoku oraz 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 jest gałęzią, a gałąź main jest gałęzią, a gałąź release ma politykę dla gałęzi, co czyni ją chronioną gałęzią. W takim przypadku, jeśli skonfigurowano zasady do przechowywania trzech uruchomień, to zostaną zachowane trzy ostatnie uruchomienia <%0 /> oraz trzy ostatnie uruchomienia <%1 /> 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/nieutrzymane	Dlaczego?
  Uruchom 10	główny	Zachowywane	Najnowsze 3 dla głównego i najnowsze 3 dla potoku
  Bieg 9	oddział1	Zachowywane	Najnowsze 3 dla potoku
  Uruchom 8	Oddział2	Zachowywane	Najnowsze 3 dla potoku
  Bieg 7	główny	Zachowywane	Najnowsze 3 dla głównej wersji
  Uruchamianie 6	główny	Zachowywane	Najnowsze 3 dla głównej wersji
  Uruchom 5	główny	Nie zachowano	Ani najnowsze 3 dla gałęzi głównej, ani dla ciągu przetwarzania.
  Run 4	główny	Nie zachowano	Ani najnowsze 3 dla serwera głównego, ani potoku
  Run 3	oddział1	Nie zachowano	Ani najnowsze 3 dla głównego, ani dla potoku
  Przebieg 2	uwolnić	Zachowywane	Najnowsza wersja 3 do wydania
  Przebieg 1	główny	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 w przypadku usunięcia przebiegu:

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

Pakiety uniwersalne, takie jak NuGet, npm i inne, nie są powiązane z retencją potoków.

Kiedy są usuwane przebiegi

Zasady przechowywania są przetwarzane raz dziennie. Czas, jaki zajmuje przetwarzanie polis, jest zmienny, ponieważ rozkładamy pracę na cały dzień w celu 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 najnowszych uruchomień skonfigurowanych w ustawieniach przechowywania
• Nie jest on oznaczony jako zachowany na czas nieokreślony
• Nie jest on zatrzymywany przez zwolnienie

Automatyczne ustawianie dzierżawy przechowywania w uruchomieniach potoków

Dzierżawy przechowywania są używane do zarządzania czasem trwania sesji przetwarzania, który wykracza poza skonfigurowane okresy retencji. Umowy zatrzymania można dodawać lub usuwać podczas uruchamiania potoku, wywołując API umów zatrzymania. Ten interfejs API można wywołać w potoku za pomocą skryptu i używać wstępnie zdefiniowanych zmiennych 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 polityki 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.

Usuń przebieg

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

Uwaga

Jeśli obecnie do przebiegu stosują się jakieś zasady przechowywania, muszą zostać usunięte przed skasowaniem przebiegu. Aby uzyskać instrukcje, zobacz Szczegóły przebiegu potoku — usunąć przebieg.

Zespół produktu aktywnie pracuje nad skracaniem czasu usuwania danych. W przypadku usuwania danych mogą wystąpić wielodniowe opóźnienia przetwarzania, jeśli z Twoim hostem jest skojarzonych wiele punktów testowych.

Ustawianie zasad przechowywania wersji

Zasady utrzymania wersji dla klasycznego potoku wersji określają, jak długo wersja oraz przebieg z nią powiązany są przechowywane. 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 możesz dostosować polityki przechowywania dla wydań potoku na zakładce 'Przechowywanie'.

Zasada przechowywania dla potoków YAML i kompilacji jest taka sama. Możesz zobaczyć ustawienia przechowywania potoku w Ustawieniach Projektu dla Potoków w sekcji Ustawienia.

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
• Na miejscu: https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub

Polityka maksymalnego przechowywania określa maksymalny czas przechowywania wydań dla wszystkich potoków publikacji. Autorzy potoków wydania nie mogą konfigurować ustawień dla ich definicji poza wartościami określonymi tutaj.

Domyślna polityka przechowywania ustala domyślne wartości przechowywania dla wszystkich pipeline'ów wydań. Autorzy potoków kompilacji mogą zastąpić te wartości.

Polityka niszczenia pomaga 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 artefaktów na dłużej niż ustawiono w zasadach przechowywania. Zadanie Kopiuj pliki jest preferowane od zadania Publikowanie artefaktów kompilacji, ponieważ dane zapisane za pomocą zadania Publikowanie artefaktów 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 Kopiowania Plików do potoku danych.

2. Skonfiguruj zadanie Kopiuj pliki.

Często zadawane pytania

Czy jeśli oznaczę przebieg lub wydanie do zachowania na czas nieokreślony, zasady przechowywania wciąż obowiązują?

Nr. Ani polityka przechowywania potoku, ani maksymalne limity ustanowione przez administratora nie są stosowane, kiedy oznaczysz pojedyncze uruchomienie lub wydanie do zachowania na czas nieokreślony. Pozostanie to do czasu, aż przestaniesz to przechowywać 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 politykę retencji w potoku wydań. 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, że duża liczba przebiegów jest zachowywana. 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ą konsumowane przez wydanie, a wydanie utrzymuje blokadę zatrzymania na tych uruchomieniach. Dostosuj zasady przechowywania wersji zgodnie z powyższym wyjaśnieniem.

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

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 znajdują się poza okresem przechowywania. 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 ustalany jest okres przechowywania, gdy wydanie jest wdrażane w wielu fazach o różnym okresie przechowywania?

Ostateczny okres przechowywania jest ustalany przez rozważenie dni zachowywania ustawień wszystkich etapów, na których wdrażana jest wersja, i przyjęcie maksymalnej liczby dni do zachowania spośród nich. Minimalne wersje do utrzymania są regulowane na poziomie etapu i nie zmieniają się w zależności od tego, czy wersja jest wdrażana do wielu etapów, czy nie. Zachowanie skojarzonych artefaktów będzie stosowane, gdy wydanie zostanie wdrożone na etapie, dla którego opcja ta jest włączona.

Usunąłem etap, dla którego mam jakieś 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, na co pozwalają ustawienia. Jak mogę przedłużyć okres przechowywania?

Jedynym sposobem zachowania procesu lub wydania dłużej niż pozwalają ustawienia przechowywania jest ręczne oznaczenie go jako przechowywanego 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ż rozważyć użycie interfejsów API REST w celu pobrania informacji oraz artefaktów z przebiegów i przesłania ich do własnego magazynu lub repozytorium artefaktów.

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

Jeśli uważasz, że utraciłeś dane z powodu błędu w usłudze, natychmiast utwórz zgłoszenie pomocy technicznej, 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?

Ustawienie możliwości na agentach spowoduje, że zadania oczyszczania puli będą kierowane tylko do tych agentów, pozostawiając resztę wolną do normalnej 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 nasycona zadaniami oczyszczania, może to powodować problem. Rozwiązaniem jest wyznaczenie podzbioru agentów w puli, którzy są agentami oczyszczania. Jeśli którykolwiek z agentów ma ustawioną wartość Build.Cleanup, tylko ci agenci będą uruchamiać zadania oczyszczania, pozostawiając resztę agentów wolnymi do 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 udostępnionymi plikami 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 jest dostępny agent z tej samej puli? 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 testów przez cały czas trwania wydania, ustaw ustawienia przechowywania dla automatycznych przebiegów testów w ustawieniach projektu na 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?

Nr 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 przez zadanie ź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ę dzieje z rurami, które są wchłonięte w inne rury?

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

Powiązane artykuły

• Kontrolowanie czasu przechowywania wyników testów
• Usuwanie artefaktów testowych
• Korzystanie z zadań do zachowywania wyników działania w usłudze Azure Pipelines