Festlegen von Aufbewahrungsrichtlinien für Builds, Versionen und Tests

Azure DevOps Services | Azure DevOps Server 2020 | 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.

Aufbewahrungsrichtlinien ermöglichen es Ihnen, festzulegen, wie lange die Ausführung, Veröffentlichungen und Tests im System beibehalten werden sollen. Um Speicherplatz zu sparen, möchten Sie ältere Ausführungen, Tests und Versionen löschen.

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

  1. Pipeline – Legen Sie fest, wie lange Artefakte, Symbole, Anlagen, Ausführungen und Pullanforderungsläufe beibehalten werden sollen.
  2. Release (klassisch) – Legen Sie fest, ob Builds gespeichert werden sollen, und zeigen Sie die standard- und maximal zulässigen Aufbewahrungseinstellungen an.
  3. Test – Legen Sie fest, wie lange automatisierte und manuelle Testläufe, Ergebnisse und Anlagen beibehalten werden sollen.

Project settings retention policies

Hinweis

Wenn Sie einen lokalen Server verwenden, können Sie auch Aufbewahrungsrichtlinienstandardwerte für ein Projekt angeben und wenn Versionen dauerhaft zerstört werden. Erfahren Sie mehr über die Freigabeaufbewahrung weiter unten in diesem Artikel.

Voraussetzungen

Standardmäßig können Mitglieder der Mitwirkenden, Buildadministratoren, Project Administratoren und Freigabeadministratorgruppen Aufbewahrungsrichtlinien verwalten.

Um Testergebnisse zu verwalten, müssen Sie über eines der folgenden Abonnements verfügen:

Sie können auch monatlichen Zugriff auf Azure Test Plans kaufen und die Zugriffsstufe "Basic + Test Plans" zuweisen. Siehe 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 gear iconRegisterkarte Einstellungen der Einstellungen Ihres Projekts.

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

    • Wählen Sie Einstellungen aus, um Aufbewahrungsrichtlinien für Ausführungen, Artefakte, Symbole, Anlagen und Pullanforderungsausführungen zu konfigurieren.
    • Wählen Sie "Release-Aufbewahrung " aus, um Ihre Aufbewahrungsrichtlinien einzurichten und zu konfigurieren, wann Versionen gelöscht oder endgültig zerstört werden sollen.
    • Wählen Sie "Aufbewahrung " aus, um einzurichten, wie lange manuelle und automatisierte Testläufe beibehalten werden sollen.

    Retention settings in Project settings

Festlegen von Aufbewahrungsrichtlinien

In den meisten Fällen müssen Sie die abgeschlossenen 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, bevor Sie sie löschen.

Zusammen mit dem Definieren der Anzahl von Tagen zur Aufbewahrung von Ausführungen können Sie auch die Mindestanzahl von Ausführungen festlegen, die für jede Pipeline aufbewahrt werden sollen.

  1. Wechseln Sie zur gear iconRegisterkarte Einstellungen der Einstellungen Ihres Projekts.

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

    • Legen Sie die Anzahl der Tage fest, um Artefakte, Symbole und Anlagen beizubehalten.
    • Festlegen der Anzahl der Tage, die ausgeführt werden sollen
    • Legen Sie die Anzahl der Tage fest, um die Pullanforderung zu speichern
    • Festlegen der Anzahl der zuletzt ausgeführten Ausführungen für jede Pipeline

Warnung

Azure DevOps unterstützt keine Aufbewahrungsregeln pro Pipeline mehr. Die einzige Möglichkeit zum Konfigurieren von Aufbewahrungsrichtlinien für YAML und klassische Pipelines erfolgt über die oben beschriebenen Projekteinstellungen. Sie können keine Aufbewahrungsrichtlinien pro Pipeline 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 Erläuterung. Die Interpretation dieser Einstellung variiert je nach Typ des Repositorys, das Sie in Ihrer Pipeline erstellen.

  • Azure Repos: Azure Pipelines behält die konfigurierte Anzahl der neuesten Ausführungen für die Standardverzweigung der Pipeline und für jede geschützte Verzweigung des Repositorys bei. Eine Verzweigung mit konfigurierten Verzweigungsrichtlinien wird als geschützte Verzweigung betrachtet.

    Betrachten Sie beispielsweise ein Repository mit zwei Verzweigungen und mainrelease. Imagine ist die pipeline's default branchmain Verzweigung, und die release Verzweigung verfügt über eine Verzweigungsrichtlinie, wodurch sie zu einer geschützten Verzweigung wird. Wenn Sie in diesem Fall die Richtlinie so konfiguriert haben, dass drei Ausführung beibehalten werden, werden sowohl die letzten drei Ausführungsläufe main als auch die letzten drei Ausführungen der release Verzweigung beibehalten. Darüber hinaus werden die letzten drei Läufe dieser Pipeline (unabhängig von der Verzweigung) ebenfalls aufbewahrt.

    Um diese Logik weiter zu klären, sagen wir, dass die Liste der Ausführungen für diese Pipeline wie folgt ist, mit der neuesten Ausführung oben. In der Tabelle wird gezeigt, welche Ausführung beibehalten wird, wenn Sie die letzten drei Ausführungen beibehalten haben (die Auswirkung der Einstellung für die Anzahl der Tage wird ignoriert):

    Ausführen # Verzweigung Beibehalten /Nicht aufbewahrt Warum?
    Ausführen von 10 Standard Beibehalten Neueste 3 für Haupt- und Neueste 3 für Pipeline
    Ausführen 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 Haupt noch für Pipeline
    Ausführen von 4 Standard Nicht beibehalten Weder neueste 3 für Haupt noch für Pipeline
    Ausführen von 3 Branch1 Nicht beibehalten Weder neueste 3 für Haupt noch für Pipeline
    Testlauf 2 Freigabe Beibehalten Neueste 3 für version
    Ausführen 1 Standard Nicht beibehalten Weder neueste 3 für Haupt noch für Pipeline
  • Alle anderen Git-Repositorys: Azure Pipelines behält die konfigurierte Anzahl der neuesten Ausführungen für die gesamte Pipeline bei.

  • TFVC: Azure Pipelines behält die konfigurierte Anzahl der neuesten Ausführungen für die gesamte Pipeline unabhängig von der Verzweigung bei.

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 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.

Wenn gelöscht wird

Ihre Aufbewahrungsrichtlinien werden einmal pro Tag verarbeitet. Die Zeit, zu der die Richtlinien verarbeitete Variablen erhalten, da wir die Arbeit täglich für Lastenausgleichszwecke verteilen. Es gibt keine Möglichkeit, diesen Prozess zu ändern.

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

  • Er ü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 markiert, unbefristet aufbewahrt zu werden
  • Sie wird nicht von einer Version aufbewahrt.

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

Automatisches Festlegen des Aufbewahrungsleasings für Pipelineausführungen

Aufbewahrungsleass werden verwendet, um die Lebensdauer der Pipeline über die konfigurierten Aufbewahrungsfristen hinaus zu verwalten. Aufbewahrungsleass können in einer Pipeline hinzugefügt oder gelöscht werden, die durch Aufrufen der Lease-API ausgeführt wird. Diese API kann in der Pipeline mithilfe eines Skripts und mithilfe vordefinierter Variablen für runId und definitionId aufgerufen werden.

Ein Aufbewahrungsleasing kann für einen bestimmten Zeitraum in einer Pipelineausführung hinzugefügt werden. Beispielsweise kann eine Pipelineausführung, die für eine Testumgebung bereitgestellt wird, für eine kürzere Dauer aufbewahrt werden, während eine Ausführung, die in produktionsbezogener Umgebung bereitgestellt wird, länger aufbewahrt werden kann.

Manuelles Festlegen der Aufbewahrungsleasing für Pipelineausführungen

Sie können eine Pipelineausführung manuell festlegen, die mithilfe des Menüs "Weitere Aktionen " auf der Seite " Pipelineausführungsdetails " beibehalten werden soll.

manually retain a run

Löschen einer Ausführung

Sie können Die Ausführung mithilfe des Menüs "Weitere Aktionen " auf der Seite " Details ausführen" der Pipeline löschen .

Hinweis

Wenn aufbewahrungsrichtlinien derzeit auf die Ausführung angewendet werden, müssen sie entfernt werden, bevor die Ausführung gelöscht werden kann. Anweisungen finden Sie unter Pipeline-Ausführungsdetails – Löschen einer Ausführung.

delete a run

Festlegen von Freigabeaufbewahrungsrichtlinien

Die Freigabeaufbewahrungsrichtlinien für eine klassische Releasepipeline bestimmen, wie lange eine Version und die ausführung gespeichert werden, die mit dieser verknüpft ist. Mithilfe dieser Richtlinien können Sie steuern, wie viele Tage Sie jede Version beibehalten möchten, nachdem sie zuletzt geändert oder bereitgestellt wurde, und die Mindestanzahl der Versionen , die für jede Pipeline aufbewahrt werden sollen.

Der Aufbewahrungszeitgeber für eine Version wird jedes Mal zurückgesetzt, wenn eine Version geändert oder in einer Phase bereitgestellt wird. Die Mindestanzahl von Versionen zur Aufbewahrung der Einstellung hat Vorrang vor der Anzahl der Tage. Wenn Sie z. B. angeben, dass mindestens drei Versionen beibehalten werden, werden die letzten drei unbefristet aufbewahrt – unabhängig von der angegebenen Anzahl von Tagen. Sie können diese Versionen jedoch manuell löschen, wenn Sie sie nicht mehr benötigen. Weitere Informationen dazu, wie die Freigabeaufbewahrung funktioniert, finden Sie unten in den faq.

Als Autor einer Releasepipeline können Sie Aufbewahrungsrichtlinien für Versionen Ihrer Pipeline auf der Registerkarte "Aufbewahrung " anpassen.

Die Aufbewahrungsrichtlinie für YAML und Buildpipelinen ist identisch. Sie können die Aufbewahrungseinstellungen ihrer Pipeline in Project Einstellungen für Pipelines im Abschnitt Einstellungen sehen.

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

Aufbewahrungsrichtlinie für globale Versionen

Wenn Sie eine lokale Team Foundation Server oder Azure DevOps Server verwenden, können Sie Standardeinstellungen und Höchstwerte für eine Freigabeaufbewahrungsrichtlinie angeben. Sie können auch angeben, wann Versionen endgültig 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 Aufbewahrungsrichtlinie für globale Versionen können über die Einstellungen für die Freigabeaufbewahrung 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 maximale Aufbewahrungsrichtlinie legt die Obergrenze für die Dauer der Aufbewahrung von Versionen für alle Releasepipelinen fest. Autoren von Releasepipelinen können einstellungen für ihre Definitionen nicht über die hier angegebenen Werte hinaus konfigurieren.

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

Die Zerstörungsrichtlinie hilft Ihnen, die Freigaben für einen bestimmten Zeitraum nach dem Löschen beizubehalten. Diese Richtlinie kann nicht in einzelnen Releasepipelinen außer Kraft gesetzt werden.

Festlegen von Aufbewahrungsrichtlinien auf Sammlungsebene

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

Configure server collection settings

Hinweis

In TFS ist die Aufbewahrungsverwaltung 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 Versionen beibehalten, die in bestimmten Phasen bereitgestellt wurden. Ihr Team möchte z. B. folgendes behalten:

  • Versionen, die in der Produktionsphase für 60 Tage bereitgestellt werden, mit mindestens drei letzten bereitgestellten Versionen.
  • Versionen, die für die Vorabproduktionsphase für 15 Tage bereitgestellt wurden, mit mindestens einer letzten bereitgestellten Version.
  • Veröffentlichungen, die für die QA-Phase für 30 Tage bereitgestellt wurden, mit mindestens zwei letzten bereitgestellten Versionen.
  • Versionen, die für die Dev-Phase für 10 Tage bereitgestellt wurden, mit mindestens einer letzten bereitgestellten Version.

Die folgende Beispiel-Aufbewahrungsrichtlinie für eine Releasepipeline erfüllt die oben genannten Anforderungen:

Configuring the release retention setting for a release pipeline

Wenn in diesem Beispiel eine Version, die für Dev bereitgestellt wird, für 10 Tage nicht zur QA höhergestuft wird, ist es ein potenzieller Kandidat für das Löschen. Wenn diese Version jedoch acht Tage nach der Bereitstellung in Dev in QS bereitgestellt wird, wird der Aufbewahrungszeitgeber zurückgesetzt und wird für weitere 30 Tage im System aufbewahrt.

Wenn Sie benutzerdefinierte Richtlinien pro Pipeline angeben, können Sie die vom Administrator festgelegten Maximalgrenzwerte nicht überschreiten.

Interaktion zwischen Build- und Release-Aufbewahrungsrichtlinien

Der mit einer Version verknüpfte Build verfügt über eine eigene Aufbewahrungsrichtlinie, die möglicherweise kürzer als die der Version sein kann. Wenn Sie den Build für denselben Zeitraum wie die Veröffentlichung beibehalten möchten, legen Sie das Kontrollkästchen " Zugeordnete Artefakte beibehalten " für die entsprechenden Stufen fest. Dadurch wird die Aufbewahrungsrichtlinie für den Build außer Kraft gesetzt und sichergestellt, dass die Artefakte verfügbar sind, wenn Sie diese Version erneut bereitstellen müssen.

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

Hinweis

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

Festlegen von Testaufbewahrungsrichtlinien

Sie können manuelle und automatisierte Testausführungsrichtlinien festlegen.

Manuelle Testausführungs-Aufbewahrungsrichtlinien

Um manuelle Testergebnisse nach einer bestimmten Anzahl von Tagen zu löschen, legen Sie den Aufbewahrungsgrenzwert auf Projektebene fest. Azure DevOps speichert manuelle Testergebnisse im Zusammenhang mit Builds, 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 gear icon dann die Projekteinstellungen unten auf der Seite aus.

configure project settings

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

manual tests retention policies

Automatische Testausführungs-Aufbewahrungsrichtlinien

Standardmäßig behält Azure DevOps automatisierte Testergebnisse im Zusammenhang mit Builds nur so lange, wie Sie diese Builds beibehalten. Um Die Testergebnisse nach dem Löschen Ihrer Builds beizubehalten, bearbeiten Sie die Buildaufbewahrungsrichtlinie. Wenn Sie Git für die Versionssteuerung verwenden, können Sie angeben, wie lange die automatisierten Testergebnisse basierend auf dem Zweig beibehalten werden sollen.

  1. Melden Sie sich bei Azure DevOps an. Sie benötigen mindestens Buildebenenberechtigungen zum Bearbeiten von Buildpipelinen.

  2. Wechseln Sie zu Ihrem Projekt, und wählen Sie gear icon dann die Projekteinstellungen unten auf der Seite aus.

manage project settings

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

edit project settings

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 aus externen Testsystemen veröffentlicht wurden, legen Sie die Aufbewahrungsgrenzwerte auf Projektebene fest, wie in den Richtlinien für manuelle Testausführungen aufbewahrungsrichtlinien dargestellt

Festlegen von Aufbewahrungsrichtlinien für Artefakte

Sie können Artefakteaufbewahrungsrichtlinien für Pipeline-Ausführungen in den Pipelineeinstellungen festlegen.

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

  2. Wechseln Sie zur Registerkarte Einstellungen der gear icon Einstellungen Ihres Projekts.

  3. Wählen Sie Einstellungen in Pipelines aus.

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

Verwenden der Aufgabe "Dateien kopieren" zum Speichern von Daten länger

Sie können die Aufgabe "Dateien kopieren" verwenden, um Ihre Build- und Artefaktedaten länger zu speichern als in den Aufbewahrungsrichtlinien festgelegt ist. Die Aufgabe "Dateien kopieren" ist bevorzugt für die Aufgabe "Erstellen Artifacts veröffentlichen", da Daten, die mit der Aufgabe "Veröffentlichen von Build Artifacts" gespeichert wurden, regelmäßig gelöscht 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 auf Branch-by-Branch-Basis anpassen, wenn Sie aus Git-Repositorys erstellen.

Globale Build-Aufbewahrungsrichtlinie

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

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

Die maximale Aufbewahrungsrichtlinie legt die obere Grenze für die Aufbewahrungsdauer für alle Buildpipelinen fest. Autoren von Buildpipelinen können keine Einstellungen für ihre Definitionen über die hier angegebenen Werte hinweg konfigurieren.

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

Die Dauerhaft zerstörten Versionen helfen Ihnen, die Ausführung für einen bestimmten Zeitraum zu behalten, nachdem sie gelöscht wurden. Diese Richtlinie kann in einzelnen Buildpipelinen nicht außer Kraft gesetzt werden.

Git-Repositorys

Wenn ihr Repositorytyp eine der folgenden ist, können Sie mehrere Aufbewahrungsrichtlinien mit Zweigfiltern definieren:

  • Azure Repos Git oder TFS Git.
  • GitHub
  • Andere/externe Git.

Ihr Team möchte z. B. folgendes behalten:

  • Benutzerzweig-Builds für fünf Tage, mit mindestens einem einzigen erfolgreichen oder teilweise erfolgreichen Build für jede Zweigstelle.
  • Haupt- und Feature-Branch-Builds für 10 Tage, mit mindestens drei erfolgreichen oder teilweise erfolgreichen Builds für jede dieser Branchs. Sie ausschließen einen speziellen Featurezweig, den Sie für einen längeren Zeitraum beibehalten möchten.
  • Erstellt aus dem Sonderfeature-Zweig und allen anderen Zweigen für 15 Tage, wobei mindestens ein einzelner erfolgreicher oder teilweise erfolgreicher Build für jede Verzweigung erforderlich ist.

Die folgende Beispiel-Aufbewahrungsrichtlinie 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 maximalen Grenzwerte nicht überschreiten.

Bereinigen von Pull-Anforderungsbuilds

Wenn Sie Ihre Git-Zweigen mit Pull-Anforderungsbuilds schützen, können Sie Aufbewahrungsrichtlinien verwenden, um die abgeschlossenen Builds automatisch zu löschen. Fügen Sie dazu eine Richtlinie hinzu, die mindestens 0 Builds mit dem folgenden Verzweigungsfilter enthält:

  refs/pull/*

retention policies for PR builds

TFVC- und Subversions-Repositorys

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

Richtlinienreihenfolge

Wenn das System alte Builds löscht, bewertet er jeden Build anhand der Richtlinien in der angegebenen Reihenfolge. Sie können eine Richtlinie niedriger oder höher in der Liste ziehen und ablegen, um diese Reihenfolge zu ändern.

Die Richtlinie "Alle" wird automatisch als letzte Richtlinie in der Auswertungsrichtlinie hinzugefügt, um die maximalen Grenzwerte für alle anderen Zweige zu erzwingen.

define git retention policy max shown in pipeline

Häufig gestellte Fragen

Wenn ich eine Ausführung oder eine Veröffentlichung markiert, die unbegrenzt aufbewahrt werden soll, gilt die Aufbewahrungsrichtlinie weiterhin?

Nein. Weder die Aufbewahrungsrichtlinie der Pipeline noch die vom Administrator festgelegten maximalen Grenzwerte werden angewendet, wenn Sie eine einzelne Ausführung oder Veröffentlichung markieren, die unbegrenzt aufbewahrt werden soll. Es bleibt, bis Sie die Aufbewahrung auf unbestimmte Zeit beenden.

Gewusst wie angeben, dass die in der Produktion bereitgestellten Ausführung länger aufbewahrt werden?

Wenn Sie klassische Versionen zum Bereitstellen in der Produktion verwenden, passen Sie die Aufbewahrungsrichtlinie in der Releasepipeline an. Geben Sie die Anzahl der Tage an, die für die Produktion bereitgestellt werden, und müssen beibehalten werden. Geben Sie außerdem an, dass die ausführung, die dieser Version zugeordnet ist, beibehalten werden soll. Dadurch wird die Ausführungsaufbewahrungsrichtlinie außer Kraft setzen.

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

Ich habe keine Ausführung markiert, die unbegrenzt beibehalten werden soll. Ich sehe jedoch eine große Anzahl von Ausführungen, die beibehalten werden. Wie kann ich dies verhindern?

Dies könnte aus einem der folgenden Gründe sein:

  • Die Ausführung wird von einer Person in Ihrem Projekt markiert, die unbegrenzt aufbewahrt werden soll.
  • Die Ausführung wird von einer Version verwendet, und die Version enthält eine Aufbewahrungssperre für diese Ausführung. Passen Sie die Aufbewahrungsrichtlinie für die Version wie oben erläutert an.

Wenn Sie glauben, dass die Ausführung nicht mehr benötigt wird oder die Versionen bereits gelöscht wurden, können Sie die Ausführung manuell löschen.

Wie funktioniert die Einstellung "Mindestversionen beibehalten"?

Mindestversionen, die auf Phasenebene festgelegt werden sollen. Es wird angegeben, dass Azure DevOps immer die angegebene Anzahl der letzten bereitgestellten Versionen für eine Phase beibehalten wird, auch wenn die Versionen außerhalb des Aufbewahrungszeitraums sind. Eine Version wird unter Mindestversionen berücksichtigt, die nur für eine Phase gelten, wenn die Bereitstellung auf dieser Stufe gestartet wurde. Sowohl erfolgreiche als auch fehlgeschlagene Bereitstellungen werden berücksichtigt. Ausstehende Freigaben werden nicht berücksichtigt.

Wie wird der Aufbewahrungszeitraum entschieden, wenn die Veröffentlichung in mehreren Phasen mit unterschiedlichen Aufbewahrungsdauern bereitgestellt wird?

Der endgültige Aufbewahrungszeitraum wird beschlossen, indem Tage berücksichtigt werden, um Einstellungen aller Phasen beizubehalten, auf denen die Version bereitgestellt wird, und maximal Tage dauern, um sie beizubehalten. Mindestversionen, die beibehalten werden sollen, werden auf Stufesebene geregelt und ändern sich nicht basierend auf der version, die auf mehreren Stufen bereitgestellt wurde oder nicht. Die zugehörigen Artefakte werden beibehalten, wenn die Veröffentlichung in einer Phase bereitgestellt wird, für die sie "true" festgelegt ist.

Ich habe eine Phase gelöscht, für die ich einige alte Versionen habe. Welche Aufbewahrung wird für diesen Fall berücksichtigt?

Da die Stufe gelöscht wird, sind die Aufbewahrungseinstellungen auf Stufesebene jetzt nicht anwendbar. Azure DevOps fällt zurück auf die Standardaufbewahrung auf Projektebene für diesen Fall.

Meine Organisation erfordert, dass wir Builds und Versionen 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 eine Version länger beizubehalten als das, was über Aufbewahrungseinstellungen zulässig ist, besteht darin, sie manuell zu markieren, die unbegrenzt aufbewahrt werden soll. 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 über die Ausführung herunterzuladen und sie in Ihr eigenes Speicher- oder Artefakte-Repository hochzuladen.

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

Wenn Sie glauben, dass Sie aufgrund eines Fehlers im Dienst verloren gegangen sind, 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ührung aufgrund einer Aufbewahrungsrichtlinie wie erwartet gelöscht wurde, ist es nicht möglich, die verlorenen Ausführungen wiederherzustellen.

Gewusst wie die Build.Cleanup Funktion 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 nicht regelmäßig arbeiten kann. Wenn eine Pipelineausführung gelöscht wird, werden Artefakte, die außerhalb von Azure DevOps gespeichert sind, über einen Auftrag bereinigt, der auf den Agents ausgeführt wird. Wenn der Agentpool mit Bereinigungsaufträgen gesättigt wird, kann dies zu einem Problem führen. Die Lösung dafür besteht darin, eine Teilmenge von Agents im Pool festzulegen, die die Bereinigungs-Agents sind. Wenn alle Agents festgelegt sind Build.Cleanup , 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 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 Funktion verfügbar? 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 einer Version veröffentlicht werden, aufbewahrt, bis die Veröffentlichung gelöscht wird?

Testergebnisse, die in einer Phase einer Version veröffentlicht wurden, werden gemäß der für die Testergebnisse konfigurierten Aufbewahrungsrichtlinie beibehalten. Die Testergebnisse werden erst aufbewahrt, wenn die Version beibehalten wird. Wenn Sie die Testergebnisse so lange wie die Veröffentlichung 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 die Version gelöscht wird.

Werden manuelle Testergebnisse gelöscht?

Nein. Manuelle Testergebnisse werden nicht gelöscht.

Gewusst wie meine Versionssteuerungsbezeichnungen oder -tags beibehalten?

Achtung

Alle Versionssteuerelementbeschriftungen oder Tags, die während einer Buildpipeline angewendet werden, die nicht automatisch aus der Aufgabe "Quellen" erstellt werden, werden beibehalten, auch wenn der Build gelöscht wird. Alle Versionssteuerelementbeschriftungen 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 Versionssteuerungsbezeichnungen oder Tags beibehalten werden müssen, auch wenn der Build gelöscht wird, müssen sie entweder als Teil einer Aufgabe in der Pipeline angewendet werden, manuell außerhalb der Pipeline bezeichnet werden, oder der Build muss unbegrenzt aufbewahrt werden.