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
Öffnen der Pipelineeinstellungen
Für durch YAML definierte Releasepipelines konfigurieren Sie die Integration über das Dialogfeld Pipelineeinstellungen.
Ö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.
Diese Einstellung ist für Azure DevOps Server 2019 oder früheren Versionen nicht verfügbar.
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.
Automatisches Verknüpfen von Arbeitselementen mit Builds
Durch das Aktivieren der automatischen 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 Arbeitselementformulars angezeigt.
Öffnen Sie Pipelineeinstellungen wie unter Öffnen von Pipelineeinstellungen beschrieben.
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.
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).
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.
Öffnen Sie die Build-Optionen der Pipeline, wie unter Build-Eigenschaften beschrieben.
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.
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
Öffnen Sie die Pipeline Weitere Aktionen, und wählen Sie Statusbadge aus.
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.
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