Versionshinweise zu Azure DevOpsServer 2020 Update 1

Developer Community | System RequirementsLicense | Terms | DevOps Blog | SHA-1 Hashes

In diesem Artikel finden Sie Informationen zum neuesten Release für Azure DevOps Server.

Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server finden Sie unter Azure DevOps Server Anforderungen. Besuchen Sie Azure DevOps Downloadseite, um Azure DevOps Server Azure DevOps herunterladen.

Direkte Upgrades auf Azure DevOps Server 2020 werden ab Azure DevOps Server 2019 oder Team Foundation Server 2015 oder neuer unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2019 durchführen. Weitere Informationen finden Sie unter Installieren und Konfigurieren Azure DevOps lokalen .


Azure DevOps Server 2020.1.1 Patch 2 Release Date: 26. Oktober 2021

Patch 2 für Azure DevOps Server 2020.1.1 enthält Fehlerbehebungen für Folgendes.

  • Bisher konnten Azure DevOps Server nur Verbindungen mit GitHub Enterprise Erstellen. Mit diesem Patch können Projektadministratoren Verbindungen zwischen Azure DevOps Server und Repositorys auf GitHub.com herstellen. Sie finden diese Einstellung auf der Seite GitHub Verbindungen unter Project Einstellungen.
  • Beheben Sie das Problem mit dem Testplanwidget. Im Testausführungsbericht wurde ein falscher Benutzer in den Ergebnissen angezeigt.
  • Es wurde ein Problem behoben, Project Zusammenfassungsseite der Übersicht nicht geladen werden konnte.
  • Es wurde ein Problem behoben, bei dem E-Mails nicht gesendet wurden, um das Produktupgrade zu bestätigen.

Azure DevOps Server Veröffentlichungsdatum 2020.1.1 Patch 1: 14. September 2021

Patch 1 für Azure DevOps Server 2020.1.1 enthält Fehlerbehebungen für Folgendes.

  • Korrektur Artifacts Download-/Uploadfehlers.
  • Beheben Sie das Problem mit inkonsistenten Testergebnisse Daten.

Azure DevOps Server Veröffentlichungsdatum von Update 1.1 2020: 17. August 2021

Azure DevOps Server 2020 Update 1.1 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020 Update 1.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder neuer durchführen.

Hinweis

Das Datenmigrationstool ist für Azure DevOps Server 2020 Update 1.1 etwa drei Wochen nach diesem Release verfügbar. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Diese Version enthält Korrekturen für folgende Fehler:

Azure Boards

  • Der Link "Arbeitselement anzeigen" in den Benachrichtigungs-E-Mails verwendet nicht die öffentliche URL.

Azure Repos

  • Die Kontrollkästchen für die Vererbung eingeschränkter Mergetypen wurden korrigiert, um das Ändern von Limit-Mergetypen nach dem Festlegen repositoryübergreifender Richtlinien zu aktivieren.

Azure Pipelines

  • Beim Ändern der Einstellung für agent update wurden die Einstellungen nicht an andere Anwendungsebenen in der Umgebung propagiert.

Allgemein

  • Die Rechtschreibung im Serverkonfigurations-Assistenten wurde korrigiert.
  • Die Größe des Erweiterungspakets wurde erhöht, und Sie können die Größe in der Registrierung ändern.

Azure Test Plans

  • Es ist nicht möglich, zurück zu den Testergebnissen zu navigieren, sobald Sie vom Verlauf zur Zusammenfassungsseite zurückkommen.

Azure DevOps Server 2020.1 Patch 2 Release Date: 10. August 2021

Wir haben einen Patch für Azure DevOps Server 2020.1 veröffentlicht, der Folgendes korrigiert.

  • Benutzeroberflächenfehler der Builddefinition behoben.
  • Der Browserverlauf wurde geändert, um Dateien anstelle des Stammrepositorys anzuzeigen.

Azure DevOps Server Veröffentlichungsdatum 2020.1 Patch 1: 15. Juni 2021

Wir haben einen Patch für Azure DevOps Server 2020.1 veröffentlicht, der Folgendes korrigiert.

  • Sichere Cookies, die in Autorisierungsflüssen verwendet werden, die die -Berechtigung SameSite=None gewährleisten.

  • Beheben Sie das Problem mit dem Notifications SDK. Zuvor wurden Benachrichtigungsabonnements, die den Filter Bereichspfad verwenden, nicht ordnungsgemäß analysiert.

Azure DevOps Server Veröffentlichungsdatum 2020.1 RTW: 25. Mai 2021

Zusammenfassung der Neuen in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerbehebungen. Es enthält alle Features im Azure DevOps Server 2020.1 RC2, das zuvor veröffentlicht wurde. Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2020, 2019 oder Team Foundation Server 2015 oder neuer durchführen.

Hinweis

Das Datenmigrationstool ist für Azure DevOps Server 2020 Update 1 etwa drei Wochen nach diesem Release verfügbar. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Azure DevOps Server 2020.1 RC2 Veröffentlichungsdatum: 13. April 2021

Zusammenfassung der Neuen in Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features im Azure DevOps Server 2020.1 RC1, das zuvor veröffentlicht wurde.

Azure DevOps Server 2020.1 RC1 Veröffentlichungsdatum: 23. März 2021

Zusammenfassung der Neuen in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 führt viele neue Features ein. Einige der Highlights sind unter anderem:

Sie können auch zu einzelnen Abschnitten springen, um alle neuen Features für jeden Dienst zu sehen:


Boards

Regeln für die Einschränkung des Zustandsübergangs

Wir schließen weiterhin die Featureparitätslücke zwischen gehosteter XML und dem geerbten Prozessmodell. Mit dieser neuen Regel des Arbeitselementtyps können Sie einschränken, dass Arbeitselemente von einem Zustand in einen anderen verschoben werden. Beispielsweise können Sie verhindern, dass Fehler von Neu zu Gelöst gehen. Stattdessen müssen sie von Neu – Aktiv > – Aufgelöst > wechseln.

Abbildung

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

Kopieren eines Arbeitselements zum Kopieren von unteren Elemente

Eines der am meisten angeforderten Features für Azure Boards ist die Möglichkeit, ein Arbeitselement zu kopieren, das auch die untergeordneten Arbeitselemente kopiert. Wir haben dem Dialogfeld "Arbeitselement kopieren" eine neue Option zum Einfügen untergeordneter " " Arbeitselemente hinzugefügt. Wenn diese Option ausgewählt ist, kopiert diese Option das Arbeitselement und alle untergeordneten Arbeitselemente (bis zu 100).

Diese Seite zeigt die neue Option in Azure Boards untergeordnete Arbeitselemente in ein kopiertes Arbeitselement ein.

Verbesserte Regeln für aktivierte und aufgelöste Felder

Bisher waren die Regeln für Activated By, Activated Date, Resolved By und Resolved Date eine Veröffentlichung. Sie werden nur für Systemarbeitselementtypen festgelegt und sind spezifisch für den Zustandswert "Aktiv" und "Aufgelöst". Wir haben die Logik so geändert, dass diese Regeln nicht mehr für einen bestimmten Zustand gelten. Stattdessen werden sie durch die Kategorie (Zustandskategorie) ausgelöst, in der sich der Zustand befindet. Angenommen, Sie verfügen in der Kategorie Aufgelöst über den benutzerdefinierten Status "Tests werden benötigt". Wenn sich das Arbeitselement von "Aktiv" in "Tests benötigt" ändert, werden die Regeln Aufgelöst nach und Aufgelöstes Datum ausgelöst.

Dadurch können Kunden benutzerdefinierte Statuswerte erstellen und trotzdem die Felder Activated By, Activated Date, Resolved By und Resolved Date generieren, ohne benutzerdefinierte Regeln verwenden zu müssen.

Beteiligte können Arbeitselemente über Boardspalten hinweg verschieben.

Projektbeteiligten war es immer möglich, den Status von Arbeitselementen zu ändern. Wenn sie jedoch zum Kanban-Board wechseln, können sie die Arbeitselemente nicht von einer Spalte in eine andere verschieben. Stattdessen müssten Die Projektbeteiligten jedes Arbeitselement nacheinander öffnen und den Zustandswert aktualisieren. Dies ist für Kunden schon lange ein Kinderpunkt, und wir freuen uns, ihnen mitteilen zu können, dass Sie nun Arbeitselemente über Boardspalten hinweg verschieben können.

Systemarbeitselementtypen in Backlogs und Boards

Nun können Sie der Backlogebene der Wahl einen Arbeitselementtyp des Systems hinzufügen. In der Vergangenheit waren diese Arbeitselementtypen nur über Abfragen verfügbar.

Prozess Arbeitselementtyp
Agilität Problem
Scrum Impediment
CMMI Change Request
Problem
Überprüfung
Risiko

Das Hinzufügen eines Systemarbeitselementtyps zu einer Backlogebene ist einfach. Wechseln Sie einfach zu Ihrem benutzerdefinierten Prozess, und klicken Sie auf die Registerkarte Backlogebenen. Wählen Sie Die Backlogebene Ihrer Wahl aus (Beispiel: Anforderungsrückstand), und wählen Sie die Bearbeitungsoption aus. Fügen Sie dann den Arbeitselementtyp hinzu.

backlogs

Azure Boards GitHub des App-Repositorys erhöht

Das Repositorylimit für die Azure Boards-Anwendung im GitHub Marketplace wurde von 100 auf 250 erhöht.

Anpassen des Arbeitselementzustands beim Zusammengeführten des Pull Requests

Nicht alle Workflows sind identisch. Einige Kunden möchten ihre zugehörigen Arbeitselemente schließen, wenn ein Pull Request abgeschlossen ist. Andere möchten die Arbeitselemente auf einen anderen Zustand festlegen, der vor dem Schließen überprüft werden soll. Wir sollten beides zulassen.

Wir haben ein neues Feature, mit dem Sie die Arbeitselemente auf den gewünschten Zustand festlegen können, wenn der Pull Request zusammengeführt und abgeschlossen wird. Hierzu überprüfen wir die Pull Request-Beschreibung und suchen nach dem Zustandswert, gefolgt von #mention arbeitselement(n). In diesem Beispiel setzen wir zwei User Storys auf Gelöst und schließen zwei Aufgaben.

work-item-state

Sie können Ihre Buildabhängigkeiten jetzt problemlos projektübergreifend nachverfolgen, indem Sie Ihr Arbeitselement einfach mit einem Build, im Build gefunden oder im Build integriert verknüpfen.

Verknüpfen von Arbeitselementen

Bearbeiten einer Beschreibung (Hilfetext) für Systemfelder

Sie konnten die Beschreibung von benutzerdefinierten Feldern schon immer bearbeiten. Für Systemfelder wie Priorität, Schweregrad und Aktivität war die Beschreibung jedoch nicht bearbeitbar. Dies war eine Featurelücke zwischen gehosteter XML und Geerbter, die einige Kunden daran gehindert hat, zum geerbten Modell zu migrieren. Sie können jetzt die Beschreibung für Systemfelder bearbeiten. Der bearbeitete Wert wirkt sich nur auf dieses Feld im Prozess und für diesen Arbeitselementtyp aus. Dies bietet Ihnen die Flexibilität, unterschiedliche Beschreibungen für dasselbe Feld für verschiedene Arbeitselementtypen zu verwenden.

Beschreibung bearbeiten

Anpassen des Arbeitselementzustands beim Zusammengeführten des Pull Requests

Pull Requests verweisen häufig auf mehrere Arbeitselemente. Wenn Sie einen Pull Request erstellen oder aktualisieren, sollten Sie einige davon schließen, einige davon auflösen und den Rest geöffnet lassen. Sie können jetzt Kommentare wie die in der folgenden Abbildung gezeigten verwenden, um dies zu erreichen. Weitere Informationen finden Sie in der Dokumentation.

Customize state

Übergeordnetes Feld auf dem Task board

Aufgrund einer häufig gestellten Anforderung können Sie jetzt das Feld Übergeordnetes Element sowohl der untergeordneten als auch der übergeordneten Karte auf dem Task Board hinzufügen.

parent field task board

Entfernen der regel "Zugewiesen zu" für den Arbeitselementtyp "Fehler"

Es gibt mehrere ausgeblendete Systemregeln für alle verschiedenen Arbeitselementtypen in Agile, Agile und CMMI. Diese Regeln gibt es seit mehr als zehn Jahren und funktionieren in der Regel einwandfrei, ohne dass es zu Beanstandungen gab. Es gibt jedoch eine Reihe von Regeln, deren Begrüßung aus ist. Insbesondere eine Regel hat für neue und vorhandene Kunden viele Probleme verursacht, und wir haben entschieden, dass es an der Zeit ist, sie zu entfernen. Diese Regel ist für den Arbeitselementtyp Fehler im Agile-Prozess vorhanden.

"Legen Sie den Zugewiesenen Wert auf Erstellt von fest, wenn der Zustand in Aufgelöst geändert wird.

Wir haben viel Feedback zu dieser Regel erhalten. Als Antwort haben wir diese Regel aus dem Arbeitselementtyp Fehler im Agile-Prozess entfernt. Diese Änderung wirkt sich auf jedes Projekt aus, das einen geerbten Agile-Prozess oder einen angepassten geerbten Agile-Prozess verwendet. Kunden, die diese aktuelle Regel verwenden und davon abhängig sind, finden in unserem Blogbeitrag informationen zu den Schritten, die Sie zum erneuten Hinzufügen der Regel in mithilfe benutzerdefinierter Regeln ausführen können.

Elemente auf der Seite "Arbeitselemente" entfernt

Die Seite Arbeitselemente ist ein hervorragender Ort, um unter anderem Elemente schnell zu finden, die Sie erstellt oder Ihnen zugewiesen haben. Es stellt mehrere personalisierte Pivots und Filter zur Verfügung. Eine der wichtigsten Beanstandungen für das Pivot "Zugewiesen zu mir" ist, dass entfernte Arbeitselemente (d. h. Arbeitselemente im Zustand Entfernt) angezeigt werden. Und wir stimmen zu! Entfernte Elemente sind Arbeitsaufgaben, die nicht mehr von Nutzen sind und daher aus dem Backlog entfernt wurden, sodass die Einbeziehung in diese Ansicht nicht hilfreich ist.

Sie können jetzt alle entfernten Elemente aus dem Pivot Zugewiesen zu mir auf der Seite Arbeitselemente ausblenden.

Repos

Standardeinstellung für Branchnamen

Azure Repos bietet jetzt einen anpassbaren Standardverzweigungsnamen für Git. In den Repositoryeinstellungen können Sie einen beliebigen Legal Branch-Namen auswählen, der beim Initialisieren eines Repositorys verwendet werden soll. Azure Repos hat das Ändern des Standardverzweigungsnamens für ein vorhandenes Repository immer unterstützt. Weitere Informationen finden Sie unter Verwalten von Branches.

 default-branch-name

Hinweis: Wenn Sie dieses Feature nicht aktivieren, werden Ihre Repositorys mit Azure Repos Standardnamen initialisiert. Derzeit ist dieser Standardwert master. Um die Verpflichtung von Microsoft zu und Kundenanforderungen für inklusive Sprache zu gleichen, werden wir branchenspezifischen Peers beitreten, um diese Standardeinstellung in "Main" zu ändern. Diese Änderung wird später in diesem Sommer auftreten. Wenn Sie weiterhin master verwenden möchten, sollten Sie dieses Feature jetzt aktivieren und auf master festlegen.

Einstellung auf Organisationsebene für Standardverzweigung

Es gibt jetzt eine Einstellung auf Sammlungsebene für Ihren bevorzugten Namen des ersten Branchs für neue Repositorys. Wenn ein Projekt keinen anfänglichen Branchnamen ausgewählt hat, wird diese Einstellung auf Organisationsebene verwendet. Wenn Sie den Ursprünglichen Branchnamen nicht in den Organisations- oder Projekteinstellungen angegeben haben, verwenden neue Repositorys Azure DevOps standarddefinierte Standardeinstellung.

branch setting for org level

Hinzufügen eines neuen Authentifizierungsbereichs zum Beitragen von PR-Kommentaren

Dieses Release fügt einen neuen OAuth-Bereich zum Lesen/Schreiben von Pull Request-Kommentaren hinzu. Wenn Sie über einen Bot oder eine Automatisierung verfügen, der nur mit Kommentaren interagieren muss, können Sie ihm ein PAT mit nur diesem Bereich geben. Dieser Prozess reduziert den Radius des Radius, wenn die Automatisierung einen Fehler auft, oder wenn das Token kompromittiert wurde.

Verbesserungen der Pull Request-Erfahrung

Die neue Pull Request-Erfahrung wurde durch Folgendes verbessert:

  • Machen Sie die optionalen Überprüfungen sichtbarer.

Kunden verwenden optionale Überprüfungen, um einen Entwickler auf potenzielle Probleme aufmerksam zu machen. In der vorherigen Erfahrung war es offensichtlich, wenn diese Überprüfungen fehlschlagen. Dies ist jedoch in der Vorschauversion nicht der Fall. Ein großes grünes Häkchen auf den erforderlichen Überprüfungen maskiert die Fehler in optionalen Überprüfungen. Benutzer konnten nur feststellen, dass optionale Überprüfungen fehlgeschlagen sind, indem sie den Prüfbereich öffnen. Entwickler tun dies nicht häufig, wenn es keinen Hinweis auf ein Problem gibt. In dieser Bereitstellung haben wir den Status optionaler Überprüfungen in der Zusammenfassung sichtbarer gemacht.


show the optional checks


  • STRG-Klicks auf Menüelemente

Tabstoppmenüs auf einem PR unterstützten STRG-Klick nicht. Benutzer öffnen häufig neue Browserregisterkarte, wenn sie einen Pull Request überprüfen. Dies wurde behoben.

  • Speicherort der [+]-Anmerkung

Die Strukturliste der Dateien in einem PR zeigt eine Anmerkung [+] an, um Autoren und Prüfern bei der Identifizierung neuer Dateien zu helfen. Da die Anmerkung nach den Auslassungsellipsen lag, war sie für längere Dateinamen oft nicht sichtbar.


show locations of annotations

  • Dropdownliste für PR-Updates: Zeitsteuerungsinformationen wiedererlangen

Die Dropdownliste zum Auswählen von Update- und Vergleichsdateien in einem PR hat ein wichtiges Element in der Vorschauversion verloren. Es wurde nicht gezeigt, wann dieses Update vorgenommen wurde. Dies wurde behoben.


PR updates dropdown missing timing information

  • **Verbessertes Kommentarfilterlayout **

Beim Filtern von Kommentaren auf der Zusammenfassungsseite eines Pull Requests befand sich das Dropdownfeld auf der rechten Seite, aber der Text wurde linksbündig ausgerichtet. Dies wurde behoben.


Improved comment filter layout

  • Navigation zu übergeordneten Commits

Auf der Seite Commits können Sie die Änderungen, die in einem bestimmten Commit vorgenommen wurden, mit dem übergeordneten Commit vergleichen. Möglicherweise möchten Sie jedoch zum übergeordneten Commit navigieren und weiter verstehen, wie sich dieser Commit von seinem eigenen übergeordneten Commit unterscheidet. Dies ist häufig erforderlich, wenn Sie alle Änderungen in einem Release verstehen möchten. Wir haben einem Commit eine(n) übergeordnete(n) Karte(en) hinzugefügt, damit Sie dies erreichen können.


Navigation to parent commits

  • Mehr Speicherplatz für Ordner und Dateien mit langen Namen auf der Registerkarte PR-Dateien

Ordner und Dateien mit langen Namen wurden aufgrund fehlender horizontaler Abstände in der Dateistruktur abgeschnitten. Wir haben zusätzlichen Platz in der Struktur wiederhergestellt, indem wir den Einzug der Struktur so geändert haben, dass er dem Stammknoten entspricht, und indem wir die Schaltfläche mit den Auslassungszeichen auf der Seite ausblenden, mit Ausnahme des Mauszeigers.

Abbildung der neuen Dateistruktur:


More space for folders and files

Abbildung der Dateistruktur beim Zeigen auf ein Verzeichnis:


Name display

  • Beibehalten der Scrollposition beim Ändern der Größe des Diff-Bereichs auf der Registerkarte "PR-Dateien"

Beim Ändern der Größe des Bereichs für parallele Unterschiede auf der Registerkarte PR-Dateien geht der Scrollspeicherort des Benutzers verloren. Dieses Problem wurde behoben. Die Bildlaufposition des Benutzers wird jetzt in einer Größenänderung des Vergleichsbereichs beibehalten.

  • Suchen nach einem Commit auf einem mobilen Gerät

Beim Anzeigen der Seite Commits auf einem mobilen Gerät fehlt das Suchfeld in der neuen Benutzeroberfläche. Daher ist es für Sie schwierig, einen Commit anhand seines Hashs zu finden und zu öffnen. Dies wurde jetzt behoben.


Search for a commit on a mobile device

  • Verbesserte Nutzung des Speicherplatzes für die neue mobile Ansicht "PR-Datei diff"

Wir haben diese Seite aktualisiert, um den Platz besser zu nutzen, sodass Benutzer mehr der Datei in mobilen Ansichten sehen können, anstatt 40 % des Bildschirms durch einen Header aufnehmen zu müssen.


Improved usage of space new PR filename

  • Verbesserte Bilder in der PR-Zusammenfassungsansicht

Bilder, die in einem PR bearbeitet wurden, wurden in der Pr-Zusammenfassungsansicht nicht angezeigt, wurden jedoch ordnungsgemäß in der Ansicht pr-Dateien angezeigt. Dieses Problem wurde behoben.

  • Verbesserte Verzweigungserfahrung beim Erstellen eines neuen PR

Vor diesem Update war diese Benutzeroberfläche nicht ideal, da die Änderungen mit dem Standardverzweigung des Repositorys und nicht mit dem Vergleichsverzweigung verglichen wurden.


branch experience enhancement

Pipelines

Zusätzliche Agent-Plattform: ARM64

Linux/ARM64 wurde der Liste der unterstützten Plattformen für den Azure Pipelines-Agent hinzugefügt. Obwohl die Codeänderungen minimal waren, mussten zunächst viele Hinter-den-Kulissen-Arbeiten abgeschlossen werden, und wir freuen uns, seine Veröffentlichung ankündigen zu können.

Tagfilterunterstützung für Pipelineressourcen

Wir haben nun "Tags" in YAML-Pipelines hinzugefügt. Sie können Tags verwenden, um festzulegen, ob die CI-Pipeline ausgeführt werden soll oder wann automatisch ausgelöst werden soll.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Der obige Codeausschnitt zeigt, dass Tags verwendet werden können, um die Standardversion der CI-Pipeline (Continuous Integration) zu bestimmen, die ausgeführt werden soll, wenn die CD-Pipelineausführung (Continuous Deployment) nicht von einer anderen Quelle/Ressource oder einem geplanten Ausführungstrigger ausgelöst wird.

Wenn Sie beispielsweise einen geplanten Trigger für Ihre CD-Pipeline festgelegt haben, den Sie nur ausführen möchten, wenn Ihr CI über das Produktionstag verfügt, stellen die Tags im Abschnitt triggers sicher, dass die CD-Pipeline nur ausgelöst wird, wenn die Markierungsbedingung durch das CI-Abschlussereignis erfüllt wird.

Steuern, welche Aufgaben in Pipelines zulässig sind

Sie können jetzt Marketplace-Aufgaben deaktivieren. Einige von Ihnen können Marketplace-Erweiterungen zulassen, aber nicht die Pipelines Aufgaben, die sie mit sich bringen. Um noch mehr Kontrolle zu erhalten, können Sie auch alle in der Box enthaltenen Aufgaben unabhängig deaktivieren (mit Ausnahme des Auscheckens, bei dem es sich um eine spezielle Aktion handelt). Wenn beide Einstellungen aktiviert sind, sind die einzigen Aufgaben, die in einer Pipeline ausgeführt werden dürfen, diejenigen, die mit tfxhochgeladen wurden. Besuchen Sie https://dev.azure.com/<your_org>/_settings/pipelinessettings den Abschnitt "Aufgabeneinschränkungen", und suchen Sie nach diesem Abschnitt, um zu beginnen.

Richtlinie für exklusive Bereitstellungssperre

Mit diesem Update können Sie sicherstellen, dass nur eine einzelne Ausführung gleichzeitig in einer Umgebung bereitgestellt wird. Wenn Sie die Überprüfung "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 letzte Ausführung fortgesetzt. Alle Zwischenläufe werden abgebrochen.

Wählen Sie auf der Seite Überprüfung hinzufügen die Option Exklusive Sperre aus, um sicherzustellen, dass nur eine einzelne Ausführung gleichzeitig in einer Umgebung bereitgestellt wird.

Stufenfilter für Pipelineressourcentrigger

Unterstützung für "Phasen" als Filter für Pipelineressourcen in YAML wurde hinzugefügt. Mit diesem Filter müssen Sie nicht warten, bis die gesamte CI-Pipeline abgeschlossen ist, um Ihre 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 angegebenen Phasen in Ihrer CI-Pipeline erfolgreich abgeschlossen wurden, wird automatisch eine neue Ausführung für Ihre CD-Pipeline ausgelöst.

Generische webhookbasierte 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 Webhooktriggern in YAML-Pipelines ein, um die Integration der Pipelineautomatisierung in beliebige externe Dienste zu ermöglichen. Sie können alle externen Ereignisse über die zugehörigen Webhooks (GitHub, GitHub Enterprise, Nexus, Aritfactory usw.) abonnieren und Ihre Pipelines auslösen.

Hier sind die Schritte zum Konfigurieren der Webhooktrigger:

  1. Richten Sie einen Webhook für Ihren externen Dienst ein. Wenn Sie Ihren Webhook erstellen, müssen Sie die folgenden Informationen angeben:

    • Anforderungs-URL : https://dev.azure.com/ <ADO collection> "/_apis/public/distributedtask/webhooks/<WebHookName>?api-version=6.0-preview"
    • Geheimnis: Dies ist optional. Wenn Sie Ihre JSON-Nutzlast schützen müssen, geben Sie den Wert secret an.
  2. Erstellen Sie eine neue Dienstverbindung "Eingehender Webhook". Dies ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie drei wichtige Informationen definieren können:

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

    Konfigurieren Sie auf der Seite Dienstverbindung bearbeiten Webhooktrigger.

  3. Ein neuer Ressourcentyp namens webhooks wird in YAML-Pipelines eingeführt. Zum Abonnieren eines Webhookereignisses müssen Sie eine Webhookressource in Ihrer Pipeline definieren und auf die Verbindung mit dem eingehenden Webhookdienst verweisen. Sie können auch zusätzliche Filter für die Webhookressource 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 nutzen.

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}}
  1. Wenn ein Webhookereignis von der Eingehenden Webhookdienstverbindung empfangen wird, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhookereignis abonniert haben.

Probleme beim YaML-Ressourcentrigger: Unterstützung und Nachverfolgbarkeit

Es kann verwirrend sein, wenn Pipelinetrigger nicht wie erwartet ausgeführt werden. Um dies besser zu verstehen, haben wir auf der Pipelinedefinitionsseite ein neues Menüelement namens "Triggerprobleme" hinzugefügt, in dem Informationen darüber 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 die 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.

    Diese Pipelinedefinitionsseite mit dem Namen Triggerprobleme zeigt Informationen dazu an, warum Trigger nicht ausgeführt werden.

Trigger mit mehreren Repositorys

Sie können mehrere Repositorys in einer YAML-Datei angeben und bewirken, dass eine Pipeline durch Updates für eines der Repositorys ausgelöst wird. Dieses Feature ist beispielsweise in den folgenden Szenarien nützlich:

  • Sie nutzen ein Tool oder eine Bibliothek aus einem anderen Repository. Sie möchten Tests für Ihre Anwendung ausführen, wenn das Tool oder die Bibliothek aktualisiert wird.
  • Sie speichern Ihre YAML-Datei in einem separaten Repository vom Anwendungscode. Sie möchten die Pipeline jedes Mal auslösen, wenn ein Update per Push an das Anwendungs-Repository übertragen wird.

Mit diesem Update funktionieren Trigger mit mehreren Repositorys nur für Git-Repositorys in Azure Repos. Sie funktionieren nicht für GitHub- oder BitBucket-Repositoryressourcen.

Hier sehen Sie ein Beispiel, das zeigt, wie sie mehrere Repositoryressourcen in einer Pipeline definieren und Trigger für alle konfigurieren.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Die Pipeline in diesem Beispiel wird ausgelöst, wenn Updates für Folgendes vorhanden sind:

  • main Branch im self Repository, das die YAML-Datei enthält
  • main oder release Branches im tools Repository

Weitere Informationen finden Sie unter Mehrere Repositorys in Ihrer Pipeline.

Agent-Protokolluploads verbessert

Wenn ein Agent die Kommunikation mit dem Azure Pipelines beendet, wird der ausgeführte Auftrag abgebrochen. Wenn Sie sich die Protokolle der Streamingkonsole ansingen, haben Sie möglicherweise einige Hinweise erhalten, bis der Agent nicht mehr reagiert hat. Wenn Sie die Seite jedoch nicht oder aktualisiert haben, waren diese Konsolenprotokolle nicht mehr verfügbar. Wenn der Agent in diesem Release nicht mehr reagiert, bevor er seine vollständigen Protokolle sendet, behalten wir die Konsolenprotokolle als das nächste Beste bei. Konsolenprotokolle sind auf 1.000 Zeichen pro Zeile beschränkt und können gelegentlich unvollständig sein, aber sie sind viel hilfreicher, als nichts zu zeigen! Die Untersuchung dieser Protokolle kann Ihnen bei der Problembehandlung Ihrer eigenen Pipelines helfen, und sie wird unseren Supporttechnikern sicherlich helfen, wenn sie bei der Problembehandlung helfen.

Optionales schreibgeschütztes Mounten von Containervolumes

Wenn Sie einen Containerauftrag in Azure Pipelines, werden mehrere Volumes, die den Arbeitsbereich, Aufgaben und andere Materialien enthalten, als Volumes zugeordnet. Diese Volumes verwenden standardmäßig Lese-/Schreibzugriff. Um die Sicherheit zu erhöhen, können Sie die Volumes schreibgeschützt bereitstellen, indem Sie Ihre Containerspezifikation in YAML ändern. Jeder Schlüssel unter mountReadOnly kann für schreibgeschützte Schlüssel auf festgelegt werden true (der Standardwert ist false ).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Fein abgrenzende Kontrolle über den Start/Stopp des Containers

Im Allgemeinen wird empfohlen, Azure Pipelines den Lebenszyklus Ihrer Auftrags- und Dienstcontainer zu verwalten. In einigen ungewöhnlichen Szenarien sollten Sie sie jedoch selbst starten und beenden. Mit diesem Release haben wir diese Funktion in die Docker-Aufgabe integriert.

Hier ist eine Beispielpipeline mit der neuen Funktion:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Außerdem fügen wir die Liste der Container in eine Pipelinevariable ein: Agent.ContainerMapping . Sie können dies verwenden, wenn Sie z. B. die Liste der Container in einem Skript überprüfen möchten. Es enthält ein Zeichenfolgen-JSON-Objekt, das den Ressourcennamen ("Builder" aus dem obigen Beispiel) der Vom Agent verwalteten Container-ID zugibt.

Entzippen von Aufgabenbündeln für jeden Schritt

Wenn der Agent einen Auftrag ausgeführt, lädt er zunächst alle Taskbündel herunter, die für die Schritte des Auftrags erforderlich sind. Normalerweise entzippen sie die Aufgaben aus Leistungs- und Leistungs-Leistungs- und Leistungs- und Leistungsstufen einmal pro Auftrag, auch wenn die Aufgabe in mehreren Schritten verwendet wird. Wenn Sie Bedenken haben, dass nicht vertrauenswürdiger Code die entzippten Inhalte ändert, können Sie die Leistung ein wenig abfangen, indem Sie den Agent die Aufgabe bei jeder Verwendung entzippen lassen. Um diesen Modus zu aktivieren, übergeben Sie --alwaysextracttask beim Konfigurieren des Agents.

Verbessern der Releasesicherheit durch Einschränken des Zugriffstokenbereichs

Auf der Grundlage unserer Initiative zur Verbesserung der Sicherheitseinstellungen für Azure Pipelines unterstützen wir jetzt das Einschränken des Bereichs von Zugriffstoken für Releases.

Jeder Auftrag, der in Releases ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und von Ihren Skripts verwendet, um einen Rückruf in Azure DevOps. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Artefakte herunterzuladen, Protokolle hochzuladen, Ergebnisse zu testen oder REST-Aufrufe in Azure DevOps. Für jeden Auftrag wird ein neues Zugriffstoken generiert, das nach Abschluss des Auftrags abläuft.

Mit diesem Update bauen wir auf der Verbesserung der Pipelinesicherheit auf, indem wir den Bereich der Zugriffstoken einschränken und auf klassische Releases ausdehnen.

Dieses Feature ist für neue Projekte und Sammlungen standardmäßig aktiviert. Für vorhandene Sammlungen müssen Sie sie in Sammlungsversionen Einstellungen > Pipelines > Einstellungen. > Auftragsautorisierungsbereich für Releasepipelines auf das aktuelle Projekt beschränken. Hiererhalten Sie weitere Informationen.

VERBESSERUNGEN der YAML-Vorschau-API

Sie können jetzt eine Vorschau des vollständigen YAML einer Pipeline anzeigen, ohne sie ausführen zu müssen. Darüber hinaus haben wir eine dedizierte neue URL für die Vorschaufunktion erstellt. Jetzt können Sie PER POST an https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview den finalisierten YAML-Text abrufen. Diese neue API verwendet die gleichen Parameter wie das Einreihen einer Ausführung in die Warteschlange, erfordert jedoch nicht mehr die Berechtigung " Warteschlangen-Builds. "

Führen Sie diesen Auftrag als Nächstes aus.

Haben Sie schon einmal ein Fehlerbehebungs-Problem erhalten, das Sie direkt in dieser Minute bereitstellen mussten, aber hinter CI- und PR-Aufträgen warten mussten? Mit diesem Release können Sie nun die Priorität eines Auftrags in der Warteschlange anheben. Benutzern mit der Berechtigung "Verwalten" für den Pool – in der Regel Pooladministratoren – wird auf der Seite mit den Auftragsdetails die neue Schaltfläche "Weiter ausführen" angezeigt. Durch Klicken auf die Schaltfläche wird festgelegt, dass der Auftrag so bald wie möglich ausgeführt wird. (Sie benötigen natürlich weiterhin verfügbare Parallelität und einen geeigneten Agent.)

Vorlagenausdrücke, die im YAML-Block zulässig resources sind

Zuvor waren Kompilierzeitausdrücke ( ) im Abschnitt einer ${{ }} YAML-Datei Azure Pipelines resources zulässig. Mit diesem Release haben wir diese Einschränkung für Container aufgehoben. Auf diese Weise können Sie Laufzeitparameterinhalte in Ihren Ressourcen verwenden, z. B. um einen Container zur Warteschlangenzeit zu wählen. Wir planen, diese Unterstützung im Laufe der Zeit auf andere Ressourcen zu erweitern.

Steuern von automatisierten Aufgabenupdates aus dem Marketplace

Wenn Sie eine YAML-Pipeline schreiben, geben Sie normalerweise nur die Hauptversionsnummer der enthaltenen Aufgaben an. Auf diese Weise können Ihre Pipelines automatisch die neuesten Features und Fehlerbehebungen übernehmen. Gelegentlich müssen Sie möglicherweise ein Rollback auf eine vorherige Punktversion einer Aufgabe machen, und mit diesem Update haben wir Ihnen die Möglichkeit hinzugefügt, dies zu tun. Sie können jetzt eine vollständige Major.Minor.Patch-Taskversion in Ihren YAML-Pipelines angeben.

Es wird nicht empfohlen, dies regelmäßig zu tun, und sie nur als vorübergehende Problemumgehung zu verwenden, wenn Sie feststellen, dass eine neuere Aufgabe Ihre Pipelines unterbricht. Außerdem wird dadurch keine ältere Version einer Aufgabe aus dem Marketplace installiert. Sie muss bereits in Ihrer Sammlung vorhanden sein, da die Pipeline nicht mehr vorhanden ist.

Beispiel:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Node 10-Unterstützung in Agent und Tasks

Da Knoten 6 nicht mehr unterstützt wird, migrieren wir die Aufgaben für die Arbeit mit Node 10. Für dieses Update haben wir fast 50 % der In-Box-Aufgaben zu Node 10 migriert. Der Agent kann jetzt sowohl Node 6- als auch Node 10-Aufgaben ausführen. In einem zukünftigen Update werden wir Node 6 vollständig vom Agent entfernen. Um die Entfernung von Node 6 vom Agent vorzubereiten, fordern wir Sie auf, Ihre eigenen Erweiterungen und benutzerdefinierten Aufgaben in Kürze zu aktualisieren, damit auch Node 10 verwendet wird. Um Node 10 für Ihre Aufgabe zu verwenden, aktualisieren Sie in unter task.json execution von auf Node Node10 .

Verbessern der YAML-Konvertierung im klassischen Build-Designer

Mit diesem Release führen wir ein neues Feature "Nach YAML exportieren" für Designer-Buildpipelines ein. Speichern Sie Ihre Pipelinedefinition, und suchen Sie dann im Menü nach "Nach YAML ... exportieren".

Die neue Exportfunktion ersetzt die Funktion "Als YAML anzeigen", die zuvor im klassischen Build-Designer gefunden wurde. Diese Funktion war unvollständig, da sie nur überprüfen konnte, was die Webbenutzeroberfläche über den Build wusste, was manchmal dazu führte, dass falsche YAML-Dateien generiert wurden. Die neue Exportfunktion berücksichtigt genau, wie die Pipeline verarbeitet wird, und generiert YAML mit vollständiger Genauigkeit für die Designerpipeline.

Neue Webplattformkonvertierung – Repositoryeinstellungen

Wir haben die beiden Repository-Einstellungsseiten in eine einzelne Beerfahrung konvertiert, die auf eine neue Webplattform aktualisiert wurde. Dieses Upgrade macht die Benutzererfahrung nicht nur schneller und moderner, sondern bietet auch einen einzelnen Einstiegspunkt für alle Richtlinien von der Projektebene bis zur Branchebene.

Neue Webplattformkonvertierung.

Mit dieser neuen Erfahrung ist die Navigation für Projekte mit einer beträchtlichen Anzahl von Repositorys aufgrund kürzerer Ladezeiten und eines hinzugefügten Suchfilters einfacher geworden. Sie können auch Richtlinien auf Projektebene und die Liste der repositoryübergreifenden Richtlinien auf der Registerkarte Richtlinien anzeigen.

Zeigen Sie repositoryübergreifende Richtlinien auf der Registerkarte Richtlinien an.

Wenn Sie auf ein Repository klicken, können Sie Richtlinien und Berechtigungen anzeigen, die auf Repositoryebene festgelegt wurden. Auf der Registerkarte "Richtlinien" können Sie eine Liste mit jedem Branch anzeigen, auf dem die Richtlinie festgelegt ist. Klicken Sie nun auf den Branch, um die Richtlinien anzuzeigen, während Sie nie die Seite Repositoryeinstellungen verlassen.

Wählen Sie Branch aus, um die Richtlinien zu sehen.

Wenn Richtlinien nun von einem höheren Bereich geerbt werden als das, was Sie verwenden, zeigen wir Ihnen, wo die Richtlinie von neben jeder einzelnen Richtlinie geerbt wurde. Sie können auch zu der Seite navigieren, auf der die Richtlinie auf höherer Ebene festgelegt wurde, indem Sie auf den Bereichsnamen klicken.

Zeigt an, von wo die Richtlinie geerbt wurde.

Die Richtlinienseite selbst wurde auch auf die neue Webplattform mit reduzierbaren Abschnitten aktualisiert. Um die Suche nach einer bestimmten Buildvalidierungs-, Statusüberprüfungs- oder Automatischer Prüferrichtlinie zu verbessern, haben wir für jeden Abschnitt Suchfilter hinzugefügt.

Suchfilter für jeden Abschnitt.

Integration der ServiceNow-Änderungsverwaltung in YAML-Pipelines

Die Azure Pipelines-App für ServiceNow unterstützt Sie bei der Integration Azure Pipelines und ServiceNow Change Management. Mit diesem Update machen wir uns mit dem Change Management Azure Pipelines, der in ServiceNow verwaltet wird, auf YAML-Pipelines aufmerksam.

Durch Konfigurieren der Überprüfung "ServiceNow-Änderungsverwaltung" für eine Ressource können Sie jetzt anhalten, bis die Änderung genehmigt wird, bevor Sie den Build für diese Ressource bereitstellen. Sie können automatisch eine neue Änderung für eine Phase erstellen oder auf eine vorhandene Änderungsanforderung warten.


ServiceNow Change Management Integration

Sie können die Aufgabe auch in einem Serverauftrag hinzufügen, um die Änderungsanforderung mit UpdateServiceNowChangeRequest Bereitstellungsstatus, Hinweisen usw. zu aktualisieren.

Artifacts

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

Wir bieten Kunden wieder die Möglichkeit, sammlungsspezifische Feeds über die Webbenutzeroberfläche sowohl für die on-prem- als auch für die gehosteten Dienste zu erstellen und zu verwalten.

Sie können jetzt organisationsspezifische Feeds über die Benutzeroberfläche erstellen, indem Sie Artifacts -> Feed erstellen und einen Feedtyp im Bereich auswählen.

Erstellen Sie sammlungsbezogene Feeds, indem Sie Artifacts und dann Feed erstellen auswählen und einen Feedtyp innerhalb des Bereichs auswählen.

Wir empfehlen zwar die Verwendung von Projektfeeds in Übereinstimmung mit den restlichen Azure DevOps Angeboten, sie können aber auch wieder sammlungsbezogene Feeds über die Benutzeroberfläche und verschiedene REST-APIs erstellen, verwalten und verwenden. Weitere Informationen finden Sie in unserer Feeds-Dokumentation.

Update Package Version REST API now available for Maven packages (Rest-API zum Aktualisieren der Paketversion jetzt für Maven-Pakete verfügbar)

Sie können jetzt die REST-API für Azure Artifacts " Updatepaketversion " verwenden, um Maven-Paketversionen zu aktualisieren. Bisher konnten Sie die REST-API verwenden, um Paketversionen für NuGet, Maven, npm und Universal Packages, aber nicht für Maven-Pakete zu aktualisieren.

Um Maven-Pakete zu aktualisieren, verwenden Sie den HTTP PATCH-Befehl wie folgt.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Sie können Folgendes festlegen:

URI-Parameter

Name In Erforderlich Typ Beschreibung
artifactId path true Zeichenfolge Artefakt-ID des Pakets
feed path true Zeichenfolge Name oder ID des Feeds
groupId path true Zeichenfolge Gruppen-ID des Pakets
collection path true Zeichenfolge Der Name der Azure DevOps Auflistung
version path true Zeichenfolge Version des Pakets
Projekt path Zeichenfolge Project-ID oder Projektname
api-version Abfrage true Zeichenfolge Version der zu verwendende API. Dies sollte auf '5.1-preview.1-' festgelegt werden, um diese Version der API zu verwenden.

Anforderungstext

Name Typ Beschreibung
views JsonPatchOperation Die Ansicht, der die Paketversion hinzugefügt wird

Weitere Informationen finden Sie in der REST-API-Dokumentation, sobald sie aktualisiert wird.

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und diese über Developer Community nachverfolgen und Sich über Stack Overflowinformieren.


Seitenanfang