Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests

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

Mit Aufbewahrungsrichtlinien können Sie festlegen, wie lange Ausführungen, Releases und Tests im System gespeichert bleiben sollen. Um Speicherplatz zu sparen, möchten Sie ältere Ausführungen, Tests und Releases löschen.

In Azure DevOps sind in Ihren Projekteinstellungen die folgenden Aufbewahrungsrichtlinien verfügbar:

1. Pipeline: Legen Sie fest, wie lange Artefakte, Symbole, Anlagen, Ausführungen und Pull Request-Ausführungen aufbewahrt werden sollen.
2. Release (klassisch): Legen Sie fest, ob Builds gespeichert werden sollen, und sehen Sie sich die Standard- und maximalen Aufbewahrungseinstellungen an.
3. Test: Legen Sie fest, wie lange automatisierte und manuelle Testläufe, Ergebnisse und Anlagen aufbewahrt werden sollen.

Hinweis

Wenn Sie einen lokalen Server verwenden, können Sie auch Standardeinstellungen für Aufbewahrungsrichtlinien für ein Projekt angeben und festlegen, wann Releases endgültig gelöscht (bzw. zerstört) werden. Weitere Informationen zur Aufbewahrung von Releases finden Sie weiter unten in diesem Artikel.

Voraussetzungen

Standardmäßig können Mitglieder der Gruppen „Mitwirkende“, „Buildadministratoren“, „Projektadministratoren“ und „Releaseadministratoren“ Aufbewahrungsrichtlinien verwalten.

Um Aufbewahrungsrichtlinien zu verwalten, benötigen Sie eines der folgenden Abonnements:

• Enterprise
• Test Professional
• MSDN-Plattformen

Sie können auch monatlichen Zugriff auf Azure Test Plans erwerben und die Zugriffsebene Basic + Test Plans zuweisen. Weitere Informationen finden Sie unter Testen des Zugriffs nach Benutzerrolle.

Konfigurieren von Aufbewahrungsrichtlinien

1. Melden Sie sich bei Ihrem Projekt an.

2. Wechseln Sie in den Einstellungen Ihres Projekts zur Registerkarte Einstellungen.

3. Wählen Sie Einstellungen oder Releaseaufbewahrung unter Pipelines oder Aufbewahrung unter Test aus.

   • Wählen Sie Einstellungen aus, um Aufbewahrungsrichtlinien für Ausführungen, Artefakte, Symbole, Anlagen und Pull Request-Ausführungen zu konfigurieren.
   • Wählen Sie Releaseaufbewahrung aus, um Ihre Aufbewahrungsrichtlinien für Releases einzurichten und zu konfigurieren, wann Releases gelöscht bzw. zerstört werden sollen.
   • Wählen Sie Aufbewahrung aus, um festzulegen, wie lange manuelle und automatisierte Testläufe aufbewahrt werden sollen.

   

Festlegen von Aufbewahrungsrichtlinien für Ausführungen

In den meisten Fällen müssen Sie abgeschlossene Ausführungen nicht länger als eine bestimmte Anzahl von Tagen aufbewahren. Mithilfe von Aufbewahrungsrichtlinien können Sie steuern, wie viele Tage Sie jede Ausführung beibehalten möchten, ehe Sie sie löschen.

1. Wechseln Sie in den Einstellungen Ihres Projekts zur Registerkarte Einstellungen.

2. Wählen Sie im Abschnitt „Pipelines“ die Option Einstellungen aus.

   • Legen Sie die Anzahl der Tage fest, die Artefakte, Symbole und Anlagen beibehalten werden sollen.
   • Legen Sie die Anzahl der Tage fest, die Ausführungen beibehalten werden sollen.
   • Legen Sie die Anzahl der Tage fest, die Ausführungen von Pull Requests beibehalten werden sollen.
   • Legen Sie die Anzahl der letzten Ausführungen fest, die für jede Pipeline beibehalten werden sollen.

Warnung

Azure DevOps unterstützt keine pipelinespezifischen Aufbewahrungsregeln mehr. Die einzige Möglichkeit zum Konfigurieren von Aufbewahrungsrichtlinien für YAML- und klassische Pipelines sind die weiter oben beschriebenen Projekteinstellungen. Sie können keine pipelinespezifischen Aufbewahrungsrichtlinien mehr konfigurieren.

Die Einstellung für die Anzahl der letzten Ausführungen, die für jede Pipeline aufbewahrt werden sollen, bedarf einer etwas ausführlicheren Erläuterung. Die Interpretation dieser Einstellung hängt vom Typ des Repositorys ab, das Sie in Ihrer Pipeline erstellen.

• Azure Repos: Azure Pipelines behält die konfigurierte Anzahl der letzten Ausführungen für den Standardbranch der Pipeline und für jeden geschützten Branch des Repositorys bei. Ein Branch, für den Branchrichtlinien konfiguriert sind, gilt als geschützter Branch.

  Nehmen Sie als Beispiel ein Repository mit den beiden Branches main und release. Stellen Sie sich vor, pipeline's default branch ist der Branch main, und für den Branch release gilt eine Branchrichtlinie, die ihn zu einem geschützter Branch macht. Wenn Sie in diesem Fall die Richtlinie so konfiguriert haben, dass drei Ausführungen beibehalten werden, werden sowohl die letzten drei Ausführungen von main als auch die letzten drei Ausführungen des Branches release beibehalten. Darüber hinaus werden die letzten drei Ausführungen dieser Pipeline (unabhängig vom Branch) ebenfalls beibehalten.

  Um diese Logik weiter zu erläutern, nehmen wir an, dass die Liste der Ausführungen für diese Pipeline wie folgt aussieht, wobei die letzte Ausführung an erster Stelle steht. Die Tabelle zeigt, welche Ausführungen beibehalten werden, wenn Ihre Konfiguration vorsieht, dass die letzten drei Ausführungen beibehalten werden (ohne die Auswirkungen der Einstellung für die Anzahl der Tage zu berücksichtigen):

  Nr. der Ausführung	Verzweigung	Beibehalten/Nicht beibehalten	Warum?
  Ausführung 10	Standard	Beibehalten	Die letzten 3 für „main“ und letzten 3 für Pipeline
  Ausführung 9	Branch1	Beibehalten	Die letzten 3 für Pipeline
  Ausführung 8	Branch2	Beibehalten	Die letzten 3 für Pipeline
  Ausführung 7	Standard	Beibehalten	Die letzten 3 für „main“
  Ausführung 6	Standard	Beibehalten	Die letzten 3 für „main“
  Ausführung 5	Standard	Nicht beibehalten	Weder die letzten 3 für „main“ noch für Pipeline
  Ausführung 4	Standard	Nicht beibehalten	Weder die letzten 3 für „main“ noch für Pipeline
  Ausführung 3	Branch1	Nicht beibehalten	Weder die letzten 3 für „main“ noch für Pipeline
  Testlauf 2	Freigabe	Beibehalten	Die letzten 3 für Release
  Ausführung 1	Standard	Nicht beibehalten	Weder die letzten 3 für „main“ noch für Pipeline

• Alle anderen Git-Repositorys: Azure Pipelines behält die konfigurierte Anzahl der letzten Ausführungen für die gesamte Pipeline bei.

• TFVC: Azure Pipelines behält die konfigurierte Anzahl der letzten Ausführungen für die gesamte Pipeline unabhängig vom Branch bei.

Welche Teile der Ausführung werden gelöscht?

Die folgenden Informationen werden beim Löschen einer Ausführung gelöscht:

• Protokolle
• Alle Pipeline- und Buildartefakte
• Alle Symbole
• Binärdateien
• Testergebnisse
• Metadaten der Ausführung
• Quellbezeichnungen (TFVC) oder Tags (Git)

Universelle, NuGet-, npm- und andere Pakete sind nicht an die Aufbewahrung von Pipelines gebunden.

Wann werden Ausführungen gelöscht?

Ihre Aufbewahrungsrichtlinien werden einmal täglich verarbeitet. Der Zeitpunkt, zu dem die Richtlinien verarbeitet werden, variiert, da wir die Verarbeitung zum Zwecke des Lastenausgleichs über den Tag verteilen. Es gibt keine Möglichkeit, diesen Verarbeitungsprozess zu ändern.

Eine Ausführung wird gelöscht, wenn alle der folgenden Bedingungen zutreffen:

• Überschreitet die in den Aufbewahrungseinstellungen konfigurierte Anzahl der Tage
• Es handelt sich entsprechend den konfigurierten Aufbewahrungseinstellungen nicht um eine der letzten Ausführungen
• Ist nicht für eine unbegrenzte Aufbewahrung markiert
• Wird nicht von einem Release aufbewahrt

Automatisches Festlegen von Aufbewahrungsleases für Pipelineausführungen

Aufbewahrungsleases werden verwendet, um die Lebensdauer von Pipelineausführungen über die konfigurierten Aufbewahrungszeiträume hinaus zu verwalten. Aufbewahrungsleases können bei einer Pipelineausführung durch Aufrufen der Lease-API hinzugefügt oder gelöscht werden. Diese API kann innerhalb der Pipeline mithilfe eines Skripts und vordefinierter Variablen für runId und definitionId aufgerufen werden.

Bei einer Pipelineausführung kann für einen bestimmten Zeitraum eine Aufbewahrungslease hinzugefügt werden. Beispielsweise kann eine in einer Testumgebung bereitgestellte Pipelineausführung für eine kürzere Dauer beibehalten werden, während eine Ausführung, die in der Produktionsumgebung bereitgestellt wird, länger beibehalten werden kann.

Manuelles Festlegen von Aufbewahrungsleases für Pipelineausführungen

Sie können im Menü Weitere Aktionen auf der Seite Details zur Pipelineausführung manuell festlegen, dass eine Pipelineausführung beibehalten werden soll.

Löschen einer Ausführung

Sie können Ausführungen im Menü Weitere Aktionen auf der Seite Details zur Pipelineausführung löschen.

Hinweis

Wenn derzeit Aufbewahrungsrichtlinien für die Ausführung gelten, müssen sie entfernt werden, ehe die Ausführung gelöscht werden kann. Anweisungen finden Sie unter Details zur Pipelineausführung: Löschen einer Ausführung.

Festlegen der Aufbewahrungsrichtlinien für Releases

Die Aufbewahrungsrichtlinien für Releases für eine klassische Releasepipeline bestimmen, wie lange ein Release und die damit verknüpfte Ausführung aufbewahrt werden. Mit diesen Richtlinien können Sie die Anzahl der Tage bestimmen, die Sie jedes Release aufbewahren möchten, nachdem es zuletzt geändert oder bereitgestellt wurde, sowie die Mindestanzahl der Releases , die für jede Pipeline aufbewahrt werden sollen.

Der Aufbewahrungszeitgeber für ein Release wird jedes Mal zurückgesetzt, wenn ein Release geändert oder in einer Phase bereitgestellt wird. Die Mindestanzahl aufzubewahrender Releases hat Vorrang vor der Anzahl der Tage. Wenn Sie z. B. angeben, dass mindestens drei Releases aufbewahrt werden sollen, werden die letzten drei auf unbestimmte Zeit aufbewahrt, und zwar unabhängig von der angegebenen Anzahl von Tagen. Sie können diese Releases jedoch manuell löschen, wenn Sie sie nicht mehr benötigen. Weitere Informationen zur Funktionsweise der Releaseaufbewahrung finden Sie weiter unten in den häufig gestellten Fragen.

Als Ersteller einer Releasepipeline können Sie Aufbewahrungsrichtlinien für Releases Ihrer Pipeline auf der Registerkarte Aufbewahrung anpassen.

Die Aufbewahrungsrichtlinie für YAML- und Buildpipelines ist identisch. Die Aufbewahrungseinstellungen Ihrer Pipeline finden Sie in Projekteinstellungen für Pipelines im Abschnitt Einstellungen.

Globale Aufbewahrungsrichtlinie für Releases

Wenn Sie eine lokale Team Foundation Server- oder eine Azure DevOps Server-Instanz nutzen, können Sie für ein Projekt die Standard- und Maximalwerte für die Aufbewahrungsrichtlinie für Releases angeben. Sie können auch angeben, wann Releases dauerhaft zerstört (von der Registerkarte Gelöscht im Build-Explorer entfernt) werden.

Wenn Sie Azure DevOps Services verwenden, können Sie diese Einstellungen für Ihr Projekt zwar anzeigen, aber nicht ändern.

Einstellungen für globale Aufbewahrungsrichtlinien für Releases können in den Einstellungen für die Aufbewahrung von Releases Ihres Projekts überprüft werden:

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

Die Richtlinie für maximale Aufbewahrungsdauer legt die Obergrenze fest, wie lange Releases für alle Releasepipelines aufbewahrt werden können. Ersteller von Releasepipelines können für ihre Definitionen keine Einstellungen konfigurieren, die über die hier angegebenen Werte hinausgehen.

Die Standardaufbewahrungsrichtlinie legt die Standardaufbewahrungsdauer für alle Releasepipelines fest. Ersteller von Buildpipelines können diese Werte überschreiben.

Die Zerstörungsrichtlinie hilft Ihnen dabei, die Releases nach dem Löschen eine bestimmte Zeit lang aufzubewahren. Diese Richtlinie kann nicht in einzelnen Releasepipelines außer Kraft gesetzt werden.

Langfristiges Speichern von Daten mithilfe der Aufgabe „Dateien kopieren“

Sie können mithilfe der Aufgabe Dateien kopieren Ihre Build- und Artefaktdaten länger als in den Aufbewahrungsrichtlinien festgelegt speichern. Die Aufgabe Dateien kopieren ist der Aufgabe Buildartefakte veröffentlichen vorzuziehen, da Daten, die mit der Aufgabe Buildartefakte veröffentlichen gespeichert wurden, regelmäßig bereinigt und gelöscht werden.

YAML

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

Klassisch

1. Fügen Sie Ihre Pipeline die Aufgabe Dateien kopieren hinzu.

2. Konfigurieren Sie die Aufgabe Dateien kopieren.

Häufig gestellte Fragen

Wenn ich eine Ausführung oder ein Release als zeitlich unbegrenzt aufzubewahren markiere, gilt dann die Aufbewahrungsrichtlinie dennoch?

Nein. Weder die Aufbewahrungsrichtlinie der Pipeline noch die vom Administrator festgelegten Obergrenzen gelten, wenn Sie eine einzelne Ausführung oder ein einzelnes Release zur unbefristeten Aufbewahrung markieren. Sie bzw. es bleibt so lange erhalten, bis Sie die unbefristete Aufbewahrung beenden.

Wie kann ich angeben, dass für die Produktion bereitgestellte Ausführungen länger aufbewahrt werden?

Wenn Sie klassische Releases für die Bereitstellung in der Produktion verwenden, passen Sie die Aufbewahrungsrichtlinie für die Releasepipeline an. Geben Sie die Anzahl der Tage an, für die in der Produktion bereitgestellte Releases beibehalten werden müssen. Geben Sie außerdem an, dass Ausführungen, die diesem Release zugeordnet sind, beibehalten werden sollen. Dadurch wird die Aufbewahrungsrichtlinie für Ausführungen außer Kraft gesetzt.

Wenn Sie für die Bereitstellung in der Produktion mehrstufige YAML-Pipelines verwenden, können Sie nur in den Projekteinstellungen eine einzelne Aufbewahrungsrichtlinie konfigurieren. Sie können die Aufbewahrung nicht basierend auf der Umgebung anpassen, in der der Build bereitgestellt wird.

Ich habe keine Ausführungen markiert, die unbefristet beibehalten werden sollen. Ich sehe jedoch, dass eine große Anzahl von Ausführungen beibehalten wird. Wie kann ich dies verhindern?

Dies kann einen der folgenden Gründe haben:

• Die Ausführungen werden von einer Person in Ihrem Projekt so markiert, dass sie unbefristet aufbewahrt werden sollen.
• Die Ausführungen werden von einem Release genutzt, das eine Aufbewahrungssperre für diese Ausführungen aktiviert hat. Passen Sie die Aufbewahrungsrichtlinie für Releases wie oben erläutert an.

Wenn Sie der Meinung sind, dass die Ausführungen nicht mehr benötigt werden oder die Releases bereits gelöscht wurden, können Sie die Ausführungen manuell löschen.

Wie funktioniert die Einstellung „Mindestzahl beizubehaltender Releases“?

Die Mindestanzahl beizubehaltender Releases wird auf Phasenebene definiert. Sie gibt an, dass Azure DevOps stets die angegebene Anzahl der letzten bereitgestellten Releases für eine Phase aufbewahrt, auch wenn der Aufbewahrungszeitraum nicht mehr für die Releases gilt. Ein Release wird nur dann als Mindestrelease für eine Phase betrachtet, wenn die Bereitstellung in dieser Phase begonnen hat. Sowohl erfolgreiche als auch fehlgeschlagene Bereitstellungen werden berücksichtigt. Releases, deren Genehmigung aussteht, werden nicht berücksichtigt.

Wie wird der Aufbewahrungszeitraum festgelegt, wenn das Release in mehreren Phasen mit unterschiedlichen Aufbewahrungszeiträumen bereitgestellt wird?

Der endgültige Aufbewahrungszeitraum wird festgelegt, indem Einstellungen für „Anzahl der Tage, die ein Release beibehalten wird“ für alle Phasen, in denen das Release bereitgestellt wird, berücksichtigt werden und eine maximale Anzahl von Tagen für die Beibehaltung festgelegt wird. Die Mindestzahl beizubehaltender Releases wird auf Phasenebene festgelegt und ändert sich nicht, je nachdem, ob ein Release in mehreren Phasen bereitgestellt wird oder nicht. „Zugeordnete Artefakte beibehalten“ wird wirksam, wenn das Release in einer Phase bereitgestellt wird, für die diese Einstellung zutrifft.

Ich habe eine Phase gelöscht, für die ich einige alte Releases habe. Welche Aufbewahrung erfolgt in diesem Fall?

Da die Phase gelöscht wird, gelten die Aufbewahrungseinstellungen auf Phasenebene jetzt nicht mehr. Azure DevOps wird in diesem Fall auf die Standardaufbewahrung auf Projektebene zurückgesetzt.

Wir müssen in meiner Organisation Builds und Releases länger als in den Einstellungen zulässig aufbewahren. Wie kann ich eine längere Aufbewahrungsdauer anfordern?

Die einzige Möglichkeit, eine Ausführung oder ein Release länger aufzubewahren, als es die Aufbewahrungseinstellungen zulassen, besteht darin, sie bzw. es manuell für unbefristete Aufbewahrung zu markieren. Es gibt keine Möglichkeit, manuell eine längere Aufbewahrungszeit zu konfigurieren. Bitte wenden Sie sich an Azure DevOps Support für Unterstützung.

Sie können auch die Möglichkeit zur Nutzung der REST-APIs erkunden, um Informationen und Artefakte zu den Ausführungen herunterzuladen und sie in Ihr eigenes Speicher- oder Artefaktrepository hochzuladen.

Mir sind einige Ausführungen verloren gegangen. Gibt es eine Möglichkeit, sie zurückzubekommen?

Wenn Sie glauben, dass Sie Ausführungen aufgrund eines Fehlers im Dienst verloren haben, erstellen Sie sofort ein Supportticket, um die verloren gegangenen Informationen wiederherzustellen. Wenn eine Builddefinition vor mehr als einer Woche manuell gelöscht wurde, kann sie nicht wiederhergestellt werden. Wenn die Ausführungen wie erwartet aufgrund einer Aufbewahrungsrichtlinie gelöscht wurden, ist es nicht möglich, die verloren gegangenen Ausführungen wiederherzustellen.

Wie verwende ich die Build.Cleanup-Funktion von Agents?

Das Festlegen einer Build.Cleanup-Funktion für Agents führt dazu, dass die Bereinigungsaufträge des Pools nur zu diesen Agents geleitet werden, sodass die übrigen Agents ihre regulären Aufgaben erledigen können. Wenn eine Pipelineausführung gelöscht wird, werden außerhalb von Azure DevOps gespeicherte Artefakte durch einen Auftrag bereinigt, der auf den Agents ausgeführt wird. Wenn der Agent-Pool mit Bereinigungsaufträgen überlastet ist, kann dies zu einem Problem führen. Die Lösung dafür besteht darin, eine Teilmenge der Agents im Pool festzulegen, die als Bereinigungs-Agents fungieren. Wenn für Agents Build.Cleanup festgelegt wurde, führen nur diese Agents die Bereinigungsaufträge aus, sodass die restlichen Agents weiterhin Pipelineaufträge ausführen können. Die Bereinigungsfunktionalität kann aktiviert werden, indem Sie zu Agent>Funktionen navigieren und Build.Cleanup auf 1 festlegen.

Was geschieht mit Dateifreigabeartefakten, wenn der Build gelöscht wird?

Wenn ein Build mit Dateifreigabeartefakten gelöscht wird, wird eine neue Buildaufgabe auf einem Build-Agent in die Warteschlange gestellt, um diese Dateien zu bereinigen. Ein Agent wird ausgewählt, um diese Aufgabe basierend auf den folgenden Kriterien auszuführen: Ist ein Agent mit Build.Cleanup-Funktionalität verfügbar? Ist der Agent verfügbar, der den Build ausgeführt hat? Ist ein Agent aus demselben Pool verfügbar? Ist ein Agent aus einem ähnlichen Pool verfügbar? Ist überhaupt ein Agent verfügbar?

Werden Ergebnisse automatisierter Tests, die als Teil eines Releases veröffentlicht werden, bis zum Löschen des Releases aufbewahrt?

In einer Phase eines Releases veröffentlichte Testergebnisse werden entsprechend der Aufbewahrungsrichtlinie aufbewahrt, die für die Testergebnisse konfiguriert ist. Die Testergebnisse werden nur dann aufbewahrt, wenn das Release aufbewahrt wird. Wenn Sie die Testergebnisse so lange wie das Release benötigen, legen Sie die Aufbewahrungseinstellungen für automatisierte Testläufe in den Projekteinstellungen entsprechend auf „Nie löschen“ fest. Dadurch wird sichergestellt, dass die Testergebnisse nur gelöscht werden, wenn das Release gelöscht wird.

Werden Ergebnisse manueller Tests gelöscht?

Nein. Ergebnisse manueller Tests werden nicht gelöscht.

Wie behalte ich meine Versionskontrollbezeichnungen oder Tags bei?

Achtung

Alle Versionskontrollbezeichnungen oder Tags, die während einer Buildpipeline angewendet werden und die nicht automatisch von der Aufgabe „Quellen“ erstellt werden, werden beibehalten, auch wenn der Build gelöscht wird. Alle Versionskontrollbezeichnungen oder Tags, die während eines Builds automatisch aus der Aufgabe „Quellen“ erstellt werden, gelten jedoch als Teil der Buildartefakte und werden gelöscht, wenn der Build gelöscht wird.

Wenn Versionskontrollbezeichnungen oder Tags beibehalten werden müssen, selbst wenn der Build gelöscht wird, müssen sie entweder als Teil einer Aufgabe in der Pipeline angewendet oder manuell außerhalb der Pipeline beschriftet werden, oder der Build muss auf unbestimmte Zeit beibehalten werden.

Was geschieht mit Pipelines, die in anderen Pipelines genutzt werden?

Klassische Releases bewahren Pipelines auf, die sie automatisch nutzen.

Verwandte Artikel

• Steuern der Dauer der Aufbewahrung von Testergebnissen
• Testartefakte löschen