Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests

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

Hinweis

Microsoft Visual Studio Team Foundation Server 2018 und frühere Versionen haben die folgenden Unterschiede in der Namensgebung:

  • Pipelines für Build und Release werden Definitionen genannt
  • Läufe werden als builds bezeichnet
  • Dienstverbindungen werden als Dienstendpunkte bezeichnet
  • Die Stages werden Environments genannt
  • Die Jobs werden Phases genannt

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

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

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

Project settings retention policies

Hinweis

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

Voraussetzungen

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

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

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

Konfigurieren von Aufbewahrungsrichtlinien

  1. Melden Sie sich bei Ihrem Projekt an.

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

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

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

    Screenshot of retention settings in Project settings for DevOps 2019.

Konfigurieren von Aufbewahrungsrichtlinien

  1. Melden Sie sich bei Ihrem Projekt an.

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

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

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

    Screenshot of retention settings in Project settings.

Wichtig

Azure Pipelines unterstützt keine pipelinespezifischen Aufbewahrungsrichtlinien mehr. Es werden Aufbewahrungsregeln auf Projektebene empfohlen.

Festlegen von Aufbewahrungsrichtlinien für Ausführungen

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

Sie können nicht nur festlegen, wie viele Tage Ausführungen aufbewahrt werden sollen, sondern auch die Mindestanzahl der Ausführungen, die für jede Pipeline beibehalten werden sollen.

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

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

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

Warnung

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

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

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

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

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

    Nr. der Ausführung Verzweigung Beibehalten/Nicht beibehalten Warum?
    Ausführung 10 Standard Beibehalten Die letzten 3 für „main“ und letzten 3 für Pipeline
    Ausführung 9 Branch1 Beibehalten Die letzten 3 für Pipeline
    Ausführung 8 Branch2 Beibehalten Die letzten 3 für Pipeline
    Ausführung 7 Standard Beibehalten Die letzten 3 für „main“
    Ausführung 6 Standard Beibehalten Die letzten 3 für „main“
    Ausführung 5 Standard Nicht beibehalten Weder die letzten 3 für „main“ noch für Pipeline
    Ausführung 4 Standard Nicht beibehalten Weder die letzten 3 für „main“ noch für Pipeline
    Ausführung 3 Branch1 Nicht beibehalten Weder die letzten 3 für „main“ noch für Pipeline
    Testlauf 2 Freigabe Beibehalten Die letzten 3 für Release
    Ausführung 1 Standard Nicht beibehalten Weder die letzten 3 für „main“ noch für Pipeline
  • Alle anderen Git-Repositorys: Azure Pipelines behält die konfigurierte Anzahl der letzten Ausführungen für die gesamte Pipeline bei.

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

Welche Teile der Ausführung werden gelöscht?

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 wählen, ob Sie den gesamten Builddatensatz löschen oder die grundlegenden Informationen zum Build auch nach dem Löschen des Builds aufbewahren möchten.
  • 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.
  • Ergebnisse automatisierter Tests: Sie können die Ergebnisse automatisierter Tests löschen, die dem Build zugeordnet sind (z. B. Ergebnisse, die von der Buildaufgabe „Testergebnisse veröffentlichen“ veröffentlicht wurden).

Die folgenden Informationen werden beim Löschen eines Builds gelöscht:

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

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

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

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

Wann werden Ausführungen gelöscht?

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

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

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

Ihre Aufbewahrungsrichtlinien werden täglich um 03: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 bei einer Pipelineausführung durch Aufrufen der Lease-API hinzugefügt oder gelöscht werden. Diese API kann innerhalb der Pipeline mithilfe eines Skripts und vordefinierter Variablen für runId und definitionId aufgerufen werden.

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

Manuelles Festlegen von Aufbewahrungsleases für Pipelineausführungen

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

manually retain a run

Löschen einer Ausführung

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

Hinweis

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

delete a run

Festlegen der Aufbewahrungsrichtlinien für Releases

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

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

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

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

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

Globale Aufbewahrungsrichtlinie für Releases

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

On premises release retention settings

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

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

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

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

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

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

Festlegen von Aufbewahrungsrichtlinien auf Sammlungsebene

Für lokale Server können Sie die Aufbewahrungsrichtlinien auf Sammlungsebene auch mithilfe benutzerdefinierter Aufbewahrungsregeln festlegen. Diese Aufbewahrungsrichtlinien gelten für klassische Buildpipelines. Die Seite unter https://{your_server}/{collection_name}/_settings/buildqueue dient zum Steuern Ihrer Maximal- und Standardwerte.

A screenshot showing how to configure collection level retention policies.

Hinweis

In TFS ist die Verwaltung der Releaseaufbewahrung auf das Angeben der Anzahl von Tagen beschränkt, und zwar erst ab TFS 2015.3.

Phasenspezifische Aufbewahrungsrichtlinien

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

  • 60 Tage in der Phase „Produktion“ bereitgestellte Releases, mit mindestens drei zuletzt bereitgestellten Releases.
  • 15 Tage in der Phase „Präproduktion“ bereitgestellte Releases, mit mindestens einem zuletzt bereitgestellten Release.
  • 30 Tage in der Phase „Qualitätssicherung“ bereitgestellte Releases, mit mindestens zwei zuletzt bereitgestellten Releases.
  • 10 Tage in der Phase „Entwicklung“ bereitgestellte Releases, mit mindestens einem zuletzt bereitgestellten Release.

Das folgende Beispiel einer Aufbewahrungsrichtlinie 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 in der Phase „Entwicklung“ bereitgestellt wird, 10 Tage nicht in die Phase „Qualitätssicherung“ höhergestuft wird, ist es ein potenzieller Löschkandidat. Wenn dieselbe Version jedoch nach Bereitstellung in der Phase „Entwicklung“ acht Tage später in der Phase „Qualitätssicherung“ bereitgestellt wird, wird der Aufbewahrungszeitgeber zurückgesetzt, und die Version wird weitere 30 Tage im System aufbewahrt.

Wenn Sie pipelinespezifische benutzerdefinierte Richtlinien angeben, können Sie die vom Administrator festgelegten maximalen Grenzwerte nicht überschreiten.

Interaktion zwischen Aufbewahrungsrichtlinien für Builds und Releases

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 den gleichen Zeitraum wie das Release aufbewahren möchten, legen Sie das Kontrollkästchen Zugeordnete Artefakte beibehalten für die entsprechenden Phasen fest. 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 oder ein Release löschen oder 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 Interaktion zwischen Build- und Releaseaufbewahrung ab TFS 2017 verfügbar.

Festlegen von Testaufbewahrungsrichtlinien

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

Aufbewahrungsrichtlinien für manuelle Testläufe

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

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

  2. Öffnen Sie Ihr Projekt, und wählen Sie dann unten auf der Seite gear icon „Projekteinstellungen“ aus.

configure project settings

  1. Wählen Sie auf der Seite „Aufbewahrung“ im Abschnitt „Test“ einen Grenzwert für die Dauer der Aufbewahrung von Daten manueller Tests aus.

manual tests retention policies

Aufbewahrungsrichtlinien für automatisierte Testläufe

Standardmäßig behält Azure DevOps Ergebnisse automatisierter Tests im Zusammenhang mit Builds nur so lange bei, wie Sie diese Builds aufbewahren. 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 Ergebnisse automatisierter Tests 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. Öffnen Sie Ihr Projekt, und wählen Sie dann unten auf der Seite gear icon „Projekteinstellungen“ aus.

manage project settings

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

edit project settings

Weitere Ergebnisse automatisierter Tests

Um Ergebnisse automatisierter Tests, die von gelöschten Builds übrig geblieben sind, oder Testergebnisse ohne Bezug zu Builds zu bereinigen, z. B. von externen Testsystemen veröffentlichte Ergebnisse, legen Sie die Aufbewahrungsfristen auf Projektebene fest, wie unter Aufbewahrungsrichtlinien für manuelle Testläufe beschrieben.

Festlegen von Aufbewahrungsrichtlinien für Artefakte

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

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

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

  3. Wählen Sie in Pipelines die Option Einstellungen aus.

  4. Bearbeiten Sie Aufbewahrung von Artefakten, Symbolen und Anlagen in Tagen.

Langfristiges Speichern von Daten mithilfe der Aufgabe „Dateien kopieren“

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

- 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 branchbezogen anpassen, wenn Sie Builds über Git-Repositorys erstellen.

Globale Richtlinie für die Buildaufbewahrung

Sie können für eine Projektsammlung Standard- und Maximalwerte für Richtlinien zur Buildaufbewahrung angeben. Sie können auch angeben, wann Builds dauerhaft zerstört (von der Registerkarte Gelöscht im Build-Explorer entfernt) werden.

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

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

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

Die Option Releases dauerhaft zerstören hilft Ihnen, die Ausführungen für einen bestimmten Zeitraum beizubehalten, nachdem sie gelöscht wurden. Diese Richtlinie kann nicht in einzelnen Buildpipelines außer Kraft gesetzt 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
  • Sonstiges/externes Git.

Ihr Team möchte beispielsweise Folgendes beibehalten:

  • Builds von Benutzerbranches für fünf Tage, mit mindestens einem einzelnen erfolgreichen oder teilweise erfolgreichen Build für jeden Branch.
  • Builds von Main- und Featurebranches für 10 Tage, mit mindestens drei erfolgreichen oder teilweise erfolgreichen Builds für jeden dieser Branches. Sie schließen einen spezielle Featurebranch aus, die Sie für einen längeren Zeitraum aufbewahren möchten.
  • Builds aus dem speziellen Featurebranch und allen anderen Branches für 15 Tage, mit mindestens einem einzelnen erfolgreichen oder teilweise erfolgreichen Build für jeden Branch.

Das folgende Beispiel einer Aufbewahrungsrichtlinie für eine Buildpipeline erfüllt die oben genannten Anforderungen:

define git retention policies

Wenn Sie für jede Pipeline benutzerdefinierte Richtlinien angeben, können Sie die vom Administrator festgelegten maximalen Grenzwerte nicht überschreiten.

Bereinigen von Pull Request-Builds

Wenn Sie Ihre Git-Branches mit Pull Request-Builds schützen, können Sie die abgeschlossenen Builds mithilfe von Aufbewahrungsrichtlinien automatisch löschen. Fügen Sie dazu eine Richtlinie hinzu, die ein Minimum an 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 löscht, wertet es jeden Build anhand der Richtlinien in der von Ihnen angegebenen Reihenfolge aus. Sie können eine Richtlinie in der Liste nach unten oder oben ziehen, um diese Reihenfolge zu ändern.

Die Branchrichtlinie „Alle“ wird automatisch als letzte Richtlinie in der Auswertungsreihenfolge hinzugefügt, um die Obergrenzen für alle anderen Branches zu erzwingen.

define git retention policy max shown in pipeline

Häufig gestellte Fragen

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

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

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

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

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

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

Dies kann einen der folgenden Gründe haben:

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

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

Wie funktioniert die Einstellung „Mindestzahl beizubehaltender Releases“?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Werden Ergebnisse manueller Tests gelöscht?

Nein. Ergebnisse manueller Tests werden nicht gelöscht.

Wie behalte ich meine Versionskontrollbezeichnungen oder Tags bei?

Achtung

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

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

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

Klassische Releases bewahren Pipelines auf, die sie automatisch nutzen.

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

Klassische Releases bewahren Pipelines auf, 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 nutzen. Die Ressourcenpipeline wird automatisch aufbewahrt, solange die Releasepipeline aufbewahrt wird.