Konfigurieren von Pipelines zur Unterstützung der Arbeitsnachverfolgung

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

Um die Integration und Nachverfolgbarkeit in Azure DevOps Services mit Pipelines zu unterstützen, können Sie mehrere Optionen konfigurieren. Sie können den Pipelinestatus melden, die Syntax für Statusbadges kopieren und automatische Verknüpfung von Arbeitselementen mit Builds und Releases einrichten.

Unterstützte Pipeline- und Arbeitsnachverfolgungs-Integrationsfeatures

Mehrere Features bieten Unterstützung für End-to-End-Rückverfolgbarkeit, während User Storys und Features den Entwicklungszyklus durchlaufen. Wie bei Azure Repos können Sie Arbeitselemente mit Pipelineobjekten mit den folgenden Linktypen verknüpfen: Build, integriert in Build und Integriert in Release. Beachten Sie, dass der Link In Releaseumgebung integriert nur erstellt werden kann, indem die Option Releasestatus an Boards melden in klassischen Releasepipelines aktiviert wird.

Konzeptionelle Abbildung: Verknüpfungstypen, die Arbeitselemente mit Azure Pipelines-Objekten verknüpfen.

In der folgenden Tabelle werden die Integrationspunkte zwischen Azure Boards und Azure Pipelines zusammengefasst. Optionen und Konfigurationsschritte unterscheiden sich je nachdem, ob Sie eine YAML- oder klassische Pipeline konfigurieren, und abhängig von Ihrer Azure DevOps-Version. Die meisten Optionen werden für Pipelines unterstützt, die für ein Git-Repository von Azure Repos ausgeführt werden, sofern nichts anderes angegeben ist.

Feature

Beschreibung

Unterstützte Versionen


Manuelles Verknüpfen von Arbeitselementen mit Builds

Sie können ein Arbeitselement mit Builds innerhalb desselben Projekts oder in anderen Projekten innerhalb der Organisation verknüpfen. Ausführliche Informationen finden Sie unter Verknüpfen von Arbeitselementen aus anderen Objekten.

Alle Versionen


Anzeigen von Builds, die über ein Arbeitselement verknüpft sind

Sie können alle Builds auf der Registerkarte „Links“ anzeigen, die über ein Arbeitselement (manuell oder automatisch) verknüpft sind. Weitere Informationen finden Sie unter Verknüpfen mit Arbeitselementen aus anderen Objekten, Anzeigen der Liste verknüpfter Objekte.

Alle Versionen


Automatisches Verknüpfen von Arbeitselementen mit Builds

Erforderlich, um das Entwicklungssteuerelement mit In Build integriert-Links aufzufüllen. Die Arbeitselemente oder Commits, die Teil eines Release sind, werden aus den Versionen von Artefakten berechnet. Beispielsweise ist jeder Build in Azure Pipelines einem Satz von Arbeitselementen und Commits zugeordnet. Ausführliche Informationen finden Sie weiter unten in diesem Artikel unter Automatisches Verknüpfen von Arbeitselementen.

YAML, Azure DevOps Server 2020 und höher
Klassisch, TFS 2017.2 und höher


Automatisches Verknüpfen von Arbeitselementen mit Releases und Berichtsbereitstellungsstatus mit einem Arbeitselement (nur klassisch)

Erforderlich, um das Bereitstellungssteuerelement im Arbeitselementformular mit In Releasestage integriert-Links aufzufüllen. Ausführliche Informationen finden Sie weiter unten in diesem Artikel unter Berichtbereitstellungstatus zu Boards.

Azure DevOps Server 2020 und höher


Anzeigen der Liste der Arbeitselemente, die mit einem Build oder Release verknüpft sind

Überprüfen und Öffnen der Arbeitselemente, die in einem Build oder Release enthalten sind.

YAML, Azure DevOps Server 2020 und höher
Klassisch, TFS 2017.2 und höher


Erstellen eines Arbeitselements bei Fehlern (klassisch)

Automatisches Erstellen eines Arbeitselements, wenn ein Build fehlschlägt, und optional Festlegen von Werten für Arbeitselementfelder. Ausführliche Informationen finden Sie weiter unten in diesem Artikel unter Erstellen eines Arbeitselements bei Fehlern.

TFS 2018 und höhere Versionen


Task „Arbeitselemente abfragen“: Hiermit wird sichergestellt, dass die Anzahl der von einer Abfrage zurückgegebenen übereinstimmenden Arbeitselemente innerhalb eines bestimmten Schwellenwerts liegt.

Verwenden Sie diesen Task, um sicherzustellen, dass die Anzahl der übereinstimmenden Elemente, die von einer Arbeitselemente-Abfrage zurückgegeben werden, innerhalb des konfigurierten Schwellenwerts liegt. Ausführliche Informationen finden Sie unter Task „Abfragen von Arbeitselementen“, Steuern von Bereitstellungen mit Gates und Genehmigungen.

Azure DevOps Server 2020 und höhere Versionen


Voraussetzungen

  • Zum Konfigurieren der Integrationsoptionen für eine klassische Releasepipeline müssen Sie über Berechtigungen zum Bearbeiten des Release verfügen.
  • Um Arbeitselemente mit Commits und Pull Requests zu verknüpfen, muss die Berechtigung Arbeitselemente in diesem Knoten bearbeiten für den Bereichspfad, der dem Arbeitselement zugewiesen ist, für Sie auf Zulassen festgelegt sein. Standardmäßig ist diese Berechtigung für die Gruppe „Mitwirkende“ festgelegt.
  • Zum Anzeigen von Arbeitselementen müssen die Berechtigungen Arbeitselemente in diesem Knoten anzeigen für den dem Arbeitselement zugewiesenen Bereichspfad auf Zulassen festgelegt sein.

Öffnen von Pipelineeinstellungen, Buildoptionen oder Integrationsoptionen

Öffnen der Pipelineeinstellungen

Für durch YAML definierte Releasepipelines konfigurieren Sie die Integration über das Dialogfeld Pipelineeinstellungen.

  1. Öffnen Sie die Pipeline, wählen Sie Weitere Aktionen und dann Einstellungen aus.

    Öffnen der Pipelineeinstellungen.

    Das Dialogfeld „Pipelineeinstellungen“ wird angezeigt. Ausführliche Informationen zur automatischen Verknüpfung finden Sie weiter unten in diesem Artikel unter Automatisches Verknüpfen von Arbeitselementen.

    Dialogfeld „YAML-Pipelineeinstellungen“.

Diese Einstellung ist für Azure DevOps Server 2019 oder früheren Versionen nicht verfügbar.

Durch das Aktivieren von automatischer Verknüpfung können Sie die Builds oder Releases nachverfolgen, die Arbeit integriert haben, ohne eine große Anzahl von Builds oder Releases manuell durchsuchen zu müssen. Jeder erfolgreiche Build, der dem Arbeitselement zugeordnet ist, wird automatisch im Steuerelement Entwicklung des Arbeitsaufgabenformulars angezeigt. Jede erfolgreiche Releasestage, die dem Arbeitselement zugeordnet ist, wird automatisch im Steuerelement Entwicklung des Arbeitsaufgabenformulars angezeigt.

Durch das Aktivieren von automatischer Verknüpfung können Sie die Builds nachverfolgen, die Arbeit integriert haben, ohne eine große Anzahl von Builds manuell durchsuchen zu müssen. Jeder erfolgreiche Build, der dem Arbeitselement zugeordnet ist, wird automatisch im Steuerelement Entwicklung des Arbeitsaufgabenformulars angezeigt.

  1. Öffnen Sie Pipelineeinstellungen wie unter Öffnen von Pipelineeinstellungen beschrieben.

  2. Aktivieren Sie Neue Arbeit in diesem Build automatisch verknüpfen.

    Screenshot: Dialogfeld „Pipelineeinstellungen“, „Arbeitselemente in diesem Build automatisch verknüpfen“.

    Nach der Aktivierung werden In Build integriert-Links bei jeder Releaseausführung für alle Arbeitselemente generiert, die mit dem ausgewählten Pull Request verknüpft sind.

Dieses Feature wird für YAML-Pipelines in Azure DevOps Server 2019 nicht unterstützt.

Welche Arbeitselemente sind in der automatischen Verknüpfung enthalten?

Beim Entwickeln Ihrer Software können Sie Arbeitselemente verknüpfen, wenn Sie einen Branch, einen Commit oder einen Pull Request erstellen. Alternativ können Sie einen Branch, einen Commit oder einen Pull Request aus einem Arbeitselement initiieren und diese Objekte automatisch verknüpfen, wie unter Steuern der Git-Entwicklung aus einem Arbeitselement beschrieben. Hier erstellen wir beispielsweise einen neuen Branch aus der User Story „Cancel order form“ (Bestellformular stornieren).

Dialogfeld „Branch erstellen“ aus dem Arbeitselementformular.

Beim automatischen Verknüpfen von Arbeitselementen mit Builds werden die folgenden Berechnungen durchgeführt:

  • Für einen erstmaligen Buildvorgang:

    • Identifizieren aller Arbeitselemente, die mit dem Branch, den Commits und den Pull Requests verknüpft sind, die dem Build zugeordnet sind.
  • Für nachfolgende Builds:

    • Identifizieren aller Arbeitselemente, die dem aktuellen Commit (C1) zugeordnet sind, der erstellt wird.
    • Identifizieren aller Arbeitselemente, die dem Commit (C2) des letzten erfolgreichen Builds desselben Quellbranchs zugeordnet sind.
    • Identifizieren aller Arbeitselemente, die den Commits zwischen C1 und C2 in der Commitstruktur zugeordnet sind.

Erstellen eines Arbeitselements bei Buildfehlern (klassisch)

Wenn eine Buildpipeline fehlschlägt, können Sie automatisch ein Arbeitselement erstellen, um nachzuverfolgen, wie das Problem behoben wurde. Sie können den Arbeitselementtyp angeben und Optionen festlegen, um ihn automatisch dem Anforderer oder anderen Feldern zuzuweisen. Der Anforderer entspricht der Person, die den Build ausgelöst hat.

Tipp

Die Option Arbeitselement bei Fehler erstellen wird nur für klassische Pipelines unterstützt. Um dies mit einer YAML-Pipeline zu erreichen, können Sie eine Marketplace-Erweiterung wie Fehler bei Releasefehler erstellen verwenden, oder Sie führen die Implementierung selbst mit der Azure CLI oder REST-API-Aufrufen aus.

  1. Öffnen Sie die Build-Optionen der Pipeline, wie unter Build-Eigenschaften beschrieben.

  2. Aktivieren Sie Arbeitselement bei Fehler erstellen, und wählen Sie den Typ des zu erstellenden Arbeitselements aus. Aktivieren Sie optional das Kontrollkästchen Anforderer zuweisen , um das Feld Zuweisen an festzulegen und Felder hinzuzufügen, die innerhalb des zu erstellenden Arbeitselements festgelegt werden sollen.

    Hier wählen wir beispielsweise den Arbeitselementtyp „Fehler“ aus und geben die Felder „Priority“ (Priorität) und „Tags“ sowie deren Werte an.

    Screenshot: „Arbeitselement bei Fehler erstellen“ in den Erstellungsoptionen.

  3. Ihre Pipeline speichern.

Um den Verweisnamen für ein Feld zu ermitteln, suchen Sie nach ihm im Feldindex des Arbeitselements. Für benutzerdefinierte Felder, die Sie über einen geerbten Prozess hinzufügen, weist Azure DevOps einen Verweisnamen basierend auf dem Anzeigefeldnamen zu, der mit dem Präfix Benutzerdefiniert versehen wird. Beispielsweise fügen Sie ein Feld mit dem Namen DevOps Triage hinzu. Der Verweisname lautet dann „Custom.DevOpsTriage“. Innerhalb des Verweisnamens sind keine Leerzeichen zulässig.

Abrufen oder Aktivieren eines Statusbadges

  1. Öffnen Sie die Pipeline Weitere Aktionen, und wählen Sie Statusbadge aus.

    Screenshot: Menüoptionen „Weitere Aktionen“ der YAML-Pipeline.

  2. Wählen Sie den gewünschten Branch und Interessenbereich aus, und wählen Sie dann In Zwischenablage kopieren aus, um das Image oder die Markdownsyntax zu kopieren.

    Screenshot: Statusbadge der YAML-Pipeline.

Status der Bereitstellung an den Repository-Host melden (Klassisch)

Wenn Sie Code in einem Azure Repos Git-Repository speichern, können Sie Ihre Releasepipeline so konfigurieren, dass ein Signal auf den Azure Repos-Seiten angezeigt wird. Das Badge gibt an, wo der bestimmte Commit bereitgestellt wurde und ob die Bereitstellung erfolgreich ist oder fehlschlägt. Diese Option verbessert die Nachvollziehbarkeit vom Code-Commit bis zur Bereitstellung.

Screenshot der Integrationsoptionen für Classic-Pipelines, Bereitstellungsstatus an den Host des Repositorys melden

Der Bereitstellungsstatus wird in den folgenden Abschnitten von Azure Repos angezeigt:

  • Dateien: Zeigt den Status der letzten Bereitstellung für den ausgewählten Zweig an.
  • Commits: Zeigt den Bereitstellungsstatus für jeden Commit an (erfordert, dass der Continuous Integration (CD)-Trigger für Ihre Version aktiviert ist).
  • Zweige: Zeigt den Status der letzten Bereitstellung für den ausgewählten Zweig an.

Wenn ein Commit für mehrere Releasepipelines (mit mehreren Umgebungen) bereitgestellt wird, verfügt jede davon über einen Eintrag im Badge und der Status wird für jede Umgebung angezeigt. Wenn Sie eine Releasepipeline erstellen, wird standardmäßig der Bereitstellungsstatus für alle Phasen angezeigt. Sie können jedoch selektiv die Phasen auswählen, für die der Bereitstellungsstatus im Status-Badge angezeigt werden soll (z. b. nur die Produktionsphase anzeigen). Die Teammitglieder können das Statusbadge auswählen, um den aktuellen Bereitstellungs-Status für die einzelnen ausgewählten Phasen der Releasepipelines anzuzeigen.

Bereitstellungsstatus an Jira melden (Klassisch)

Schließen Sie Jira-Probleme in Arbeitsaufgaben ein, und erstellen Sie Links zu allen Problemen beim Abschluss der Phase. Installieren Sie Azure Pipelines für Jira-App in der JIRA Software-Cloud, und fügen Sie Organisation hinzu, um eine Verbindung zu erstellen.

Screenshot der Integrationsoptionen für Classic-Pipelines, Bereitstellungsstatus an Jira melden

Um die Integration mit der Jira-Problemverfolgung zu unterstützen, installieren Sie die Azure Pipelines-Integration in Jira und verbinden Sie Ihre Azure DevOps-Organisationen mit Ihrer Jira Software-Instanz. Sie können mehrere Organisationen mit einer Instanz verbinden und Daten für alle Ihre Teams und verwandten Projekte abrufen. Erfahren Sie mehr über die Einrichtung der Integration in unserer Dokumentation. Weitere Informationen zur Installation und Einrichtung finden Sie unter Integration in Jira – Problemverfolgung.