Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests

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 die im System gespeicherten Läufe, Releases und Tests aufbewahrt werden sollen. Um Speicherplatz zu sparen, möchten Sie ältere Läufe, Tests und Releases löschen.

Die folgenden Aufbewahrungsrichtlinien sind in den Azure DevOps in ihren Project verfügbar:

  1. Pipeline: Legen Sie fest, wie lange Artefakte, Symbole, Anlagen, Läufe und Pull Request-Läufe erhalten bleiben.
  2. Release (klassisch): Legen Sie fest, ob Builds zu speichern sind, und zeigen Sie die Standardeinstellungen für die maximale Aufbewahrung an.
  3. Test: Legen Sie fest, wie lange automatisierte und manuelle Testläufe, Ergebnisse und Anlagen erhalten bleiben.

Project settings retention policies

Hinweis

Wenn Sie einen lokalen Server verwenden, können Sie auch Standardwerte für Aufbewahrungsrichtlinien für ein Projekt angeben und festlegen, wann Releases dauerhaft zerstört werden. Weitere Informationen zur Veröffentlichungsaufbewahrung finden Sie weiter später in diesem Artikel.

Voraussetzungen

Standardmäßig können Mitglieder der Gruppen Contributors, Build Admins, Project Admins und Release Admins Aufbewahrungsrichtlinien verwalten.

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

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 gear iconzur Einstellungen registerkarte der Projekteinstellungen.

  3. Wählen Einstellungen oder Releaseaufbewahrungunter Pipelines oder Aufbewahrung unterTest aus.

    • Wählen Einstellungen aus, um Aufbewahrungsrichtlinien für Läufe, Artefakte, Symbole, Anlagen und Pull Request-Läufe zu konfigurieren.
    • Wählen Sie Releaseaufbewahrung aus, um Ihre Richtlinien für die Veröffentlichungsaufbewahrung zu konfigurieren und zu konfigurieren, wann Releases gelöscht oder endgültig gelöscht werden.
    • Wählen Sie Aufbewahrung aus, um die Dauer manueller und automatisierter Testläufe zu aktivieren.

    Retention settings in Project settings

Festlegen von Aufbewahrungsrichtlinien für die Ausführung

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

Neben der Definition, wie viele Tage die Läufe beibehalten werden sollen, können Sie auch die Mindestanzahl von Läufen festlegen, die für jede Pipeline beibehalten werden sollen.

  1. Wechseln Sie gear iconzur Einstellungen registerkarte der Projekteinstellungen.

  2. Wählen Einstellungen abschnitt Pipelines aus.

    • Legen Sie die Anzahl von Tagen fest, um Artefakte,Symbole und Anlagen zu behalten.
    • Festlegen der Anzahl von Tagen zum Behalten von Läufen
    • Festlegen der Anzahl von Tagen zum Halten von Pull Request-Läufen
    • Festlegen der Anzahl der zuletzt ausgeführten Läufe für jede Pipeline

Warnung

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

Die Einstellung für die Anzahl der zuletzt ausgeführten Läufe, die für jede Pipeline erhalten bleiben, 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 die konfigurierte Anzahl der letzten Läufe für den Standardverzweigung der Pipeline und für jeden geschützten Branch des Repositorys. Ein Branch, für den Branchrichtlinien konfiguriert sind, wird als geschützter Branch betrachtet.

    Betrachten Sie beispielsweise ein Repository mit zwei Verzweigungen, main und release . Imagine ist der Branch, und der Branch verfügt über eine pipeline's default branchmain Branchrichtlinie, wodurch er zu einem release geschützten Branch wird. Wenn Sie in diesem Fall die Richtlinie so konfiguriert haben, dass drei Durchläufe beibehalten werden, werden sowohl die letzten drei Durchläufe von als auch die letzten drei Läufe des mainrelease Branchs beibehalten. Darüber hinaus werden auch die letzten drei Läufe dieser Pipeline (unabhängig vom Branch) beibehalten.

    Um diese Logik weiter zu verdeutlichen, nehmen wir an, dass die Liste der Ausführungen für diese Pipeline wie folgt lautet, mit der letzten Ausführung oben. Die Tabelle zeigt, welche Läufe beibehalten werden, wenn Sie so konfiguriert haben, dass die letzten drei Läufe beibehalten werden (ohne die Auswirkungen der Einstellung anzahl von Tagen):

    Ausführen # Verzweigung Beibehalten/Nicht beibehalten 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 main
    Ausführen von 6 Standard Beibehalten Neueste 3 für main
    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 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 1 Standard Nicht beibehalten Weder neueste 3 für main noch für Pipeline
  • Alle anderen Git-Repositorys: Azure Pipelines die konfigurierte Anzahl der neuesten Läufe für die gesamte Pipeline bei.

  • TFVC: Azure Pipelines die konfigurierte Anzahl der letzten Läufe für die gesamte Pipeline, unabhängig vom Branch.

Welche Teile der Ausführung werden gelöscht?

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 auch nach dem Löschen des Builds den gesamten Builddatensatz löschen oder grundlegende Informationen zum Build beibehalten.
  • 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 von der Buildaufgabe Testergebnisse veröffentlichen veröffentlicht wurden).

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 Ausgeführte gelöscht?

Ihre Aufbewahrungsrichtlinien werden einmal täglich verarbeitet. Die Zeit, zu der die Richtlinien verarbeitete Variablen erhalten, da wir die Arbeit für den Lastenausgleich über den Tag verteilen. Es gibt keine Option, diesen Prozess zu ändern.

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

  • Sie überschreitet die Anzahl von Tagen, die in den Aufbewahrungseinstellungen konfiguriert sind.
  • Es handelt sich nicht um eine der letzten Ausführungen, wie in den Aufbewahrungseinstellungen konfiguriert.
  • Sie ist nicht als unbegrenzt beibehalten gekennzeichnet.
  • Sie wird nicht durch ein Release beibehalten.

Ihre Aufbewahrungsrichtlinien werden täglich um 3:00 Uhr UTC ausgeführt. Es gibt keine Option zum Ändern der Ausführungszeit der Richtlinien.

Automatisches Festlegen der Aufbewahrungslease für Pipelineläufe

Aufbewahrungsleases werden verwendet, um die Lebensdauer von Pipelineläufen über die konfigurierten Aufbewahrungsdauern hinaus zu verwalten. Aufbewahrungsleases können bei einer Pipelinelaufzeit durch Aufrufen der Lease-APIhinzugefügt oder gelöscht werden. Diese API kann innerhalb der Pipeline mithilfe eines Skripts und vordefinierten Variablen für runId und definitionId aufgerufen werden.

Eine Aufbewahrungslease kann einer Pipelinelaufzeit für einen bestimmten Zeitraum hinzugefügt werden. Beispielsweise kann eine Pipelinelauf, die in einer Testumgebung bereitgestellt wird, für einen kürzeren Zeitraum beibehalten werden, während eine Ausführung, die in einer Produktionsumgebung bereitgestellt wird, länger aufbewahrt werden kann.

Manuelles Festlegen der Aufbewahrungslease für Pipelineläufe

Sie können manuell festlegen, dass eine Pipelineläufe beibehalten werden, indem Sie das Menü Weitere Aktionen auf der Detailseite pipeline run verwenden.

manually retain a run

Löschen einer Ausführung

Sie können Ausführungen mithilfe des Menüs Weitere Aktionen auf der Detailseite Pipelinelauf 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 Pipelinelauf – Löschen einer Ausführung.

delete a run

Festlegen von Richtlinien für die Veröffentlichungsaufbewahrung

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 die einzelnen Releases nach der letzten Änderung oder Bereitstellung beibehalten werden sollen, sowie 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, für die die Einstellung beibehalten werden soll, hat Vorrang vor der Anzahl von Tagen. Wenn Sie beispielsweise angeben, dass mindestens drei Releases beibehalten werden sollen, werden die letzten drei unbegrenzt aufbewahrt – 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 Veröffentlichungsaufbewahrung finden Sie weiter unten in den häufig gestellten Fragen.

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 werden im Abschnitt Einstellungen in Project Einstellungen für Pipelines angezeigt.

Sie können auch später in diesem Artikel erfahren, wie Sie diese Richtlinien phasenweise anpassen.

Globale Veröffentlichungsaufbewahrungsrichtlinie

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

On premises release retention settings

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

Einstellungen für die globale Veröffentlichungsaufbewahrungsrichtlinie können über die Einstellungen für die Veröffentlichungsaufbewahrung Ihres Projekts verwaltet 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 die maximale Aufbewahrung legt die Obergrenze für die Beibehaltungsdauer von Releases für alle Releasepipelines fest. 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 überschreiben.

Die Zerstörungsrichtlinie hilft Ihnen, die Releases für einen bestimmten Zeitraum beizubehalten, nachdem sie gelöscht wurden. Diese Richtlinie kann nicht in einzelnen Releasepipelines überschrieben werden.

Festlegen von Aufbewahrungsrichtlinien auf Sammlungsebene

Für lokale Server können Sie die Aufbewahrungsrichtlinien auf Sammlungsebene auch mit benutzerdefinierten Aufbewahrungsregeln festlegen. Diese Aufbewahrungsrichtlinien gelten für klassische Buildpipelines. Auf der Seite unter https://{your_server}/{collection_name}/_settings/buildqueue werden Die maximalen Werte und Standardwerte gesteuert.

Configure server collection settings

Hinweis

In TFS ist die Veröffentlichungsaufbewahrungsverwaltung auf die Angabe der Anzahl von Tagen beschränkt. Dies ist nur in TFS 2015.3 und neuer 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 60 Tage lang in der Produktionsphase bereitgestellt wurden, mit mindestens drei zuletzt bereitgestellten Releases.
  • Releases, die 15 Tage lang in der Präproduktionsphase bereitgestellt wurden, mit mindestens einem zuletzt bereitgestellten Release.
  • Releases, die 30 Tage lang in der QA-Phase bereitgestellt wurden, mit mindestens zwei zuletzt bereitgestellten Releases.
  • Releases, die 10 Tage lang in der Entwicklungsphase bereitgestellt wurden, mit mindestens einem zuletzt bereitgestellten Release.

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

Configuring the release retention setting for a release pipeline

Wenn in diesem Beispiel ein Release, das für Dev bereitgestellt wird, nicht 10 Tage lang auf QA heraufgestuft wird, ist es ein potenzieller Kandidat für den Löschvorgang. Wenn das gleiche Release jedoch acht Tage nach der Bereitstellung in Dev in QA bereitgestellt wird, wird der Aufbewahrungszeitgeber zurückgesetzt und für weitere 30 Tage im System beibehalten.

Wenn Sie benutzerdefinierte Richtlinien pro Pipeline angeben, können 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 Release ist. Wenn Sie den Build für den gleichen Zeitraum wie das Release beibehalten möchten, aktivieren Sie das Kontrollkästchen Zugeordnete Artefakte beibehalten für die entsprechenden Phasen. Dadurch wird die Aufbewahrungsrichtlinie für den Build überschrieben 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 neuer verfügbar.

Festlegen von Testaufbewahrungsrichtlinien

Sie können Richtlinien für manuelle und automatisierte Testläufe festlegen.

Aufbewahrungsrichtlinien für manuelle Testläufe

Um manuelle Testergebnisse nach einer bestimmten Anzahl von Tagen zu löschen, legen Sie den Aufbewahrungsgrenzwert 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 Ihrem Azure DevOps an. Sie benötigen mindestens Projektadministratorberechtigungen.

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

configure project settings

  1. Wählen Sie auf der Seite Aufbewahrung im Abschnitt Test einen Grenzwert für die Aufbewahrungsdauer manueller Testdaten aus.

manual tests retention policies

Automatisierte Aufbewahrungsrichtlinien für Testläufe

Standardmäßig behält Azure DevOps automatisierte Testergebnisse im Zusammenhang mit Builds nur bei, solange Sie diese Builds beibehalten. Bearbeiten Sie die Buildaufbewahrungsrichtlinie, um die Testergebnisse nach dem Löschen der 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 gear icon am unteren Rand der Seite Projekteinstellungen aus.

manage project settings

  1. Wählen Sie unter Pipelines Einstellungen aus, gear icon und ändern Sie Ihre Aufbewahrungsrichtlinien.

edit project settings

Andere 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 Testläufe gezeigt.

Festlegen von Aufbewahrungsrichtlinien für Artefakte

Sie können Die Aufbewahrungsrichtlinien für Artefakte für Pipelineläufe in den Pipelineeinstellungen festlegen.

  1. Melden Sie sich bei Ihrem Projekt an ( https://dev.azure.com/{yourorganization}/{yourproject} ).

  2. Wechseln Sie auf der Registerkarte gear iconEinstellungen der Projekteinstellungen zu .

  3. Wählen Sie Einstellungen in Pipelinesaus.

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

Verwenden des Tasks "Dateien kopieren" zum längeren Speichern von Daten

Sie können den Task Dateien kopieren verwenden, um Ihre Build- und Artefaktdaten länger als in den Aufbewahrungsrichtlinien festgelegt zu speichern. Der Task Dateien kopieren ist dem Task Build veröffentlichen Artifacts vorzuziehen, da mit dem Task Build veröffentlichen Artifacts gespeicherte Daten regelmäßig bereinigt und gelöscht werden.

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

Sie können diese Richtlinien auch branchweise anpassen, wenn Sie aus Git-Repositoryserstellen.

Globale Buildaufbewahrungsrichtlinie

Sie können Standardwerte und Höchstwerte für die Buildaufbewahrungsrichtlinie 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 2017 und neuer: https://{your_server}/tfs/DefaultCollection/_admin/_buildQueue
  • TFS 2015.3: http://{your_server}:8080/tfs/DefaultCollection/_admin/_buildQueue

  • TFS 2015 RTM: http://{your_server}:8080/tfs/DefaultCollection/_admin/_buildQueue#_a=settings

Die Richtlinie für die maximale Aufbewahrung legt die Obergrenze für die Beibehaltungsdauer für alle Buildpipelines fest. Autoren von Buildpipelines können keine Einstellungen für ihre Definitionen konfigurieren, die über die hier angegebenen Werte hinausgehen.

Die Standardaufbewahrungsrichtlinie legt die Standardaufbewahrungswerte für alle Buildpipelines fest. Autoren von Buildpipelines können diese Werte überschreiben.

Mit den Releases für dauerhaftes Zerstören können Sie die Ausführungen für einen bestimmten Zeitraum beibehalten, nachdem sie gelöscht wurden. Diese Richtlinie kann nicht in einzelnen Buildpipelines ü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:

  • Benutzerverzweigung wird fünf Tage lang erstellt, wobei mindestens ein einzelner erfolgreicher oder teilweise erfolgreicher Build für jeden Branch erstellt wird.
  • Haupt- und Featurebranchebuilds für 10 Tage mit mindestens drei erfolgreichen oder teilweise erfolgreichen Builds für jede dieser Branches. Sie schließen eine spezielle Featureverzweigung aus, die Sie für einen längeren Zeitraum beibehalten möchten.
  • Erstellt 15 Tage lang aus dem Special Feature Branch und allen anderen Branches, wobei mindestens ein einzelner erfolgreicher oder teilweise erfolgreicher Build für jeden Branch erfolgt.

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

define git retention policies

Wenn Sie benutzerdefinierte Richtlinien für jede Pipeline angeben, können 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 hierzu eine Richtlinie hinzu, die mindestens 0 Builds mit dem folgenden Branchfilter beibehält:

  refs/pull/*

retention policies for PR builds

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 bereinigen möchte, wertet es jeden Build anhand der Richtlinien in der von Ihnen angegebenen Reihenfolge aus. Sie können eine Richtlinie per Drag & Drop nach unten oder höher in der Liste 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.

define git retention policy max shown in pipeline

Häufig gestellte Fragen

Gilt die Aufbewahrungsrichtlinie weiterhin, wenn ich eine Ausführung oder ein Release für eine unbegrenzte Aufbewahrung markiere?

Nein. Weder die Aufbewahrungsrichtlinie der Pipeline noch die vom Administrator festgelegten maximalen Grenzwerte werden angewendet, wenn Sie eine einzelne Ausführung oder ein Release so kennzeichnen, dass sie unbegrenzt beibehalten wird. Sie bleibt so lange erhalten, bis Sie die Aufbewahrung auf unbestimmte Zeit beenden.

Gewusst wie angeben, dass in der 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, 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 die Ausführung überschrieben.

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

Ich habe Ausführungen nicht so gekennzeichnet, dass sie unbegrenzt beibehalten werden. 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 verfügt über eine Aufbewahrungssperre für diese Ausführungen. Passen Sie die Veröffentlichungsaufbewahrungsrichtlinie wie oben beschrieben 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 "Mindestversionen, die beibehalten werden müssen"?

Mindestversionen, die beibehalten werden sollen, werden auf Phasenebene definiert. Er gibt an, dass Azure DevOps immer die angegebene Anzahl der zuletzt bereitgestellten Releases für eine Phase beibehält, auch wenn die Freigaben außerhalb des Aufbewahrungszeitraums liegen. Ein Release wird unter den Mindestversionen berücksichtigt, die nur dann für eine Phase beibehalten werden, wenn die Bereitstellung in dieser Phase gestartet wurde. Sowohl erfolgreiche als auch fehlgeschlagene Bereitstellungen werden berücksichtigt. Releases mit ausstehender Genehmigung werden nicht berücksichtigt.

Wie wird die Beibehaltungsdauer festgelegt, wenn die Freigabe in mehreren Phasen mit unterschiedlicher Beibehaltungsdauer bereitgestellt wird?

Die endgültige Beibehaltungsdauer wird durch Die Berücksichtigung von Tagen festgelegt, um Einstellungen aller Phasen beizubehalten, in denen das Release bereitgestellt wird, und es wird maximal Tage dauern, bis die Einstellungen zwischen ihnen beibehalten werden. Mindestversionen, die beibehalten werden müssen, werden auf Phasenebene gesteuert und ändern sich nicht basierend auf der Version, die in mehreren Phasen bereitgestellt wird. Zugeordnete Artefakte beibehalten ist anwendbar, wenn das Release in einer Phase bereitgestellt wird, für die es auf 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 einen solchen Fall auf die Standardaufbewahrung auf Projektebene zurückverlegt.

Meine Organisation verlangt von uns, dass Builds und Releases länger aufbewahrt werden, 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 als durch Die Aufbewahrungseinstellungen zulässig beizubehalten, besteht darin, sie manuell so zu kennzeichnen, dass sie unbegrenzt aufbewahrt 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 Ihren eigenen Speicher oder Ihr eigenes Artefakt-Repository hochzuladen.

Ich habe einige Ausführungen verloren. Gibt es eine Möglichkeit, sie zurückzubekommen?

Wenn Sie der Meinung sind, dass Sie aufgrund eines Fehlers im Dienst Ausführungen verloren haben, erstellen Sie sofort ein Supportticket, um die verlorenen Informationen wiederherzustellen. Wenn eine Builddefinition mehr als eine Woche zuvor manuell gelöscht wurde, kann sie nicht wiederhergestellt werden. 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 Funktion Build.Cleanup von Agents verwenden?

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 reguläre Aufgaben frei bleibt. Wenn eine Pipeline ausgeführt wird, werden Artefakte, die außerhalb von Azure DevOps gespeichert sind, durch eine Auftragsausleitung auf den Agents bereinigt. Wenn der Agentpool mit Bereinigungsaufträgen überlastigt wird, kann dies zu einem Problem führen. Die Lösung hierfür besteht darin, eine Teilmenge der Agents im Pool festzulegen, bei denen es sich um die Bereinigungs-Agents handelt. Wenn Agents Build.Cleanup festgelegt wurden, führen nur diese Agents die Bereinigungsaufträge aus, sodass die restlichen Agents weiterhin Pipelineaufträge ausführen können.

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

Wenn ein Build mit dateifreigabe Artifacts gelöscht wird, wird ein neuer Buildtask auf einem Build-Agent in die Warteschlange eingereiht, um diese Dateien zu bereinigen. Ein Agent wird ausgewählt, um diese Aufgabe anhand der folgenden Kriterien auszuführen: Ist ein Agent mit Build.Cleanup verfügbarer Funktion 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 ein Agent verfügbar?

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

Testergebnisse, die innerhalb einer Phase eines Release veröffentlicht werden, werden gemäß der aufbewahrungsrichtlinie beibehalten, 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 Project Einstellungen 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 Versionskontrollbezeichnungen oder -tags, die während einer Buildpipeline angewendet werden und nicht automatisch aus dem Sources-Task erstellt werden, werden beibehalten, auch wenn der Build gelöscht wird. Allerdings werden alle Versionskontrollbezeichnungen oder -tags, die während eines Builds automatisch aus dem Sources-Task erstellt werden, als Teil der Buildartefakte betrachtet und gelöscht, wenn der Build gelöscht wird.

Wenn Bezeichnungen oder Tags der Versionskontrolle beibehalten werden müssen, selbst wenn der Build gelöscht wird, müssen sie entweder als Teil einer Aufgabe in der Pipeline angewendet werden, die außerhalb der Pipeline manuell bezeichnet wird, oder der Build muss unbegrenzt beibehalten werden.