Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests

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

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

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.

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

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

Hinweis

Wenn Sie einen lokalen Server verwenden, können Sie auch Aufbewahrungsrichtlinienstandard für ein Projekt und den Zeitpunkt angeben, wenn Releases endgültig 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.

Zum Verwalten von Aufbewahrungsrichtlinien müssen Sie über eines der folgenden Abonnements verfügen:

• 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 (https://dev.azure.com/{yourorganization}/{yourproject}).

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

3. Wählen Sie unter Test unter Pipelines oder Aufbewahrung die Option Einstellungen oder Releaseaufbewahrung 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 Das Release einzurichten und zu konfigurieren, wann Releases gelöscht oder endgültig gelöscht werden sollen.
   • Wählen Sie Aufbewahrung aus, um festzulegen, wie lange manuelle und automatisierte Testläufe beibehalten werden sollen.

   

Wichtig

Azure Pipelines unterstützt keine Aufbewahrungsrichtlinien pro Pipeline mehr. Es wird empfohlen, Aufbewahrungsregeln auf Projektebene zu verwenden.

Festlegen von Ausführungsaufbewahrungsrichtlinien

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

Neben der Definition, wie viele Tage Die Ausführung beibehalten werden soll, können Sie auch die Mindestanzahl von Ausführungen festlegen, die für jede Pipeline beibehalten werden sollen.

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

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

   • Legen Sie die Anzahl der Tage fest, die Artefakte, Symbole und Anlagen beibehalten sollen.
   • Festlegen der Anzahl der Tage, die ausgeführt werden sollen
   • Legen Sie die Anzahl der Tage fest, die Pull Request-Ausführungen beibehalten werden sollen.
   • Legen Sie die Anzahl der zuletzt ausgeführten Ausführungen fest, die für jede Pipeline beibehalten werden sollen.

Warnung

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

Die Einstellung für die Anzahl der zuletzt ausgeführten Ausführungen, die für jede Pipeline beibehalten werden sollen, erfordert etwas mehr Erklärung. 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, in dem alle Branchrichtlinien konfiguriert sind, gilt als geschützter Branch.

  Betrachten Sie als Beispiel ein Repository mit zwei Branches main und release. Stellen Sie sich vor, dass der pipeline's default branch Branch der main Branch ist, und der release Branch verfügt über eine Branchrichtlinie, die ihn zu einem geschützten 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 release Branchs beibehalten. Darüber hinaus werden die letzten drei Ausführungen dieser Pipeline (unabhängig von der Verzweigung) ebenfalls beibehalten.

  Um diese Logik weiter zu verdeutlichen, nehmen wir an, dass die Liste der Läufe für diese Pipeline wie folgt lautet, wobei die letzte Ausführung an der Spitze steht. Die Tabelle zeigt, welche Ausführungen beibehalten werden, wenn Sie so konfiguriert haben, dass die letzten drei Ausführungen beibehalten werden (wobei die Auswirkung der Einstellung anzahl der Tage ignoriert wird):

  Ausführen #	Verzweigung	Beibehalten /Nicht aufbewahrt	Warum?
  Ausführen von 10	Standard	Beibehalten	Neueste 3 für main und Neueste 3 für Pipeline
  Ausführen von 9	branch1	Beibehalten	Neueste 3 für Pipeline
  Ausführen von 8	branch2	Beibehalten	Neueste 3 für Pipeline
  Ausführen von 7	Standard	Beibehalten	Neueste 3 für haupt
  Ausführen 6	Standard	Beibehalten	Neueste 3 für haupt
  Ausführen von 5	Standard	Nicht beibehalten	Weder neueste 3 für main noch für pipeline
  Ausführen von 4	Standard	Nicht beibehalten	Weder neueste 3 für main noch für pipeline
  Ausführen von 3	branch1	Nicht beibehalten	Weder neueste 3 für main noch für pipeline
  Testlauf 2	Freigabe	Beibehalten	Neueste Version 3 für Release
  Ausführen von 1	Standard	Nicht beibehalten	Weder neueste 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 bei, unabhängig vom Branch.

Welche Teile der Ausführung gelöscht werden

Wenn die Aufbewahrungsrichtlinien einen Build zum Löschen markieren, können Sie steuern, welche Informationen im Zusammenhang mit dem Build gelöscht werden:

• Builddatensatz: Sie können den gesamten Builddatensatz löschen oder grundlegende Informationen zum Build beibehalten, auch nachdem der Build gelöscht wurde.
• Quellbezeichnung: Wenn Sie Quellen als Teil des Builds bezeichnen, können Sie das Tag (für Git) oder die Bezeichnung (für TFVC) löschen, die von einem Build erstellt wurde.
• Automatisierte Testergebnisse: Sie können die automatisierten Testergebnisse löschen, die dem Build zugeordnet sind (z. B. Ergebnisse, die vom Buildtask "Testergebnisse veröffentlichen" veröffentlicht werden).

Die folgenden Informationen werden gelöscht, wenn ein Build gelöscht wird:

• Protokolle
• Veröffentlichte Artefakte
• Veröffentlichte Symbole

Die folgenden Informationen werden gelöscht, wenn eine Ausführung gelöscht wird:

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

Universelle Pakete, 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. Die Zeit, in der die Richtlinien verarbeitete Variablen erhalten, da wir die Arbeit für Lastenausgleichszwecke über den Tag verteilen. Es gibt keine Möglichkeit, diesen Prozess zu ändern.

Eine Ausführung wird gelöscht, wenn alle folgenden Bedingungen erfüllt sind:

• Sie überschreitet die Anzahl von Tagen, die in den Aufbewahrungseinstellungen konfiguriert sind.
• Es handelt sich nicht um eine der letzten Ausführungen, die in den Aufbewahrungseinstellungen konfiguriert sind.
• Es ist nicht so gekennzeichnet, dass er unbegrenzt aufbewahrt wird.
• Es wird nicht von einem Release aufbewahrt.

Ihre Aufbewahrungsrichtlinien werden täglich um 3:00 Uhr UTC ausgeführt. Es gibt keine Möglichkeit, den Zeitpunkt der Richtlinienausführung zu ändern.

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 in einer Pipelineausführung hinzugefügt oder gelöscht werden, indem die Lease-API aufgerufen wird. Diese API kann innerhalb der Pipeline mithilfe eines Skripts und mithilfe vordefinierter Variablen für runId und definitionId aufgerufen werden.

Eine Aufbewahrungsleasase kann einer Pipelineausführung für einen bestimmten Zeitraum hinzugefügt werden. Beispielsweise kann eine Pipelineausführung, die in einer Testumgebung bereitgestellt wird, 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 der Aufbewahrungsleasing für Pipelineausführungen

Sie können manuell festlegen, dass eine Pipelineausführung beibehalten wird, indem Sie das Menü Weitere Aktionen auf der Seite Pipelineausführungsdetails verwenden.

Löschen einer Ausführung

Sie können Ausführungen über das Menü Weitere Aktionen auf der Seite Pipelineausführungsdetails löschen.

Hinweis

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

Festlegen von Releaseaufbewahrungsrichtlinien

Die Releaseaufbewahrungsrichtlinien für eine klassische Releasepipeline bestimmen, wie lange ein Release und die damit verknüpfte Ausführung beibehalten werden. Mithilfe dieser Richtlinien können Sie steuern, wie viele Tage Sie jedes Release behalten möchten, nachdem es zuletzt geändert oder bereitgestellt wurde, und die Mindestanzahl von Releases , die für jede Pipeline beibehalten 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 von Releases, die beibehalten werden sollen, hat Vorrang vor der Anzahl der Tage. Wenn Sie beispielsweise angeben, dass mindestens drei Releases beibehalten werden sollen, werden die letzten drei Versionen auf unbestimmte Zeit beibehalten – 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 Releaseaufbewahrung finden Sie unter FAQ unten.

Als Autor 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 im Abschnitt Einstellungen unter Projekteinstellungen für Pipelines.

Sie können auch erfahren, wie Sie diese Richtlinien schrittweise anpassen , weiter unten in diesem Artikel.

Globale Releaseaufbewahrungsrichtlinie

Wenn Sie ein lokales Team Foundation Server oder eine Azure DevOps Server verwenden, können Sie die Standardwerte und Höchstwerte der Releaseaufbewahrungsrichtlinie für ein Projekt angeben. Sie können auch angeben, wann Releases endgültig zerstört werden (aus der Registerkarte Gelöscht im Build-Explorer entfernt).

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

Die Einstellungen für globale Releaseaufbewahrungsrichtlinien können über die Aufbewahrungseinstellungen für das Release 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 maximale Aufbewahrungsrichtlinie legt die Obergrenze fest, wie lange Releases für alle Releasepipelines beibehalten werden können. Autoren von Releasepipelines können keine Einstellungen für ihre Definitionen konfigurieren, die über die hier angegebenen Werte hinausgehen.

Die Standardaufbewahrungsrichtlinie legt die Standardaufbewahrungswerte für alle Releasepipelines fest. Autoren von Buildpipelines können diese Werte außer Kraft setzen.

Die Zerstörungsrichtlinie hilft Ihnen, die Releases nach dem Löschen für einen bestimmten Zeitraum beizubehalten. Diese Richtlinie kann in einzelnen Releasepipelines nicht überschrieben werden.

Festlegen von Aufbewahrungsrichtlinien auf Sammlungsebene

Für lokale Server können Sie auch Aufbewahrungsrichtlinien auf Sammlungsebene mit benutzerdefinierten Aufbewahrungsregeln festlegen. Diese Aufbewahrungsrichtlinien gelten für klassische Buildpipelines. Die Seite unter https://{your_server}/{collection_name}/_settings/buildqueue steuert Ihre Maximal- und Standardwerte.

Hinweis

In TFS ist die Verwaltung der Releaseaufbewahrung auf die Angabe der Anzahl von Tagen beschränkt, und dies ist nur in TFS 2015.3 und höher verfügbar.

Phasenspezifische Aufbewahrungsrichtlinien

Möglicherweise möchten Sie weitere Releases beibehalten, die in bestimmten Phasen bereitgestellt wurden. Ihr Team möchte beispielsweise Folgendes beibehalten:

• Releases, die für 60 Tage in der Produktionsphase bereitgestellt werden, mit mindestens drei zuletzt bereitgestellten Releases.
• Releases, die 15 Tage lang in der Pre-Production-Phase bereitgestellt werden, wobei mindestens ein letztes Release bereitgestellt wurde.
• Releases, die für 30 Tage in der QA-Phase bereitgestellt werden, wobei mindestens zwei letzte Releases bereitgestellt wurden.
• Releases, die für 10 Tage in der Dev-Phase bereitgestellt werden, wobei mindestens ein letztes Release bereitgestellt wurde.

Die folgende Beispielaufbewahrungsrichtlinie für eine Releasepipeline erfüllt die oben genannten Anforderungen:

Wenn in diesem Beispiel ein Release, das für Dev bereitgestellt wird, 10 Tage lang nicht in qa höhergestuft wird, ist es ein potenzieller Löschkandidat. Wenn dasselbe Release jedoch acht Tage nach der Bereitstellung in Dev für qa bereitgestellt wird, wird der Aufbewahrungszeitgeber zurückgesetzt und wird für weitere 30 Tage im System aufbewahrt.

Wenn Sie benutzerdefinierte Richtlinien pro Pipeline angeben, dürfen Sie die vom Administrator festgelegten Grenzwerte nicht überschreiten.

Interaktion zwischen Build- und Releaseaufbewahrungsrichtlinien

Der mit einem Release verknüpfte Build verfügt über eine eigene Aufbewahrungsrichtlinie, die möglicherweise kürzer als die des Releases ist. Wenn Sie den Build für denselben Zeitraum wie das Release beibehalten möchten, legen Sie das Kontrollkästchen Zugeordnete Artefakte beibehalten für die entsprechenden Phasen fest. Dadurch wird die Aufbewahrungsrichtlinie für den Build außer Kraft gesetzt und sichergestellt, dass die Artefakte verfügbar sind, wenn Sie dieses Release erneut bereitstellen müssen.

Wenn Sie eine Releasepipeline löschen, ein Release löschen oder wenn die Aufbewahrungsrichtlinie ein Release automatisch löscht, bestimmt die Aufbewahrungsrichtlinie für den zugeordneten Build, wann dieser Build gelöscht wird.

Hinweis

In TFS ist die Interaktion zwischen Build- und Releaseaufbewahrung in TFS 2017 und höher verfügbar.

Festlegen von Testaufbewahrungsrichtlinien

Sie können manuelle und automatisierte Testlaufrichtlinien festlegen.

Aufbewahrungsrichtlinien für manuelle Testausführungen

Um manuelle Testergebnisse nach einer bestimmten Anzahl von Tagen zu löschen, legen Sie das Aufbewahrungslimit auf Projektebene fest. Azure DevOps behält manuelle Testergebnisse im Zusammenhang mit Builds bei, auch nachdem Sie diese Builds gelöscht haben. Auf diese Weise löschen Buildrichtlinien Ihre Testergebnisse nicht, bevor Sie die Daten analysieren können.

1. Melden Sie sich bei Azure DevOps an. Sie benötigen mindestens Projektadministratorberechtigungen.

2. Wechseln Sie zu Ihrem Projekt, und wählen Sie dann am unteren Rand der Seite aus.

3. Wählen Sie auf der Seite Aufbewahrung unter dem Abschnitt Test ein Limit für die Dauer der Aufbewahrung manueller Testdaten aus.

Aufbewahrungsrichtlinien für automatisierte Testausführungen

Standardmäßig speichert Azure DevOps automatisierte Testergebnisse, die sich auf Builds beziehen, nur solange Sie diese Builds beibehalten. Bearbeiten Sie die Buildaufbewahrungsrichtlinie, um die Testergebnisse nach dem Löschen ihrer Builds beizubehalten. Wenn Sie Git für die Versionskontrolle verwenden, können Sie angeben, wie lange automatisierte Testergebnisse basierend auf dem Branch beibehalten werden sollen.

1. Melden Sie sich bei Azure DevOps an. Sie benötigen mindestens Berechtigungen auf Buildebene, um Buildpipelines zu bearbeiten.

2. Wechseln Sie zu Ihrem Projekt, und wählen Sie dann am unteren Rand der Seite aus.

3. Wählen Sie unter Pipelines Einstellungen aus, und ändern Sie Ihre Aufbewahrungsrichtlinien.

Weitere automatisierte Testergebnisse

Um automatisierte Testergebnisse zu bereinigen, die von gelöschten Builds oder Testergebnissen übrig bleiben, die sich nicht auf Builds beziehen, z. B. ergebnisse, die von externen Testsystemen veröffentlicht wurden, legen Sie die Aufbewahrungsgrenzwerte auf Projektebene fest, wie in den Aufbewahrungsrichtlinien für manuelle Testausführungen gezeigt.

Festlegen von Artefaktaufbewahrungsrichtlinien

Sie können Artefaktaufbewahrungsrichtlinien für Pipelineausführungen in den Pipelineeinstellungen festlegen.

1. Melden Sie sich bei Ihrem Projekt an. Für Azure DevOps Services lautet https://dev.azure.com/{yourorganization}/{yourproject}der URL-Pfad .

2. Wechseln Sie zu der Registerkarte in den Einstellungen Ihres Projekts.

3. Wählen Sie einstellungen in Pipelines aus.

4. Bearbeiten Sie Tage, um Artefakte, Symbole und Anlagen beizubehalten.

Verwenden Sie den Task Dateien kopieren, um Daten länger zu speichern.

Sie können die Aufgabe Dateien kopieren verwenden, um Ihre Build- und Artefaktdaten länger als in den Aufbewahrungsrichtlinien festgelegt zu 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 der Pipeline den Task Dateien kopieren hinzu.

2. Konfigurieren Sie den Task Dateien kopieren.

Sie können diese Richtlinien auch auf Branch-by-Branch-Basis anpassen, wenn Sie aus Git-Repositorys erstellen.

Globale Buildaufbewahrungsrichtlinie

Sie können Buildaufbewahrungsrichtlinienstandard und Höchstwerte für eine Projektsammlung angeben. Sie können auch angeben, wann Builds dauerhaft zerstört werden (aus der Registerkarte Gelöscht im Build-Explorer entfernt).

• TFS 2018: https://{your_server}/tfs/DefaultCollection/_admin/_buildQueue

Die maximale Aufbewahrungsrichtlinie legt die Obergrenze fest, wie lange Ausführungen für alle Buildpipelines beibehalten werden können. Autoren von Buildpipelines können keine Einstellungen für ihre Definitionen über die hier angegebenen Werte hinaus konfigurieren.

Die Standardaufbewahrungsrichtlinie legt die Standardaufbewahrungswerte für alle Buildpipelines fest. Autoren von Buildpipelines können diese Werte außer Kraft setzen.

Die Releases Permanent zerstören helfen Ihnen, die Ausführungen nach dem Löschen für einen bestimmten Zeitraum beizubehalten. Diese Richtlinie kann in einzelnen Buildpipelines nicht überschrieben werden.

Git-Repositorys

Wenn Ihr Repositorytyp einer der folgenden Ist, können Sie mehrere Aufbewahrungsrichtlinien mit Branchfiltern definieren:

• Azure Repos Git oder TFS Git.
• GitHub
• Anderes/externes Git.

Ihr Team möchte beispielsweise Folgendes beibehalten:

• Der Benutzerbranch wird fünf Tage lang erstellt, wobei mindestens ein einzelner erfolgreicher oder teilweise erfolgreicher Build für jeden Branch vorhanden ist.
• Haupt- und Featurebranchs werden 10 Tage lang erstellt, wobei mindestens drei erfolgreiche oder teilweise erfolgreiche Builds für jede dieser Branchs vorhanden sind. Sie schließen einen speziellen Featurebranch aus, den Sie für einen längeren Zeitraum beibehalten möchten.
• Erstellt aus dem Speziellen Featurebranch und allen anderen Branches für 15 Tage, wobei mindestens ein einzelner erfolgreicher oder teilweise erfolgreicher Build für jeden Branch vorhanden ist.

Die folgende Beispielaufbewahrungsrichtlinie für eine Buildpipeline erfüllt die oben genannten Anforderungen:

Wenn Sie benutzerdefinierte Richtlinien für jede Pipeline angeben, dürfen Sie die vom Administrator festgelegten Grenzwerte nicht überschreiten.

Bereinigen von Pull Request-Builds

Wenn Sie Ihre Git-Branches mit Pull Request-Builds schützen, können Sie Aufbewahrungsrichtlinien verwenden, um die abgeschlossenen Builds automatisch zu löschen. Fügen Sie dazu eine Richtlinie hinzu, die ein Minimum an 0 Builds mit dem folgenden Branchfilter vorhält:

  refs/pull/*

TFVC- und Subversion-Repositorys

Für TFVC- und Subversion-Repositorytypen können Sie eine einzelne Richtlinie mit den oben gezeigten Optionen ändern.

Richtlinienreihenfolge

Wenn das System alte Builds löscht, wertet es jeden Build anhand der Richtlinien in der von Ihnen angegebenen Reihenfolge aus. Sie können eine Richtlinie nach unten oder höher in der Liste ziehen und ablegen, um diese Reihenfolge zu ändern.

Die Richtlinie "Alle"-Branches wird automatisch als letzte Richtlinie in der Auswertungsreihenfolge hinzugefügt, um die Maximalen Grenzwerte für alle anderen Branches zu erzwingen.

Häufig gestellte Fragen

Gilt die Aufbewahrungsrichtlinie weiterhin, wenn ich eine Ausführung oder ein Release markiere, die unbegrenzt beibehalten werden soll?

Nein. Weder die Aufbewahrungsrichtlinie der Pipeline noch die vom Administrator festgelegten Höchstgrenzwerte werden angewendet, wenn Sie eine einzelne Ausführung oder Eine einzelne Version für eine unbegrenzte Beibehaltung markieren. Sie bleibt so lange erhalten, bis Sie die Aufbewahrung auf unbestimmte Zeit beenden.

Gewusst wie angeben, dass die in der Produktion bereitgestellten Ausführungen länger beibehalten 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, die für die 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 Ausführungsaufbewahrungsrichtlinie außer Kraft gesetzt.

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

Ich habe keine Läufe markiert, die unbegrenzt 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 markiert, die unbegrenzt aufbewahrt werden soll.
• Die Ausführungen werden von einem Release genutzt, und das Release enthält eine Aufbewahrungssperre für diese Ausführungen. Passen Sie die Releaseaufbewahrungsrichtlinie wie oben erläutert an.

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

Wie funktioniert die Einstellung "Mindestfreigaben, die beibehalten werden sollen"?

Mindestfreigaben, die beibehalten werden sollen, werden auf Phasenebene definiert. Es gibt an, dass Azure DevOps immer die angegebene Anzahl der letzten bereitgestellten Releases für eine Phase behält, auch wenn sich die Releases außerhalb des Aufbewahrungszeitraums befinden. Ein Release wird als Mindestversionen betrachtet, die nur für eine Phase beibehalten werden sollen, wenn die Bereitstellung in dieser Phase gestartet wurde. Es werden sowohl erfolgreiche als auch fehlgeschlagene Bereitstellungen berücksichtigt. Releases, für die die Genehmigung aussteht, werden nicht berücksichtigt.

Wie wird der Aufbewahrungszeitraum entschieden, wenn die Freigabe in mehreren Phasen mit unterschiedlicher Aufbewahrungsdauer bereitgestellt wird?

Der endgültige Aufbewahrungszeitraum wird festgelegt, indem Tage berücksichtigt werden, um Einstellungen aller Phasen beizubehalten, in denen das Release bereitgestellt wird, und maximal Tage in Anspruch zu nehmen. Mindestversionen, die beibehalten werden sollen , werden auf Phasenebene geregelt und ändern sich nicht basierend auf der bereitgestellten Version in mehrere Phasen oder nicht. Das Beibehalten zugeordneter Artefakte ist anwendbar, wenn die Freigabe für eine Phase bereitgestellt wird, für die sie true festgelegt ist.

Ich habe eine Phase gelöscht, für die ich einige alte Releases habe. Welche Aufbewahrungsdauer wird in diesem Fall berücksichtigt?

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

Meine Organisation erfordert, dass wir Builds und Releases länger aufbewahren, als in den Einstellungen zulässig ist. Wie kann ich eine längere Aufbewahrungsdauer anfordern?

Die einzige Möglichkeit, eine Ausführung oder ein Release länger beizubehalten, als durch Aufbewahrungseinstellungen zulässig ist, besteht darin, sie manuell so zu markieren, dass sie unbegrenzt beibehalten wird. Es gibt keine Möglichkeit, eine längere Aufbewahrungseinstellung zu konfigurieren. Sie können auch die Möglichkeit erkunden, die REST-APIs zu verwenden, um Informationen und Artefakte zu den Ausführungen herunterzuladen und in Ihr eigenes Speicher- oder Artefaktrepository hochzuladen.

Ich habe einige Läufe verloren. Gibt es eine Möglichkeit, sie zurückzubekommen?

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

Gewusst wie die Build.Cleanup Funktion von Agents nutzen?

Das Festlegen einer Build.Cleanup Funktion für Agents führt dazu, dass die Bereinigungsaufträge des Pools nur an diese Agents weitergeleitet werden, sodass der Rest für die reguläre Arbeit frei bleibt. Wenn eine Pipelineausführung gelöscht wird, werden Artefakte, die außerhalb von Azure DevOps gespeichert sind, durch einen Auftrag bereinigt, der auf den Agents ausgeführt wird. Wenn der Agentpool 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 die Bereinigungs-Agents sind. Wenn Agents festgelegt wurden Build.Cleanup , führen nur diese Agents die Bereinigungsaufträge aus, sodass die restlichen Agents weiterhin Pipelineaufträge ausführen können. Die Bereinigungsfunktion kann aktiviert werden, indem Sie zu Agentfunktionen> navigieren und gleich1festlegen.Build.Cleanup

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: Gibt es einen Agent mit Build.Cleanup verfügbarer Funktion? Ist der Agent, der den Build ausgeführt hat, verfügbar? Ist ein Agent aus demselben Pool verfügbar? Ist ein Agent aus einem ähnlichen Pool verfügbar? Ist ein Agent verfügbar?

Werden automatisierte Testergebnisse, die als Teil eines Releases veröffentlicht werden, beibehalten, bis das Release gelöscht wird?

Testergebnisse, die in einer Phase einer Version veröffentlicht werden, werden wie in der Aufbewahrungsrichtlinie angegeben, die für die Testergebnisse konfiguriert ist. Die Testergebnisse werden erst beibehalten, wenn das Release beibehalten 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 manuelle Testergebnisse gelöscht?

Nein. Manuelle Testergebnisse werden nicht gelöscht.

Gewusst wie meine Versionskontrollbezeichnungen oder -tags beibehalten?

Achtung

Alle Bezeichnungen der Versionskontrolle oder Tags, die während einer Buildpipeline angewendet werden und nicht automatisch aus der Aufgabe Quellen erstellt werden, werden beibehalten, auch wenn der Build gelöscht wird. Alle Bezeichnungen der Versionskontrolle 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 Bezeichnungen oder Tags der Versionsverwaltung beibehalten werden müssen, müssen sie auch beim Löschen des Builds entweder als Teil einer Aufgabe in der Pipeline angewendet, manuell außerhalb der Pipeline beschriftet oder der Build auf unbestimmte Zeit beibehalten werden.

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

Klassische Releases behalten Pipelines bei, die sie automatisch nutzen.

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

Klassische Releases behalten Pipelines bei, die sie automatisch nutzen. Wenn Sie YAML verwenden, können Sie auch eine mehrstufige YAML-Pipeline erstellen, um Ihr Release darzustellen und eine andere YAML-Pipeline darin als Ressource zu nutzen. Die Ressourcenpipeline wird automatisch beibehalten, solange die Releasepipeline beibehalten wird.

Verwandte Artikel

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