Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests

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

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

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

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

Voraussetzungen

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

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

• Enterprise
• Test Professional
• MSDN-Plattformen

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

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.

Welche Teile der Ausführung werden gelöscht?

Wann werden Ausführungen gelöscht?

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.

Globale Aufbewahrungsrichtlinie für Releases

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

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

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

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

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

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

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

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

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.

Verwandte Artikel

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