Einschränken von Übergängen des Arbeitsaufgabenstatus

Nach mehreren Sprints in der Vorschau kündigen wir nun die allgemeine Version der Regeln für zustandsübergangseinschränkung für alle Kunden im Rahmen des Sprint 172-Updates an.

Weitere Informationen finden Sie in der Liste " Features" weiter unten.

Features

Azure Boards

• Regeln für Zustandsübergangseinschränkung
• Kopieren einer Arbeitsaufgabe zum Kopieren untergeordneter Elemente
• Verbesserte Regeln für aktivierte und aufgelöste Felder
• Systemaufgabentypen für Backlogs und Boards (private Vorschau)

Azure Pipelines

• Exklusive Bereitstellungssperresrichtlinie
• Phasenfilter für Pipelineressourcentrigger
• Generische Webhook-basierte Trigger für YAML-Pipelines
• YaML-Ressourcen lösen Probleme zur Unterstützung und Rückverfolgbarkeit aus
• Banner für Live-Site-Vorfälle, die sich auf Pipelines auswirken

Azure Artifacts

• Möglichkeit zum Erstellen von organisationsbezogenen Feeds über die Benutzeroberfläche

Azure Boards

Regeln für Zustandsübergangseinschränkung

Nach mehreren Sprints der privaten Vorschau sind Regeln für Zustandsübergangseinschränkungen jetzt allgemein für alle Kunden verfügbar. Diese neue Arbeitsaufgabentypregel ermöglicht es Ihnen, arbeitsaufgaben von einem Zustand in einen anderen zu verschieben. Sie können z. B. verhindern, dass Fehler von "Neu" zu "Gelöst" wechseln. Stattdessen müssen sie von "Neu" –> "Aktiv" –> "Gelöst" wechseln.

Sie können auch eine Regel erstellen, um Statusübergänge nach Gruppenmitgliedschaft einzuschränken. Beispielsweise können nur Benutzer in der Gruppe "Genehmigende Personen" Benutzergeschichten aus "Neu –> Genehmigt" verschieben.

Kopieren einer Arbeitsaufgabe zum Kopieren untergeordneter Elemente

Eine der wichtigsten angeforderten Features für Azure Boards ist die Möglichkeit, eine Arbeitsaufgabe zu kopieren, die auch die untergeordneten Arbeitsaufgaben kopiert. In diesem Sprint haben wir dem Dialogfeld "Arbeitsaufgabe kopieren" eine neue Option "Untergeordnete Arbeitsaufgaben einschließen" hinzugefügt. Wenn diese Option ausgewählt ist, wird die Arbeitsaufgabe kopiert und alle untergeordneten Arbeitsaufgaben (bis zu 100) kopiert.

Verbesserte Regeln für aktivierte und aufgelöste Felder

Bisher waren die Regeln für "Aktiviert von", "Aktiviert am", "Gelöst am" und "Gelöst am" ein Geheimnis. Sie werden nur für Systemaufgabentypen festgelegt und sind spezifisch für den Statuswert "Aktiv" und "Aufgelöst". In Sprint 172 haben wir die Logik so geändert, dass diese Regeln nicht mehr für einen bestimmten Zustand gelten. Stattdessen werden sie durch die Kategorie (Statuskategorie) ausgelöst, in der sich der Zustand befindet. Angenommen, Sie haben in der Kategorie "Aufgelöst" den benutzerdefinierten Status "Anforderungen testen". Wenn sich die Arbeitsaufgabe von "Aktiv" in "Bedarfstests" ändert, werden die Regeln "Gelöst nach" und "Gelöst am" ausgelöst.

Auf diese Weise können Kunden benutzerdefinierte Statuswerte erstellen und weiterhin die Felder "Aktiviert nach", "Aktiviert am", "Aufgelöst von" und "Aufgelöstes Datum" generieren, ohne benutzerdefinierte Regeln verwenden zu müssen.

Systemaufgabentypen für Backlogs und Boards (private Vorschau)

Seit Dem Beginn des Vererbungsprozessmodells wurden mehrere Arbeitsaufgabentypen nicht mehr zu Boards und Backlogs hinzugefügt. Zu diesen Arbeitsaufgabentypen gehören:

Ab diesem Sprint wird eine private Vorschau für Kunden zugelassen, die diese Arbeitsaufgabentypen auf jeder Backlog-Ebene verfügbar machen möchten.

Wenn Sie an der Vorschau dieses Features interessiert sind, senden Sie uns bitte eine E-Mail mit Ihrem Organisationsnamen, und wir können Ihnen Zugriff gewähren.

Azure Pipelines

Exklusive Bereitstellungssperresrichtlinie

Mit diesem Update können Sie sicherstellen, dass jeweils nur eine einzelne Ausführung in einer Umgebung bereitgestellt wird. Wenn Sie die "Exklusive Sperre" für eine Umgebung auswählen, wird nur eine Ausführung fortgesetzt. Nachfolgende Ausführungen, die in dieser Umgebung bereitgestellt werden sollen, werden angehalten. Sobald die Ausführung mit der exklusiven Sperre abgeschlossen ist, wird die neueste Ausführung fortgesetzt. Alle Zwischenläufe werden abgebrochen.

Phasenfilter für Pipelineressourcentrigger

In diesem Sprint haben wir Unterstützung für "Phasen" als Filter für Pipelineressourcen in YAML hinzugefügt. Mit diesem Filter müssen Sie nicht warten, bis die gesamte CI-Pipeline abgeschlossen ist, um die CD-Pipeline auszulösen. Sie können ihre CD-Pipeline jetzt nach Abschluss einer bestimmten Phase in Ihrer CI-Pipeline auslösen.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Wenn die im Triggerfilter bereitgestellten Phasen in Ihrer CI-Pipeline erfolgreich abgeschlossen werden, wird automatisch eine neue Ausführung für Ihre CD-Pipeline ausgelöst.

Generische Webhook-basierte Trigger für YAML-Pipelines

Heute verfügen wir über verschiedene Ressourcen (z. B. Pipelines, Container, Build und Pakete), über die Sie Artefakte nutzen und automatisierte Trigger aktivieren können. Bisher konnten Sie Ihren Bereitstellungsprozess jedoch nicht basierend auf anderen externen Ereignissen oder Diensten automatisieren. In dieser Version führen wir die Unterstützung von Webhook-Triggern in YAML-Pipelines ein, um die Integration der Pipelineautomatisierung mit jedem externen Dienst zu ermöglichen. Sie können externe Ereignisse über ihre Webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory usw.) abonnieren und Ihre Pipelines auslösen.

Hier sind die Schritte zum Konfigurieren der Webhook-Trigger:

1. Richten Sie einen Webhook für Ihren externen Dienst ein. Beim Erstellen ihres Webhooks müssen Sie die folgenden Informationen angeben:

   • Anforderungs-URL – "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Geheim – Dies ist optional. Wenn Sie Ihre JSON-Nutzlast sichern müssen, geben Sie den Geheimwert an.

2. Erstellen Sie eine neue Dienstverbindung vom Typ „Eingehender Webhook“. Dies ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie drei wichtige Informationen definieren können:

   • Webhookname: Der Name des Webhooks sollte dem in Ihrem externen Dienst erstellten Webhook entsprechen.
   • HTTP-Header – Der Name des HTTP-Headers in der Anforderung, der den Nutzlasthashwert für die Anforderungsüberprüfung enthält. Im Fall von GitHub lautet der Anforderungsheader beispielsweise "X-Hub-Signature"
   • Geheimer Schlüssel – Der geheime Schlüssel wird verwendet, um den Nutzlasthash zu analysieren, der zur Überprüfung der eingehenden Anforderung verwendet wird (dies ist optional). Wenn Sie beim Erstellen Ihres Webhooks einen geheimen Schlüssel verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.

   

3. Ein neuer Ressourcentyp namens webhooks wird in YAML-Pipelines eingeführt. Zum Abonnieren eines Webhook-Ereignisses müssen Sie eine Webhook-Ressource in Ihrer Pipeline definieren und auf die Eingehende Webhook-Dienstverbindung verweisen. Sie können auch zusätzliche Filter für die Webhook-Ressource basierend auf den JSON-Nutzlastdaten definieren, um die Trigger für jede Pipeline weiter anzupassen, und Sie können die Nutzlastdaten in Form von Variablen in Ihren Aufträgen verwenden.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Wenn ein Webhook-Ereignis von der Eingehenden Webhook-Dienstverbindung empfangen wird, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhook-Ereignis abonniert haben.

Unterstützung und Nachverfolgbarkeit bei YAML-Ressourcentriggerproblemen

Es kann verwirrend sein, wenn Pipelinetrigger nicht ausgeführt werden, wie sie erwartet werden. Um dies besser zu verstehen, haben wir ein neues Menüelement auf der Pipelinedefinitionsseite namens "Trigger Issues" hinzugefügt, bei dem Informationen dazu angezeigt werden, warum Trigger nicht ausgeführt werden.

Ressourcentrigger können aus zwei Gründen nicht ausgeführt werden.

1. Wenn die Quelle der bereitgestellten Dienstverbindung ungültig ist oder syntaxfehler im Trigger vorhanden sind, wird der Trigger überhaupt nicht konfiguriert. Diese werden als Fehler angezeigt.

2. Wenn Triggerbedingungen nicht übereinstimmen, wird der Trigger nicht ausgeführt. Wenn dies geschieht, wird eine Warnung angezeigt, damit Sie verstehen können, warum die Bedingungen nicht übereinstimmen.

   

Banner für Live-Site-Vorfälle, die sich auf Pipelines auswirken

Wir haben der Pipelineseite ein Warnbanner hinzugefügt, um Benutzer über laufende Vorfälle in Ihrer Region zu informieren, was sich auf Ihre Pipelines auswirken kann.

Azure Artifacts

Möglichkeit zum Erstellen von organisationsbezogenen Feeds über die Benutzeroberfläche

Wir bringen die Möglichkeit für Kunden zurück, durch die Web-UI sowohl lokale als auch gehostete Dienste zu erstellen und zu verwalten.

Sie können jetzt organisationsbezogene Feeds über die Benutzeroberfläche erstellen, indem Sie zu Artefakte> – Feed erstellen und einen Feedtyp im Bereich auswählen.

Es wird zwar empfohlen, projektbezogene Feeds in Übereinstimmung mit den restlichen Azure DevOps-Angeboten zu verwenden, Sie können jedoch auch wieder feeds mit Organisationsbereich über die Benutzeroberfläche und verschiedene REST-APIs erstellen, verwalten und verwenden. Weitere Informationen finden Sie in unserer Feeds-Dokumentation.

Nächste Schritte

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Aaron Hallberg