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. Der Link In Releaseumgebung integriert kann nur erstellt werden, indem die Option Releasestatus an Boards melden in klassischen Releasepipelines aktiviert wird.

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. Weitere 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. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Automatisches Verknüpfen von Arbeitselementen.

YAML, Azure DevOps Server 2020 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. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Bereitstellungsstatus an Boards melden.

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

---

Erstellen eines Arbeitselements bei Fehlern (klassisch)

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

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

YAML

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

   

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

   

Klassischer Build

Buildeigenschaften

Öffnen Sie die Buildpipeline, wählen Sie „Pipeline bearbeiten“ aus, und wählen Sie dann die Registerkarte Optionen aus.

Die Seite „Buildeigenschaften“ wird angezeigt.

Weitere Informationen zu den einzelnen Einstellungen finden Sie unter den folgenden Links:

• Buildnummernformat
• Automatisches Verknüpfen von Arbeitselementen
• Erstellen eines Arbeitselements bei Fehlern
• Statussignal

Klassisches Release

Optionen für Releaseintegration

Öffnen Sie für klassische Releasepipelines Pipelines>Releases, wählen Sie „Bearbeiten“ aus, und wählen Sie dann Optionen und anschließend Integrationen aus.

Weitere Informationen zu den einzelnen Einstellungen finden Sie unter den folgenden Links:

• Status der Bereitstellung an den Repository-Host melden
• Bereitstellungsstatus an Arbeitselemente melden
• Bereitstellungsstatus an Boards melden
• Bereitstellungsstatus an Jira melden
• Badge zum Bereitstellungsstatus aktivieren

Automatisches Verknüpfen von Arbeitselementen mit Builds oder Releases

Durch das Aktivieren der automatischen 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 Arbeitselementformulars angezeigt. Jede erfolgreiche Releasestage, die dem Arbeitselement zugeordnet ist, wird automatisch im Steuerelement Entwicklung des Arbeitsaufgabenformulars angezeigt.

YAML

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

2. Aktivieren Sie Neue Arbeit 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.

Klassischer Build

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

2. Aktivieren Sie In dieser Ausführung enthaltene Arbeitselemente automatisch verknüpfen. Fügen Sie die Branches hinzu, die eingeschlossen oder ausgeschlossen werden sollen.
   

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

   Um eine Liste der mit dem Build verknüpften Arbeitselemente anzuzeigen, wählen Sie auf der Seite „Zusammenfassung“ die zugehörige Verknüpfung aus.

   

3. Ihre Pipeline speichern.

Klassisches Release

Bevor Sie Integrationsoptionen auswählen, sollten Sie die Releasestages einrichten, wie unter Definieren Ihrer mehrstufigen Continuous Deployment-Pipeline (CD) beschrieben.

1. Öffnen Sie Optionen>Integrationen für die Releasepipeline, wie unter Optionen für Releaseintegration beschrieben.

2. Aktivieren Sie das Kontrollkästchen Bereitstellungsstatus an Boards melden. Ordnen Sie den Bereitstellungstyp jeder Stage zu, oder belassen Sie ihn als Nicht zugeordnet. Wählen Sie diese Option, wenn Sie nach Abschluss einer Freigabe Verknüpfungen zu allen Arbeitselementen erstellen möchten, die zugehörige Änderungen an der Quelle darstellen. Diese Option muss aktiviert sein, damit das Steuerelement Bereitstellung des Arbeitselementformulars funktioniert.

   

   Um eine Liste der mit dem Release verknüpften Arbeitselemente anzuzeigen, wählen Sie unter Weitere Befehle die Option Release (alte Ansicht) und dann die Registerkarte Arbeitselemente aus.

   

3. Ihre Pipeline speichern.

Überprüfen der Integration

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Integration funktioniert:

1. Verknüpfen Sie mindestens ein Arbeitselement mit einem Commit oder Pull Request im Git-Repository von Azure Repos. Weitere Informationen finden Sie unter:

   • Steuern der Git-Entwicklung aus einem Arbeitselement
   • Verknüpfen von Arbeitselementen mit anderen Objekten

2. Ausführen der Pipeline.

3. Öffnen Sie eines der verknüpften Arbeitselemente, und zeigen Sie das Steuerelement Bereitstellung an. Wie in der folgenden Abbildung dargestellt, zeigt das Steuerelement Bereitstellung Releaseinformationen für zwei Releasestages der Arbeitselemente an, die mit einem Git-Commit oder -Pull Request für eine für die Integration in Azure Boards konfigurierte Releasepipeline verknüpft wurden.

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

Wenn Sie Arbeitselemente automatisch mit Builds verknüpfen, 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.

   

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

YAML

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

   

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.

   

Klassischer Build

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

2. Wählen Sie In Zwischenablage kopieren aus, um das Image oder die Markdownsyntax zu kopieren.

   

3. Ihre Pipeline speichern.

Klassisches Release

Wählen Sie diese Option, wenn Sie das letzte Ergebnis einer Stufenbereitstellung auf einer externen Website anzeigen möchten.

1. Aktivieren Sie das Kontrollkästchen Statusbadge der Bereitstellung aktivieren. Wählen Sie dann die Stages aus, für die Sie das Ergebnis anzeigen möchten. Standardmäßig sind alle für das Release definierten Stages ausgewählt.

   

2. Wählen Sie In Zwischenablage kopieren aus, um das Image oder die Markdownsyntax zu kopieren.

   

3. Ihre Pipeline speichern.

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.

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.

Um die Integration mit der Jira-Problemverfolgung zu unterstützen, installieren Sie Azure DevOps für 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. Weitere Informationen finden Sie unter Verbinden von Azure DevOps mit Jira.

Verwandte Artikel

• Definieren einer mehrstufigen Continuous Deployment-Pipeline (CD)
• Verknüpfen von Arbeitselementen mit anderen Objekten
• Übersicht über Releasepipelines (klassisch)
• Abrufen aller Arbeitselemente, die einer Releasepipeline zugeordnet sind, mithilfe der Azure DevOps-API
• Steuern der Git-Entwicklung aus einem Arbeitselement
• Verknüpfen von Arbeitselementen mit anderen Objekten
• End-to-End-Nachverfolgbarkeit
• Referenzhandbuch für Linktypen