Azure DevOps Server 2019: Anmerkungen zu dieser Version

Entwickler Community | Systemanforderungen | Lizenzbedingungen | 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 Veröffentlichungsdatum 2019.0.1 Patch 11: 10. August 2021

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

  • Benutzeroberflächenfehler der Builddefinition behoben.

Azure DevOps Server 2019.0.1 Patch 10 Release Date: 13. April 2021

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

Um Patch 10 anzuwenden, müssen Sie die Aufgabe AzureResourceGroupDeploymentV2 installieren.

Installation des AzureResourceGroupDeploymentV2-Task

Hinweis

Alle unten genannten Schritte müssen auf einem Windows-Computer ausgeführt werden.

Installieren

  1. Extrahieren Sie AzureResourceGroupDeploymentV2.zip Paket in einen neuen Ordner auf Ihrem Computer. Beispiel: AzureResourceGroupDeploymentV2.

  2. Laden Sie die Node.js 14.15.1 und npm (im Node.js-Download enthalten) auf Ihren Computer herunter, und installieren Sie diese Komponenten.

  3. Öffnen Sie eine Eingabeaufforderung im Administratormodus, und führen Sie den folgenden Befehl aus, um tfx-cli zu installieren.

npm install -g tfx-cli
  1. Erstellen Sie ein persönliches Zugriffstoken mit Vollzugriffsberechtigungen, und kopieren Sie es. Dieses persönliche Zugriffstoken wird beim Ausführen des Befehls tfx login verwendet.

  2. Führen Sie Folgendes in der Eingabeaufforderung aus. Wenn Sie dazu aufgefordert werden, geben Sie die Dienst-URL und das persönliche Zugriffstoken ein.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Verwenden Sie den Pfad der extrahierten ZIP-Datei aus Schritt 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server Veröffentlichungsdatum 2019.0.1 Patch 9: 8. Dezember 2020

Wir haben einen Patch für Azure DevOps Server 2019.0.1 veröffentlicht, der Folgendes korrigiert. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2020-1325: Sicherheitsrisiko Azure DevOps Server Spoofing
  • CVE-2020-17135: Sicherheitsrisiko Azure DevOps Server Spoofing
  • CVE-2020-17145 : Sicherheitsrisiko durch Spoofing in Azure DevOps Server und Team Foundation Server
  • Problem behoben, bei dem TFVC nicht alle Ergebnisse verarbeitet

Wichtig

Lesen Sie die unten angegebenen vollständigen Anweisungen, bevor Sie diesen Patch installieren.

Allgemeine Patchinstallation

Wenn Sie Azure DevOps Server 2019.0.1 installiert haben, sollten Sie Azure DevOps Server 2019.0.1 Patch 9 installieren.

Überprüfen der Installation

  • Option 1: Führen Sie devops2019.0.1patch9.exe CheckInstall devops2019.0.1patch9.exe ist die Datei, die über den obigen Link heruntergeladen wird. Die Ausgabe des Befehls gibt entweder an, dass der Patch installiert oder nicht installiert wurde.

  • Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll . Azure DevOps Server 2019 ist standardmäßig c:\Program Files\Azure DevOps Server 2019 auf installiert. Nach der Azure DevOps Server 2019.0.1 Patch 9 ist die Version 17.143.30723.4.

Installation des AzurePowerShellV4-Task

Hinweis

Alle unten genannten Schritte müssen auf einem Windows-Computer ausgeführt werden.

Voraussetzungen

  1. Installieren Azure PowerShell Az-Modul Azure PowerShell auf Ihrem privaten Agent-Computer.

  2. Erstellen Sie eine Pipeline mit der AzurePowerShellV4-Aufgabe. In der Aufgabe wird nur ein Fehler bei Standardfehler angezeigt.

Installieren

  1. Extrahieren Sie AzurePowerShellV4.zip-Paket in einen Ordner mit dem Namen AzurePowerShellV4.

  2. Laden Sie die Node.js 14.15.1 und npm (im Node.js-Download enthalten) auf Ihren Computer herunter, und installieren Sie diese Komponenten.

  3. Öffnen Sie eine Eingabeaufforderung im Administratormodus, und führen Sie den folgenden Befehl aus, um tfx-cli zu installieren.

npm install -g tfx-cli
  1. Erstellen Sie ein persönliches Zugriffstoken mit Vollzugriffsberechtigungen, und kopieren Sie es. Dieses persönliche Zugriffstoken wird beim Ausführen des Befehls tfx login verwendet.

  2. Führen Sie Folgendes in der Eingabeaufforderung aus. Wenn Sie dazu aufgefordert werden, geben Sie die Dienst-URL und das persönliche Zugriffstoken ein.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Der Pfad des extrahierten Pakets ist "D:\tasks (1)\AzurePowerShellv4".
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 8 Release Date: 8. September 2020

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, der Folgendes korrigiert. Weitere Informationen finden Sie im Blogbeitrag.

  • DTS 1713492: Unerwartetes Verhalten beim Hinzufügen von AD-Gruppen zu Sicherheitsberechtigungen.

Azure DevOps Server Veröffentlichungsdatum 2019.0.1 Patch 7: 14. Juli 2020

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, der Folgendes korrigiert. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2020-1326: Sicherheitsrisiko durch websiteübergreifende Skripterstellung
  • Die Buildpipeline zeigt eine falsche Verbindung für nicht autorisierte Benutzer an, wenn Sie Andere Git-Quelle auswählen.
  • Korrektur eines Fehlers beim Ändern der Vererbung in "Ein" oder "Aus" in der XAML-Builddefinition.

Azure DevOps Server 2019.0.1 Patch 6 Release Date: 10. Juni 2020

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, der Folgendes korrigiert. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2020-1327: Stellen Sie sicher, dass Azure DevOps Server Benutzereingaben bereinigungen.
  • Hinzufügen von Unterstützung für SHA2 in SSH auf Azure DevOps

Azure DevOps Server 2019.0.1 Patch 5 Release Date: 10. März 2020

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, der Folgendes korrigiert. Weitere Informationen finden Sie im Blogbeitrag.

Azure DevOps Server Veröffentlichungsdatum 2019.0.1 Patch 3: 10. September 2019

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, mit dem die folgenden Fehler korrigiert werden. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2019-1305 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Repositorys
  • CVE-2019-1306 : Sicherheitsrisiko durch Remotecodeausführung in Wiki

Azure DevOps Server Veröffentlichungsdatum 2019.0.1 Patch 2: 13. August 2019

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, mit dem folgender Fehler korrigiert wird. Weitere Informationen finden Sie im Blogbeitrag.

  • Wir haben Dienstverbindungen Informationen hinzugefügt, um zu verdeutlichen, dass sie standardmäßig für alle Pipelines autorisiert sind.

Azure DevOps Server Veröffentlichungsdatum 2019.0.1 Patch 1: 9. Juli 2019

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019.0.1 veröffentlicht, mit dem die folgenden Fehler korrigiert werden. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2019-1072 : Sicherheitsrisiko durch Remotecodeausführung bei der Nachverfolgung von Arbeitselementen
  • CVE-2019-1076: Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pull Requests

Azure DevOps Server Veröffentlichungsdatum 2019.0.1: 21. Mai 2019

Azure DevOps Server 2019.0.1 ist ein Rollup von Fehlerbehebungen. Es enthält alle Fehlerbehebungen in den Azure DevOps Server 2019-Patches, die zuvor veröffentlicht wurden. Sie können Azure DevOps Server 2019.0.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2019 oder Team Foundation Server 2012 oder neuer durchführen.

Hinweis

Das Datenmigrationstool ist für Azure DevOps Server 2019.0.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

  • "Die Feldkriterien für diesen Plan haben einen Fehler." beim Konfigurieren eines Plans. Wird vom Entwickler Community.
  • apiwitcontroller.executequery löst eine Ausnahme aus, wenn eine Abfrage mehrmals dieselbe Spalte enthält.
  • Im Clientobjektmodell, das den oauth vso.work_full bereich verwendet, schlägt WorkItemServer.DownloadFile() fehl.
  • Das Kopieren eines eingebetteten Bilds aus einem Arbeitselementfeld in ein anderes Arbeitselementfeld in einem anderen Projekt kann zu einem beschädigten Bild werden.

Azure Repos

  • "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

  • Die Registerkarte "Testanalyse" weist einen Stern (*) auf, der die Vorschau anzeigt, obwohl sich dieses Feature nicht in der Vorschau befindet.
  • Auf der Registerkarte Releases wird die Aktion zum Verwalten der Sicherheit jetzt allen Benutzern angezeigt, unabhängig davon, ob sie die Berechtigungen ändern können.
  • Auf den Landing Pages releases wurde mit dem Startentwurf der Releaseaktion ein neues Release erstellt, jetzt wird der Releaseentwurf gestartet.

Azure Test Plans

  • Der 1-Stunden-Filter für TestRuns und TestResults CompletedDate ist zu präzise.
  • Im Arbeitselementtyp Testfall sollte der Typ "Testfall" nicht lokalisiert werden.
  • Testfälle werden nicht in MTM oder einem Browser angezeigt.
  • Fehler "Phase überprüfen: Sie verfügen nicht über die Berechtigung zum Auslösen von Releases in der zugehörigen Releasepipeline", wenn automatisierte Tests aus einem Testplan ausgeführt werden. Wird vom Entwickler Community.
  • Mithilfe der API zum Löschen von Testfällenkönnen Testfälle aus anderen Projekten gelöscht werden. Wird vom Entwickler Community.
  • Durch Klicken auf einen Arbeitselementlink in Test Runner wird die Arbeitselement-URL in Test Runner anstelle des Standardbrowsers geöffnet.
  • Der Status des Testfalles wird für Benutzer, die sich abmelden, nicht Test Runner.
  • Benutzername und E-Mail-Adresse werden in der Dropdownliste "Benutzer" in der Test Runner.

Azure Artifacts

  • Nach oben und Nach unten werden in Upstreams nicht lokalisiert.

Analyse

  • Analytics-Berichte zeigen möglicherweise unvollständige Daten an, da das Modell als "bereit" markiert ist, bevor es tatsächlich abgeschlossen ist.
  • Die Widgets "Geschwindigkeit", "Burndown" und "Burnup" zeigen verschiedene geplante Arbeit für Benutzer in verschiedenen Zeitzonen an.
  • Bei der Analytics-Datenerfassung kann eine Zurückhaltung während der Wartung platziert werden, was zu veralteten Berichten führen kann.

Allgemein

  • Linke Navigationselemente werden auf dem Internetgerät angezeigt, wenn nicht genügend Platz vorhanden ist.

Verwaltung

  • Zusätzliche Protokollierung zum Sammlungsupgrade hinzugefügt, um Probleme zu debuggen.
  • Wenn tfsConfig offlineDetach fehlschlägt, ist die Fehlermeldung nicht umsetzbar.
  • Der TfsJobAgent-Dienst stürzt ab.
  • Die Search-Erweiterung wird nach Abschluss der Konfiguration nicht installiert.
  • Die Verwaltungskonsole reagiert nicht mehr, wenn die Konfigurationsdatenbank beschädigt ist.
  • Diensthooks verarbeiten Benachrichtigungen möglicherweise nicht ordnungsgemäß.
  • Codesuche wird die Indizierung nach dem Konfigurieren der Suche nicht gestartet.
  • Es gibt nicht lokalisierte Zeichenfolgen in Suchergebnissen.

Dieses Release enthält das folgende Update:

Unterstützung für Visual Studio 2019 (VS2019) in Visual Studio Testaufgabe

Wir haben unterstützung für Visual Studio 2019 zur Visual Studio Testaufgabe in Pipelines hinzugefügt. Um Tests mithilfe der Testplattform für Visual Studio 2019 durchzuführen, wählen Sie in der Dropdownliste Testplattformversion die Optionen Neueste oder Visual Studio 2019 aus.

Screenshot des Abschnitts "Ausführungsoptionen", in dem die Dropdownliste Testplattformversion mit ausgewählter Option "Letzte Visual Studio 2019" ausgewählt ist


Azure DevOps Server Veröffentlichungsdatum 2019 Patch 2: 14. Mai 2019

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019 veröffentlicht, der die folgenden Fehler behebt. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2019-0872 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Test Plans
  • CVE-2019-0971 : Sicherheitsrisiko bei der Veröffentlichung von Informationen in der Repos-API
  • CVE-2019-0979 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) im Benutzerhub

Azure DevOps Server Veröffentlichungsdatum von Patch 1 2019: 9. April 2019

Wir haben einen Sicherheitspatch für Azure DevOps Server 2019 veröffentlicht, der die folgenden Fehler behebt. Weitere Informationen finden Sie im Blogbeitrag.

  • CVE-2019-0857: Spoofing-Sicherheitsrisiko im Wiki
  • CVE-2019-0866 : Sicherheitsrisiko durch Remotecodeausführung in Pipelines
  • CVE-2019-0867 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
  • CVE-2019-0868 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
  • CVE-2019-0869: Sicherheitsrisiko durch Ein injection in HTML in Pipelines
  • CVE-2019-0870 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
  • CVE-2019-0871 : Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
  • CVE-2019-0874: Sicherheitsrisiko durch websiteübergreifende Skripterstellung (Cross-Site Scripting, XSS) in Pipelines
  • CVE-2019-0875: Sicherheitsrisiko durch Rechteerweiterungen in Boards

Azure DevOps Server Veröffentlichungsdatum 2019: 5. März 2019

Hinweis

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


RC2-Veröffentlichungsdatum: 22. Januar 2019

Zusammenfassung der Neuen in Azure DevOps Server 2019 RC2

Wir haben RC2 die folgenden Features hinzugefügt:


RC1-Veröffentlichungsdatum: 19. November 2018

Zusammenfassung der Neuen in Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 führt eine neue Navigationserfahrung und viele neue Features ein. Einige der Highlights sind unter anderem:

Sie können auch zu einzelnen Abschnitten springen, um die neuen Features zu sehen:


Allgemein

Ankündigung Azure DevOps Server

Am 10. September haben wir angekündigt, Azure DevOps entwicklung von Visual Studio Team Services und Team Foundation Server. Azure DevOps Server 2019 ist unser erstes lokales Release mit dieser neuen Marke. Weitere Informationen finden Sie in unserem Blogbeitrag.

Neue Navigationserfahrung

Wir führen eine neue Navigation ein, um die Benutzeroberfläche zu modernisieren. Diese neue Navigation wurde für den Azure DevOps-Dienst veröffentlicht und ist ab Azure DevOps Server 2019 verfügbar. Weitere Informationen finden Sie in unserem Blog.

Neuer Navigations nav

Änderungen an Artifacts und Release Management-Bereitstellungspipelinelizenzierung

Basierend auf Benutzerfeedback werden im Jahr 2019 zwei wichtige Änderungen an unseren Lizenzen Azure DevOps Server vorgenommen. Erstens müssen Kunden die Artefakterweiterung nicht mehr erwerben, um die Artifacts. Eine Artifacts Lizenznutzung ist jetzt in der Basic-Lizenz enthalten. Alle Benutzer, denen eine Basic-Lizenz zugewiesen ist, können jetzt Artifacts. Zweitens müssen Kunden keine Bereitstellungsbereitstellungs-Release Management mehr Pipelines. Genau wie build Pipelines sind Release Management Deployment Pipelines jetzt in Azure DevOps Server 2019 enthalten.

Unterstützung für Azure SQL-Datenbank

Um die Ausführung von Azure DevOps 2019 in Azure zu vereinfachen, haben wir die Unterstützung für Azure SQL-Datenbank (Universell S3 und höher) aktiviert. Dadurch können Sie umfangreiche Sicherungsfeatures und Skalierungsoptionen nutzen, um Ihre Anforderungen zu erfüllen und gleichzeitig den Verwaltungsaufwand für die Ausführung des Diensts zu reduzieren. Beachten Sie, dass sich Ihre Host-VM in derselben Azure-Region wie Ihre Datenbank befinden muss, um die Latenz gering zu halten. Weitere Informationen finden Sie in der Dokumentation .

Arbeitselement & Testen von SOAP-APIs des Clientobjektmodells in zukünftigen Versionen

Azure DevOps Server 2019 unterstützt weiterhin die SOAP-API für die Arbeitselementnachverfolgung und das Clientobjektmodell. Sie wird jedoch in zukünftigen Versionen von als veraltet markiert Azure DevOps Server. Weitere Informationen finden Sie in unserer Dokumentation.

Verarbeiten der Vererbung für neue Sammlungen

Die Prozessvererbung ist jetzt für neue Sammlungen verfügbar. Benutzer müssen beim Erstellen einer neuen Sammlung eine entscheidungsbegründende Entscheidung über das Prozessmodell treffen. Informationen dazu, was das Vererbungsmodell ist und wie es sich von XML unterscheiden kann, finden Sie in unserer Dokumentation.

Prozessvererbung

Wir verstehen die Wichtigkeit der Suche und stellen das erweiterte Suchfeld im Produktheader wieder zur Seite. Darüber hinaus können Sie jetzt das Suchfeld aufrufen, indem Sie einfach auf einer beliebigen Dienstseite in der Azure DevOps. Dieses Feature wurde basierend auf der folgenden Benutzerstimme priorisiert.

Hier ist das Standardsuchfeld:

Standardsuchfeld

Sobald Sie ein "/" eingeben, wird das erweiterte Suchfeld angezeigt:

Erweitertes Suchfeld

Mein Arbeits-Flyout

Ein neues Feature, das wir sehr gerne einführen können, ist das Flyout für meine Arbeit. Wir haben feedback gehört, dass Sie ihren Kontext nicht verlieren möchten, wenn Sie sich in einem Teil des Produkts befinden und Informationen aus einem anderen Teil wünschen. Mit diesem neuen Feature können Sie von überall im Produkt auf dieses Flyout zugreifen und erhalten einen schnellen Blick auf wichtige Informationen, einschließlich Ihrer Arbeitselemente, Pull Requests und aller Favoriten. Wenn Sie mit diesem neuen Flyout in Repos im Code nach unten suchen, aber dann schnell überprüfen möchten, an welchem Arbeitselement Sie als Nächstes arbeiten sollten, können Sie einfach auf das Flyout klicken und die Ihnen zugewiesenen Arbeitselemente sehen und das nächste Element auswählen.

Unten sehen Sie das Flyout "Meine Arbeit", das die mir zugewiesenen Arbeitselemente zeigt:

Mein Arbeits-Flyout

Hier sehen Sie das zweite Pivot, das die zugewiesenen PRs zeigt. Im Flyout haben Sie auch Einen-Klick-Zugriff, um weitere Pull Requests anzeigen zu können:

Mein Arbeits-Flyout-PR

Hier sehen Sie das letzte Pivot, das alles ist, was Sie als Favoriten verwendet haben. Dazu gehören Ihre bevorzugten Teams, Dashboards, Boards, Backlogs, Abfragen und Repositorys:

Meine Arbeits-Flyoutfavoriten

Boards

Teams, die GitHub Enterprise für Code verwenden und umfassende Projektverwaltungsfunktionen wünschen, können ihre Repositorys jetzt in die Azure Boards. Durch Verbinden von GitHubund Azure Boards können Sie alle Features wie Backlogs, Boards, Sprintplanungstools, mehrere Arbeitselementtypen erhalten und dennoch über einen Workflow verfügen, der in Entwicklerworkflows in GitHub.

Das Verknüpfen von Commits und Pull Requests mit Arbeitselementen ist einfach. Erwähnen Sie das Arbeitselement mithilfe der folgenden Syntax:

AB#{work item ID}

Erwähnen Sie ein Arbeitselement in einer Commitnachricht, einem Pull Request-Titel oder einer Pull Request-Beschreibung, und Azure Boards erstellt einen Link zu diesem Artefakt. Betrachten Sie beispielsweise eine Commitnachricht wie die folgende:

Adds support for deleting connections. Fixes AB#20.

Dadurch wird ein Link vom Arbeitselement #20 zum Commit in GitHub erstellt, der im Abschnitt Entwicklung des Arbeitselements angezeigt wird.

Screenshot: Azure DevOps mit dem Abschnitt "Entwicklung"

Wenn die Wörter "fix", "fixes" oder "fixed" vor der Erwähnung des Arbeitselements (wie oben gezeigt) sind, wird das Arbeitselement in den abgeschlossenen Zustand verschoben, wenn der Commit mit der Standardverzweigung zusammengeführt wird.

Teams, die Azure Pipelines zum Erstellen von Code in GitHub verwenden, werden auch die Arbeitselemente, die mit ihren GitHub Commits verknüpft sind, in der Buildzusammenfassung angezeigt.

Hub "Neue Arbeitselemente"

Der Arbeitselemente-Hub ist unser neuer Hub, der als Grundlage für Ihre Arbeitselemente dient. Hier haben Sie viele verschiedene Listenansichten Ihrer Arbeitselemente, die für Sie gelten. Sie können Zugewiesen zu mir anzeigen, um schnell einen Blick auf alle Ihnen zugewiesenen Aufgaben oder Kürzlich aktualisiert zu erhalten. Hier werden alle Arbeitselemente in Ihrem Projekt angezeigt, die zuletzt aktualisiert wurden. Alle Listenoptionen sind unten zu sehen:

Arbeitselementehub

Wenn Sie die Listen noch weiter nach unten filtern möchten, können Sie nach Typ, Zugewiesen, Zustand, Bereich, Tags und Schlüsselwort filtern. Sobald Sie die gewünschte Listenansicht haben, können Sie die Arbeitselemente sortieren, indem Sie einfach auf die Kopfzeile der Spalte klicken. Wenn eine Spalte zu schmal ist, um den vollständigen Inhalt der Spalte anzuzeigen, können Sie die Größe der Spalte im Headerbereich problemlos ändern. Diese Erfahrungen sind unten zu sehen:

Hubliste für Arbeitselemente

Neue Boards, Backlogs und Sprints-Hubs

Der Backlogs-Hub wurde in drei verschiedene Hubs aufgeteilt, um die Benutzerfreundlichkeit zu verbessern. Obwohl der alte Backlogs-Hub leistungsfähig war, gab es zu viele Features. Dies erschwerte häufig die Suche nach dem Feature oder den Funktionen, nach dem Benutzer suchten. Um dieses Problem zu beheben, haben wir den Backlogs-Hub in:

  • Der Backlogs-Hub ist jetzt nur noch die Backlogs für ein Projekt. Ein Backlog ist eine priorisierte Liste der Aufgaben für das Team. Backlogs stellen Planungstools wie Arbeitselementhierarchie, Vorhersage und neue Sprintplanungserfahrungen zur Verfügung.
  • Der neue Boards Hub ist die Startseite aller Kanban-Boards für ein Projekt. Boards werden verwendet, um status und flow zu kommunizieren. Karten (Arbeitselemente) wechseln von links nach rechts über das Board durch spalten, die vom Team definiert werden.
  • Der neue Sprints-Hub enthält Features, die zum Planen und Ausführen eines Arbeitsinkrements verwendet werden. Jeder Sprint enthält ein Sprint-Backlog, eine Taskboard und eine Ansicht zum Verwalten und Festlegen der Kapazität für das Team.

Boards Hub

Neuer Hub "Abfragen"

Der neue Abfragehub optimiert viele der vorhandenen Abfragefeatures des alten Hubs mit einem moderneren Aussehen und Aussehen sowie neuen Funktionen, um den Zugang zu den für Sie wichtigen Abfragen zu vereinfachen. Zu den Highlights der neuen Umgebung gehören:

  • Verzeichnisseiten mit der letzten Änderung durch Informationen und der Möglichkeit, nach Abfragen zu suchen
  • Breadcrumb mit eindeutigen URLs für Ordner zum Markieren wichtiger Abfragegruppen
  • Schnellzugriff von der Ergebnisseite zu Ihren bevorzugten Abfragen

Weitere Informationen zu diesen interessanten Updates finden Sie in unserem DevOps Blog.

Verschieben von Arbeitselementen in ein anderes Projekt und Ändern eines Arbeitselementtyps

Sie können nun den Arbeitselementtyp ändern oder Arbeitselemente in ein anderes Projekt innerhalb einer Projektsammlung verschieben. Diese Features erfordern, dass das Data Warehouse deaktiviert ist. Wenn das Data Warehouse deaktiviert ist, können Sie den Analytics-Dienst verwenden, um Ihre Berichterstellungsanforderungen zu unterstützen. Weitere Informationen zum Deaktivieren des Data Warehouse finden Sie unter Deaktivieren von Data Warehouse und Cube.

Sprintplanungsfeatures

Die neuen Sprintplanungsfeatures helfen dabei, die Sprintplanung zu beschleunigen und zu verbessern.

  • Erstellen Sie Ihren nächsten Sprint, oder abonnieren Sie einen vorhandenen Sprintzeitplan direkt über den Sprints-Hub.
  • Use the new Planning pane in your backlog to drag and drop work items into future sprints. Der Bereich Planung enthält Sprinttermine, Anzahl von Arbeitselements und geplanten Aufwand.
  • Fügen Sie anforderungen am oberen Rand des Taskboards hinzu, oder verwenden Sie quick create, um dem Sprintbacklog oben, unten oder in der Zeile Ihrer Wahl hinzuzufügen.
  • Verwenden Sie Filter für "Zugewiesene", "Arbeitselementtyp", "Status" und "Tags", um die Ansichten an Ihre Anforderungen anzupassen.

Sprintplanung

Neue Verzeichnisseiten

Alle neuen Hubs, einschließlich Backlogs, Boards und Sprints, verfügen jetzt über neue Verzeichnisseiten, die in den folgenden Abschnitten organisiert sind:

  • Fahren Sie dort fort, wo Sie aufgehört haben. Dieser neue Abschnitt enthält einen schnellen Link direkt zum letzten (Board | Backlog-| Sprint) sie waren.
  • Favoriten Alle Ihre bevorzugten Boards, Sprints und Backlogs in allen Teams.
  • Mein Alle Boards, Backlogs und Sprints für Teams, zu der Sie gehören.
  • Alle Eine vollständige Liste aller Boards, Backlogs und Sprints.

Verzeichnisseiten

Menü "Neue Ansichtsoptionen"

Die neuen Hubs, einschließlich Backlogs, Boards und Sprints, verfügen über ein neues Menü Ansichtsoptionen. Dies ist eine neue Startseite für alle Aktionen zum Anpassen von Layout- und Seiteninhalten. Verwenden Sie Ansichtsoptionen, um zusätzliche Ansichten zu aktivieren, z. B. hierarchie in Backlogs anzuzeigen oder die Option Gruppieren nach auf einem Taskboard zu ändern, um den Seitenbereich für Zuordnungs- und Planungssprints zu aktivieren oder Arbeitsdetailsdiagramme zu untersuchen.

Anzeigen der Optionen

Weitere Informationen zu diesen interessanten Updates, dem neuen Teamprofilbereich und den Favoriten finden Sie in unserem DevOps Blog.

Kartenanmerkungen enthalten Fehler und benutzerdefinierte Arbeitselementtypen.

Kartenanmerkungen sind für ihre intuitive Ansicht und Interaktion von Prüflisten beliebt. Zuvor waren Kartenanmerkungen auf Standardtypen auf Backlogebene beschränkt und unterstützten keine Fehler oder benutzerdefinierten Typen. Mit der neuen Version haben wir die Einschränkung für Arbeitselementtypen aufgehoben und die Möglichkeit hinzugefügt, Fehler und jeden benutzerdefinierten Arbeitselementtyp als Kartenanmerkung anzuzeigen.

Boardeinstellungen für Kartenanmerkungen wurden erweitert, sodass sie alle Arbeitselementtypen enthalten, die für diese Backlogebene verfügbar sind.

Anmerkungseinstellungen

Wenn Anmerkungen für Arbeitselement aktiviert sind, wird die Anzahl für diesen Arbeitselementtyp als separate Prüfliste auf der Karte angezeigt.

Anmerkungsarbeitselement

Die schnelle Erstellung von aktivierten Arbeitselementtypen ist auch über das Kartenkontextmenü verfügbar.

Schnellerfassung von Anmerkungen

Verschieben von Arbeit mit vorgeschlagenen Bereichen und Iterationen

Es kann üblich sein, im gleichen Bereich oder in derselben Iteration zu arbeiten und beim Verschieben von Arbeitselementen wiederholt die Hierarchien zu durchsuchen. Die Steuerelemente für den Bereichs- und Iterationspfad enthalten jetzt eine Liste der zuletzt verwendeten Werte als Vorschläge, sodass Sie schnell auf festlegen und weitermachen können.

Dropdownliste "Bereich"

Darüber hinaus sind Iterationstermine rechts neben dem Namen enthalten, sodass Sie schnell erkennen können, wann ein Arbeitselement übermittelt werden soll.

Dropdownliste "Iteration"

Abfragearbeit im Iterationszeitplan mit +/- @CurrentIteration

Das @CurrentIteration Makro, das Ihrem Team hilft, die Arbeit basierend auf Ihrem Iterationszeitplan nachzuverfolgen, unterstützt jetzt ganzzahligen Offset. Halten Sie einfach Registerkarten für die Arbeit, die nicht mit - 1 geschlossen @CurrentIteration wurde, oder sehen Sie sich die für zukünftige Iterationen mit + 1 geplanten Arbeiten @CurrentIteration an. Weitere Informationen finden Sie im @CurrentIteration Beitrag im Microsoft DevOps Blog. Dieses Feature wurde basierend auf dem derzeit nr. 12 am höchsten gewählten Vorschlag mit 456 Stimmen priorisiert.

Verdeutlichen von Abfrageiterationszeitplänen mit dem @CurrentIteration Team-Parameter

Wenn Sie das Makro in der Vergangenheit in Abfragen verwendet @CurrentIteration haben, haben Sie möglicherweise bemerkt, dass die Ergebnisse variieren können, wenn sich der Teamkontext über Teams mit unterschiedlichen Iterationszeitplänen ändert. Wenn Sie nun eine Abfrage mit dem Makro erstellen oder @CurrentIteration ändern, müssen Sie auch das Team mit dem Iterationszeitplan auswählen, der für die Abfrage relevant ist. Mit dem Parameter Team können Sie das @CurrentIteration Makro in derselben Abfrage, aber teamsübergreifend verwenden. Ein Beispiel hierfür ist eine Abfrage für Arbeitselemente in zwei verschiedenen Teamprojekten mit unterschiedlichen Iterationsnamen und sogar Zeitplänen. Dies bedeutet, dass Abfragen nicht mehr aktualisiert werden müssen, wenn sich Sprints ändern! Weitere Informationen finden Sie im @CurrentIteration Beitrag im Microsoft DevOps Blog. Dieses Feature hat aufgrund eines Vorschlags Priorität erhalten.

Teamparameter

Abfragen der Arbeit in den Bereichspfaden eines Teams mit dem neuen @TeamAreas Makro

In den Einstellungen für ein Team können Sie einen oder mehrere Bereichspfade zuordnen, sodass Sie backlogs, Boards, Plans, sogar Dashboards auf die Arbeit für dieses Team konzentrieren können. Wenn Sie jedoch eine Abfrage für ein Team schreiben wollten, mussten Sie die spezifischen Bereichspfade für dieses Team in den Abfrageklauseln auflisten. Jetzt steht ein neues @TeamAreas Makro zur Verfügung, mit dem Sie problemlos auf die Bereichspfade verweisen können, die sich im Besitz des angegebenen Teams befinden.

Teambereichsmakro im Abfrage-Editor

Abfragen leerer Rich-Text-Felder

Suchen Sie mithilfe des neuen IsEmpty-Abfrageoperators nach Arbeitselementen, die über ein leeres Rich-Text-Feld verfügen, z. B. Description.

Einfaches Auffinden vorhandener Arbeitselemente in Verknüpfungs- und Erwähnungserfahrungen

Wenn Sie zwei vorhandene Arbeitselemente miteinander verknüpfen möchten, können Sie das Element, das für Sie wichtig ist, jetzt leicht finden, indem Sie unser neues Steuerelement für die Arbeitselementsuche verwenden. Die Abfrageauswahl wurde durch Inlinevorschläge ersetzt, die auf Ihren zuletzt verwendeten Arbeitselementen basieren, sowie durch einen Einstiegspunkt für die Suche nach einem bestimmten Arbeitselement nach ID oder Titel.

Arbeitselementverknüpfung

Zuvor konnte ein Arbeitselement nicht über die Suchergebnisseite geöffnet werden, wenn der Vorschaubereich des Arbeitselements deaktiviert wurde. Dies würde es schwierig machen, Ihre Suchergebnisse zu untersuchen. Jetzt können Sie auf den Arbeitselementtitel klicken, um die Arbeitselemente in einem modalen Fenster zu öffnen. Dieses Feature wurde von UserVoicepriorisiert.

Repos

Verbesserte Verzweigungsauswahl

Für die meisten Benutzererlebnisse in Azure Repos müssen Sie ein Repository und dann einen Branch in diesem Repository auswählen. Um diese Erfahrung für Organisationen mit einer großen Anzahl von Branches zu verbessern, stellen wir eine neue Branchauswahl bereit. Mit der Auswahl können Sie jetzt Ihre bevorzugten Branches auswählen oder schnell nach einem Branch suchen.

Branchauswahl

Empfangen von Benachrichtigungen, wenn Pull Request-Richtlinien umgangen werden

Für Teams, die Pull Requests (PRs) und Branchrichtlinienverwenden, kann es vorkommen, dass Personen diese Richtlinien außer Kraft setzen und umgehen müssen, z. B. wenn sie einen Hotfix für ein Produktionsproblem mitten in der Nacht bereitstellen. Es ist sinnvoll, Entwicklern zu vertrauen, dass sie das Richtige tun und die Außerkraftsetzungsfunktion nur selten verwenden. Gleichzeitig benötigen Teams eine Möglichkeit, zu überprüfen, ob diese Richtlinienüberschreibungen in den richtigen Situationen verwendet werden. Um dies zu unterstützen, haben wir einen neuen Benachrichtigungsfilter hinzugefügt, damit Benutzer und Teams bei jeder Umgehung einer Richtlinie E-Mail-Benachrichtigungen erhalten können. Beginnen Sie mit der Vorlage Ein Pull Request wird erstellt oder aktualisiert, und wählen Sie Richtlinienumgehung aus der Liste der Filter aus. Wählen Sie Richtlinien wurden als Wert umgangen aus, und Sie werden benachrichtigt, sobald ein PR abgeschlossen ist und Richtlinien umgangen werden.

Umgehungsrichtlinienbenachrichtigung

Umgehen von Branchrichtlinien zulassen, ohne push protection aufzugeben

Es gibt viele Szenarien, in denen Gelegentlich eine Branchrichtlinie umgangen werden muss: Kehren Sie eine Änderung zurück, die zu einer Buildunterbrechung geführt hat, wenden Sie einen Hotfix mitten in der Nacht an usw. Zuvor haben wir eine Berechtigung ("Von der Richtlinienerzwingung ausgenommen") angeboten, um Teams bei der Verwaltung zu unterstützen, welchen Benutzern die Möglichkeit gewährt wurde, Branchrichtlinien beim Abschließen eines Pull Requests zu umgehen. Diese Berechtigung gewährte jedoch auch die Möglichkeit, pushen direkt an den Branch zu pushen, wobei der PR-Prozess vollständig umgangen wurde.

Um diese Erfahrung zu verbessern, haben wir die alte Berechtigung aufgeteilt, um Teams, die Umgehungsberechtigungen erteilen, mehr Kontrolle zu bieten. Es gibt zwei neue Berechtigungen, um die alte zu ersetzen:

  1. Umgehen Sie Richtlinien, wenn Sie Pull Requests abschließen. Benutzer mit dieser Berechtigung können die "Override"-Benutzeroberfläche für Pull Requests verwenden.
  2. Umgehen Sie Richtlinien beim Pushen. Benutzer mit dieser Berechtigung können Push direkt an Branches übertragen, für die die erforderlichen Richtlinien konfiguriert sind.

Durch Erteilen der ersten Berechtigung und Verweigern der zweiten Berechtigung kann ein Benutzer bei Bedarf die Umgehungsoption verwenden, verfügt jedoch weiterhin über den Schutz vor versehentlichem Pushen an einen Branch mit Richtlinien.

Hinweis

Diese Änderung führt nicht zu Verhaltensänderungen. Benutzern, denen zuvor die Berechtigung Zulassen für die Ausnahme von der Richtlinienerzwingung gewährt wurde, wird für beide neuen Berechtigungen zulassen gewährt, sodass sie die Vervollständigung für PRs außer Kraft setzen und direkt an Branches mit Richtlinien pushen können.

Weitere Informationen finden Sie in der Dokumentation zum Festlegen von Branchberechtigungen.

Schnelles Beschreiben von Pull Requests mithilfe von Commitnachrichten

Das Schreiben beschreibender Commitnachrichten erhöht den Verlauf jedes Git-Repositorys. Um Qualitätscommitnachrichten zu fördern, erfordern neue Pull Requests (PR), die über mehrere Commits verfügen, dass Mitwirkende manuell einen Titel eingeben müssen.

Pull Request-Beschreibungen sind standardmäßig weiterhin leer, aber ein neues Feature erleichtert das Integrieren der Commitnachrichten aus den PR-Commits in die PR-Beschreibung. Um die Commitnachrichten hinzuzufügen, klicken Sie einfach auf Commitnachrichten hinzufügen, um die Commitnachrichten am Ende des PR-Beschreibungstexts anzufügen.

Erstellen von Pull Requests ohne Standardteam als Prüfer

Als wir die Pull Request-Erfahrung (PR) zum ersten Mal gestartet haben, haben wir angenommen, dass es sinnvoll wäre, alle PRs dem Teamkontext zuzuweisen, den Sie beim Erstellen des PR ausgewählt haben. Dieses Verhalten war ein Frustpunkt, da viele Personen die Verbindung zwischen dem Teamkontext und der PR-Zuweisung nicht bemerkt haben. Tatsächlich war dies einer unserer wichtigsten UserVoice-Vorschläge.

Im Rahmen der neuen Navigationsänderungen haben wir die Gelegenheit genutzt, diese Standardzuordnung zu Teams zu ändern. Sie werden zwei Änderungen feststellen:

  1. Beim Erstellen eines PR werden standardmäßig keine Prüfer hinzugefügt. Die Prüferliste verfügt über ein Feature, das das Hinzufügen von Personen und Gruppen vereinfacht, die kürzlich zu PRs hinzugefügt wurden. Die erforderliche Richtlinie für Prüfer kann auch Teams helfen, die sicherstellen möchten, dass bestimmte Prüfer hinzugefügt werden, um ihren Code zu überprüfen.
  2. Der Pull Requests-Hub verfügt über einen neuen anpassbaren Abschnitt. In diesem Abschnitt werden standardmäßig die PRs "Meinen Teams zugewiesen" angezeigt, die entsprechende Funktionen wie im alten Abschnitt bereitstellen. Wenn Sie jedoch mehreren Teams angehören, werden in diesem Abschnitt PRs angezeigt, die einem Ihrer Teams zugewiesen sind. Der Abschnitt kann auch angepasst werden. Klicken Sie einfach in der Nähe des Abschnittsheaders auf die Aktion "Diese Ansicht anpassen".

Standardisieren von Pull Request-Beschreibungen mithilfe von Vorlagen

Das Schreiben guter Pull Request-Beschreibungen ist eine hervorragende Möglichkeit, Prüfern zu helfen, zu wissen, was sie beim Überprüfen von Code erwarten sollten. Sie sind auch eine hervorragende Möglichkeit, dinge nachzuverfolgen, die für jede Änderung durchgeführt werden sollten, z. B. Tests, Hinzufügen von Komponententests und Aktualisieren der Dokumentation. Viele von Ihnen haben angefordert, dass wir Pull Request-Vorlagen hinzufügen, um teams das Schreiben hervorragender Beschreibungen zu erleichtern, und wir haben dieses Feature nun hinzugefügt.

Zusätzlich zur Unterstützung einer Standard-PR-Beschreibungsvorlage können Teams mehrere Vorlagen hinzufügen, die Ihnen in einem Menü auf der Seite "PR erstellen" angezeigt werden. Klicken Sie einfach auf die Schaltfläche Vorlage hinzufügen, um eine beliebige Vorlage im Repository auszuwählen, um sie an die PR-Beschreibung anzufügen.

Hinzufügen einer Vorlage für PR

Branchspezifische Vorlagen werden auch unterstützt, wenn Sie eine andere Vorlage für einen PR auf einen bestimmten Branch oder Branchordner anwenden möchten. Wenn Sie z. B. über eine Vorlage verfügen möchten, die für alle Branches spezifisch ist, die mit "hotfix/" beginnen, können Sie eine Vorlage hinzufügen, die für alle PRs in diesen Branches verwendet wird.

Weitere Informationen zum Erstellen und Verwenden von Vorlagen finden Sie in der Dokumentation zu Pull Request-Vorlagen.

Ändern der Zielverzweigung eines Pull Requests

Für die meisten Teams sind fast alle Pull Requests auf denselben Branch ausgerichtet, z. main B. oder develop . Wenn Sie jedoch einen anderen Branch als Ziel festlegen müssen, ist es leicht zu vergessen, den Zielverzweigung von der Standardverzweigung zu ändern. Mit dem neuen Feature zum Ändern der Zielverzweigung eines aktiven Pull Requests ist dies jetzt eine einfache Aktion. Klicken Sie einfach auf das Stiftsymbol in der Nähe des Zielverzweigungsnamens im Pull Request-Header.

Ändern der Zielverzweigung

Die Funktion zum Ändern von Zielbranches vereinfacht nicht nur das Korrigieren von Fehlern, sondern erleichtert auch das "Neuzuweisen" eines Pull Requests, wenn der Zielverzweigung zusammengeführt oder gelöscht wurde. Stellen Sie sich ein Szenario vor, in dem Sie über einen PR für einen Feature-Branch verfügen, der einige Features enthält, von denen Ihre Änderungen abhängig sind. Sie möchten Ihre abhängigen Änderungen isoliert von anderen Änderungen im Feature-Branch überprüfen, sodass Sie zunächst features/new-feature auf abzielen. Prüfer können dann nur Ihre Änderungen sehen und die entsprechenden Kommentare hinterlassen.

Überlegen Sie sich nun, was passieren würde, wenn der Feature-Branch auch über einen aktiven PR verfügt und vor ihren Änderungen mit zusammengeführt main wird? Zuvor mussten Sie Ihre Änderungen verwerfen und einen neuen PR in main erstellen, oder Ihren PR mit zusammenführen features/new-feature und dann einen weiteren PR von zu features/new-feature main erstellen. Mit dieser neuen Aktion zum Aktualisieren der Zielverzweigung können Sie einfach den Zielverzweigung des PR von in ändern features/new-feature und dabei den gesamten Kontext und die Kommentare main beibehalten. Wenn Sie den Zielverzweigung ändern, wird sogar ein neues Update für den PR erstellt, wodurch es einfach ist, vor der Änderung des Zielzweigs auf frühere Unterschiede zurückblicken zu können.

Zielverzweigungsupdate

Erweiterungsautoren können Kontext zum aktuellen Repository abfragen.

Eine der Herausforderungen für einen Autor einer Versionskontrollerweiterung besteht darin, den Kontext des Repositorys abzurufen, das dem Benutzer angezeigt wird, z. B. Name, ID und URL. Um dies zu unterstützen, haben wir versionControlRepositoryService als Dienst hinzugefügt, auf den die Erweiterung zugreifen kann. Dadurch kann ein Erweiterungsautor Informationen zum aktuellen Git-Repositorykontext innerhalb der Web-Benutzeroberfläche abfragen. Sie verfügt derzeit über eine Methode, getCurrentGitRepository().

  • Wenn ein Git-Repository ausgewählt ist, wird ein GitRepository-Objekt mit grundlegenden Daten zum Repository (Name, ID und URL) zurückgegeben.
  • Wenn ein TFVC-Repository ausgewählt ist oder auf den Dienst außerhalb der Azure Repos Seiten zugegriffen wird, wird NULL zurückgegeben.

Hier ist eine Beispielerweiterung, die diesen Dienst verwendet.

Pipelines

Verwalten von Buildpipelines mithilfe der neuen Seite "Builds"

Wir machen mehrere Verbesserungen und stellen eine neue Version der Seite Builds bereit. Diese neue Version kombiniert das Verzeichnis aller Buildpipelines und die Liste der aktuellen Builds, sodass Sie schnell durch die Builds Ihres Projekts navigieren können, um deren Status anzuzeigen. Sie enthält auch eine Vorschau der Testanalyse für die ausgewählte Pipeline.

Seite "Neue Builds"

Verwalten von Build- und Bereitstellungsabschluss-E-Mails mit verbesserter Formatierung

Build- und Bereitstellungsabschluss-E-Mails wurden aktualisiert, damit sie nach E-Mail-Regeln gefiltert werden können. Nun enthält die Betreffzeile auf einen Blick relevantere Informationen, der Text enthält weitere Details, und ihr Stil wurde mit der neuesten Marke aktualisiert.

Elemente des neuen Formats sind:

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

Hier sind einige Beispiele:

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Befolgen Sie die neue einheitliche Azure Pipelines Terminologie.

In builds und releases wurden in der Vergangenheit unterschiedliche Begriffe für ähnliche Konzepte verwendet. In anderen Fällen waren Die Bedeutungen von Begriffen ungenau. Geben Sie beispielsweise den Unterschied zwischen einem Agentpool und einer Agentwarteschlange an.

Die Terminologie wurde in Azure Pipelines vereinheitlicht, um ihre Konzepte zu verdeutlichen. Nun werden die folgenden vereinheitlichten Begriffe angezeigt:

Vorheriger Begriff Vereinheitlichter Begriff Bedeutung
Gehosteter Agent Von Microsoft gehosteter Agent Ein Build-/Release-Agent, der in einer von Microsoft verwalteten, in der Cloud gehosteten Infrastruktur ausgeführt wird.
Privater Agent Selbstgehosteter Agent Ein Build-/Release-Agent, der auf einem von Ihnen bereitgestellten und verwalteten Computer ausgeführt wird.
Agent-Pool Agent-Pool Eine Gruppe von Agentcomputern auf Organisationsebene, die Builds oder Releases ausführen können.
Agent-Warteschlange Agent-Pool Eine Gruppe von Agentcomputern auf Projektebene, die Builds oder Releases ausführen können. Sie ist mit einem Agentpool auf Organisationsebene verknüpft.
Builddefinition Buildpipeline Ein End-to-End-Satz von Buildschritten für eine Anwendung.
Erstellen Erstellen Eine Instanz einer Buildpipeline, die ausgeführt wird oder ausgeführt wurde.
Phase Auftrag Eine Reihe von Aufgaben, die sequenziell oder parallel auf einem Agent ausgeführt werden. Eine Build- oder Releasepipeline kann einen Auftrag oder ein Diagramm mehrerer Aufträge enthalten.
Releasedefinition Releasepipeline Eine End-to-End-Reihe von Releaseschritten für eine Anwendung, die in verschiedenen Phasen bereitgestellt werden soll.
Freigabe Freigabe Eine Instanz einer Releasepipeline, die ausgeführt wird oder ausgeführt wurde.
Environment Phase Eine logische und unabhängige Entität, die den Ort darstellt, an dem Sie ein release generiertes Release aus einer Releasepipeline bereitstellen möchten.
Gleichzeitiger Auftrag/Pipeline Paralleler Auftrag Mit einem parallelen Auftrag können Sie einen einzelnen Build- oder Releaseauftrag gleichzeitig in Ihrer Organisation ausführen. Wenn mehr parallele Aufträge verfügbar sind, können Sie mehr Build- und Releaseaufträge gleichzeitig ausführen.
Dienstendpunkt Dienstverbindung Eine Gruppe von Einstellungen, z. B. Anmeldeinformationen, die zum Herstellen einer Verbindung mit externen Diensten verwendet werden, um Aufgaben in einem Build oder Release auszuführen.

Weitere Informationen finden Sie in der Dokumentation zu Konzepten.

Verwalten von Releasepipelines mithilfe der neuen Seite "Releases"

Für die Landing Page des Release ist eine neue und vollständig überarbeitete Benutzeroberfläche verfügbar. Auf der linken Seite finden Sie eine Liste der Releasepipelines, die Sie häufig veröffentlichen. Sie können ihre Pipelines auch durchsuchen und als Favoriten verwenden.

Landing Page des Release

Wechseln Sie zur Ordneransicht, um Ordner für Organisation und Sicherheit zu erstellen. Die Sicherheit kann auf Ordnerebene festgelegt werden.

Releaseordner

Visualisieren des Releasefortschritts

Die Statusansicht des neuen Release bietet Ihnen Liveupdates zum Bereitstellungsfortschritt und Zugriff mit nur einem Klick auf weitere Details. Die neue Ansicht visualisiert die Releasepipeline und erleichtert das Verständnis, was passiert, und zeigt entsprechende Details und Aktionen in verschiedenen Phasen des Release an.

Releasepipelineansicht

Pipeline, Releasedetails und Umgebungen

In der Ansicht Pipeline werden die Artefakte des Release und die Umgebungen angezeigt, in denen sie bereitgestellt werden. Der Bereich Release enthält Releasedetails wie den Releasetrigger, Artefaktversionen und Tags.

Umgebungen werden so modelliert, dass sie ihren Status und den detaillierten Fortschritt besser verstehen. Sie können jederzeit zu den Protokollen kommen, indem Sie in der Umgebung auf den Statuslink klicken.

Umgebungen

Vor und nach der Bereitstellung

Wenn bedingungen vor der Bereitstellung oder nach der Bereitstellung für eine Umgebung festgelegt wurden, wird dies in der Umgebung mit den Genehmigungen und Gates angegeben. Der Status von Genehmigungen und Gates wird auch im Status der Umgebung angezeigt. Sie können Maßnahmen ergreifen oder weitere Details anzeigen, indem Sie auf das Bedingungssymbol der Umgebung klicken, das rechts oder links von der Umgebung hängt.

Releaseumgebungsaktionen

Commits und Arbeitselemente

Mit jedem neuen Release können Sie die Liste der zugeordneten Commits und Arbeitselemente für jede Umgebung separat anzeigen, indem Sie auf die Umgebung klicken. Wenn die Liste lang ist, verwenden Sie Filter, um einen Commit oder ein Arbeitselement zu finden, an dem Sie interessiert sind.

Release-Commits und Arbeitselemente

Bereitstellungsfortschritt und Protokolle

Die Umgebungen zeigen Liveupdates für in Bearbeitung ausgeführte Bereitstellungen an, einschließlich der Abgeschlossene Phasen und Aufgaben sowie der Ausführungszeit. Wenn Sie auf den Umgebungsstatus klicken, wird eine Ansicht mit den Protokollen geöffnet, und der Fokus liegt auf dem, was derzeit aktiv ist.

Sie können in die Protokolle klicken, um eine fokussierte Ansicht zu öffnen.

Releaseprotokolldetails

Auswirkungen des Upgrades auf Azure DevOps Server 2019 auf Aufgaben: Windows Computerdateikopie und PoweShell auf dem Zielcomputer

Computergruppen unter Dem Testhub wurden in TFS 2017 RTM als veraltet bezeichnet. Ab Azure DevOps Server 2019 ist der Computergruppendienst nicht mehr verfügbar. Dies wirkt sich auf die Benutzer der Taskversion 1 Windows Computerdateikopieraufgabe* und der Taskversion 1.* von PowerShell auf Zielcomputern aus. Damit Ihre Pipelines weiterhin funktionieren,

  • Sie müssen zur Taskversion 2 Windows Computerdateikopie wechseln und den vollständigen FQDN für den Zielcomputer anstelle des Computernamens angeben.
  • Wechseln Sie zu "Powershell auf Zielcomputer", Version 2.* oder höher, und geben Sie den vollständigen FQDN des Computers oder Computernamens gefolgt von den Windows-Remoteverwaltungsports (http/https) an. Beispiel: targetMachine:5985 oder targetMachine:5986

Testergebnisse und Erweiterbarkeit

Ergebnisse der Testausführung werden auch für jede Umgebung angezeigt. Wenn Sie auf die Testergebnisse klicken, wird eine Ansicht mit Testdetails geöffnet, einschließlich der Ergebnisse anderer Erweiterungen, die zum Prozess beitragen.

Releasetestergebnisse

Vorhandene Erweiterungen funktionieren in dieser neuen Ansicht, und es gibt neue Erweiterungspunkte, mit denen Erweiterungen noch mehr Informationen für eine Umgebung anzeigen können. Weitere Informationen finden Sie in der Dokumentation zu Beiträgen und Erweiterungen.

Konfigurieren von Builds mit YAML

YAML-basierte Buildpipelines sind in Ihrer Azure DevOps Server. Automatisieren Sie Ihre Continuous Integration-Pipeline mithilfe einer YAML-Datei, die in Ihr Repository eingecheckt ist. Eine vollständige Referenz für das YAML-Schema finden Sie hier.

Um YAML-basierte Buildpipelines nahtloser zu unterstützen, haben wir das Standardverhalten für alle neuen Ressourcen, die Sie erstellen (z. B. Dienstverbindungen, variablen Gruppen, Agentpools und sichere Dateien), so geändert, dass es in allen Pipelines dieses Projekts verwendet werden kann. Wenn Sie eine strengere Kontrolle über Ihre Ressourcen wünschen, können Sie das Standardautorisierungsmodell deaktivieren (siehe Abbildung unten). Wenn Sie dies tun, muss eine Person mit Berechtigungen zur Verwendung der Ressource die Pipeline explizit im Web-Editor speichern, nachdem der YAML-Datei ein Ressourcenverweis hinzugefügt wurde.

YAML

Große Produkte verfügen über mehrere Komponenten, die voneinander abhängig sind. Diese Komponenten werden häufig unabhängig voneinander erstellt. Wenn sich eine Upstreamkomponente (z. B. eine Bibliothek) ändert, müssen die Downstreamabhängigkeiten neu erstellt und erneut überprüfen werden. Teams diese Abhängigkeiten in der Regel manuell verwalten.

Jetzt können Sie einen Build nach dem erfolgreichen Abschluss eines anderen Build auslösen. Artifacts von einem Upstream-Build erzeugten Daten können heruntergeladen und im späteren Build verwendet werden, und Sie können auch Daten aus diesen Variablen erhalten: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Weitere Informationen finden Sie in der Dokumentation zu Buildtriggern.

Einrichten der Buildkette

Denken Sie daran, dass in einigen Fällen ein einzelner mehrstufiger Build Ihre Anforderungen erfüllen kann. Ein Buildabschlusstrigger ist jedoch nützlich, wenn Ihre Anforderungen unterschiedliche Konfigurationseinstellungen, Optionen oder ein anderes Team enthalten, das den abhängigen Prozess besitzt.

Lokales Aktualisieren des Agents

Aufgaben, die Sie aus dem Katalog installieren, erfordern manchmal eine neuere Version des Pipeline-Agents. Wenn Ihr Azure DevOps Server mit dem Internet verbinden kann, werden neuere Versionen automatisch heruntergeladen. Falls nicht, müssen Sie jeden Agent manuell aktualisieren. Ab diesem Release können Sie Ihre Azure DevOps Server so konfigurieren, dass sie nach den Agent-Paketdateien auf dem lokalen Datenträger und nicht über das Internet sucht. Dies bietet Ihnen flexibilität und Kontrolle darüber, welche Agent-Versionen Sie zur Verfügung stellen, ohne Ihre Azure DevOps Server im Internet verfügbar machen zu müssen.

Badge-URL für neuen Buildstatus

Buildbadge, die in die Startseite eines Repositorys eingebettet sind, sind eine gängige Methode, um die Integrität des Repositorys zu zeigen. Obwohl wir bisher Buildbadge hatten, gab es einige Probleme:

  • Die URL war nicht intuitiv
  • Der Badge war nicht spezifisch für einen Branch.
  • Es gab keine Möglichkeit für einen Benutzer, auf den Badge zu klicken, um den Benutzer zum neuesten Build dieser Definition zu nehmen.

Wir führen jetzt eine neue API für Build badges ein, die diese Probleme löst. Mit der neuen API können Benutzer einen Status pro Branch veröffentlichen und Benutzer zum neuesten Build des ausgewählten Branchs weiterverstellen. Sie können markdown für die neue Statusbadge-URL erhalten, indem Sie auf der neuen Seite Builds die Menüaktion Statusbadge auswählen.

Aus Gründen der Abwärtskompatibilität werden wir weiterhin auch die älteren Buildbadge-URLs verwenden.

Hinzufügen benutzerdefinierter Buildindikatoren zu Ihren Builds

Buildindikatoren bieten eine Möglichkeit, Builds eindeutig zu nummeriert und zu kennzeichnen. Zuvor konnten Sie die spezielle Variable $(rev:r) verwenden, um dies zu erreichen. Nun können Sie ihre eigenen Indikatorvariablen in Ihrer Builddefinition definieren, die bei jeder Ausführung eines Build automatisch erhöht werden. Dies ist auf der Registerkarte Variablen einer Definition der Fall. Dieses neue Feature bietet Ihnen mehr Leistung auf folgende Weise:

  • Sie können einen benutzerdefinierten Indikator definieren und dessen Startwert festlegen. Beispielsweise können Sie Ihren Zähler bei 100 starten. $(rev:r) beginnt immer bei 0.
  • Sie können ihre eigene benutzerdefinierte Logik verwenden, um einen Zähler zurückzusetzen. $(rev:r) ist an die Buildnummerngenerierung gebunden und wird automatisch zurückgesetzt, wenn ein neues Präfix in der Buildnummer vorhanden ist.
  • Sie können mehrere Leistungsindikatoren pro Definition definieren.
  • Sie können den Wert eines Leistungsindikators außerhalb eines Builds abfragen. Beispielsweise können Sie die Anzahl der Builds, die seit der letzten Zurücksetzung ausgeführt wurden, mithilfe eines Zählers zählen.

Weitere Informationen zu Buildindikatoren finden Sie in der Dokumentation zu benutzerdefinierten Variablen.

Azure Policy von Konformitäts- und Sicherheitsüberprüfungen in Pipelines

Wir möchten die Stabilität und Sicherheit von Software frühzeitig im Entwicklungsprozess sicherstellen und gleichzeitig Entwicklung, Sicherheit und Betrieb zusammenführen. Zu diesem Zwecke haben wir Unterstützung für Azure Policyhinzugefügt.

Dank Azure Policy können Sie mithilfe von Richtliniendefinitionen, die Regeln und Aktionen für Ihre Ressourcen erzwingen, IT-Probleme verwalten und verhindern. Wenn Sie Azure Policy verwenden, bleiben Ressourcen stets konform mit Ihren Unternehmensstandards und Vereinbarungen zum Servicelevel.

Um die Compliance- und Sicherheitsrichtlinien im Rahmen des Releaseprozesses zu erfüllen, haben wir unsere Bereitstellungsumgebung für Azure-Ressourcengruppen verbessert. Nun treten bei der Bereitstellungsaufgabe für Azure-Ressourcengruppen bei Verstößen beim Bereitstellen von ARM-Vorlagen relevante richtlinienbezogene Fehler auf.

Azure Policy

Darüber hinaus haben wir Azure Policy Releasedefinitionsvorlage hinzugefügt. Dadurch können Benutzer Azure-Richtlinien erstellen und diese Richtlinien Ressourcen, Abonnements oder Verwaltungsgruppen aus der Releasedefinition selbst zuweisen.

Azure Policy Vorlage

Erstellen auf Linux-/ARM- und Windows 32-Bit-Plattformen

Der Azure Pipelines plattformübergreifenden Open Source-Agent wurde immer auf 64-Bit-Windows, macOS und Linux unterstützt. Mit diesem Release werden zwei neue unterstützte Plattformen eingeführt: Linux/ARM und Windows/32-Bit. Mit diesen neuen Plattformen können Sie auf weniger gängigen, aber nicht weniger wichtigen Plattformen wie raspberry Pi, einem Linux-/ARM-Computer, aufbauen.

Verbesserte Funktionen für Tests in Pipelines

Die Registerkarte "Tests" verfügt jetzt über eine moderne Benutzeroberfläche, mit der Sie umfassende Kontexttestinformationen für Pipelines erhalten. Die neue Benutzeroberfläche bietet eine Testansicht in Bearbeitung, ein vollständiges Seitendebuggen im Kontexttestverlauf, die Meldung abgebrochener Testausführungen und eine Zusammenfassung auf Ausführungsebene.

Neuer Testhub

Anzeigen der Ausführung laufender Tests

Tests, z. B. Integrations- und Funktionstests, können für einen langen Zeitraum ausgeführt werden, daher ist es wichtig, die Testausführung zu einem beliebigen Zeitpunkt zu sehen. Mit dem In-Progress Testansicht müssen Sie nicht mehr warten, bis die Testausführung abgeschlossen ist, um das Testergebnis zu kennen. Ergebnisse sind nahezu in Echtzeit verfügbar, da sie ausgeführt werden, wodurch Sie schneller Maßnahmen ergreifen können. Sie können einen Fehler debuggen oder abbrechen, einen Fehler melden oder die Pipeline abbrechen. Das Feature ist derzeit sowohl für Build- als auch für Releasepipelines verfügbar, die den VS-Testtask in der Multi-Agent-Phase verwenden, Testergebnisse Task veröffentlichen oder Testergebnisse mithilfe von API(s) veröffentlichen. In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Die folgende Ansicht zeigt die In-Progress Testzusammenfassung in der neuen Statusansicht des Release, die die Gesamtanzahl der Tests und die Anzahl der Testfehler zu einem bestimmten Zeitpunkt meldet.

Testansicht in Bearbeitung

Wenn Sie oben auf die In-Progress Testzusammenfassung klicken, können Sie die ausführliche Testzusammenfassung zusammen mit fehlgeschlagenen oder abgebrochenen Testinformationen in Test Plans anzeigen. Die Testzusammenfassung wird in regelmäßigen Abständen mit der Möglichkeit aktualisiert, die Detailansicht bei Bedarf basierend auf der Verfügbarkeit neuer Ergebnisse zu aktualisieren.

Detaillierte Testzusammenfassung

Anzeigen von Details zum Debuggen von Testläufen auf der vollständigen Seite

Fehlermeldungen und Stapelüberwachungen sind lang und benötigen genügend Platz, um die Details während des Debuggens anzuzeigen. Um ein immersives Debuggen zu ermöglichen, können Sie jetzt die Test- oder Testlaufansicht auf die vollständige Seitenansicht erweitern, während Sie weiterhin die erforderlichen Vorgänge in Kontextvorgängen wie Fehlererstellung oder Anforderungszuordnung für das aktuelle Testergebnis ausführen können.

Debuggen auf der ganzen Seite

Anzeigen des Testverlaufs im Kontext

In der Vergangenheit mussten Teams zum Hub "Ausführungen" wechseln, um den Verlauf eines Testergebnisses anzuzeigen. Mit der neuen Benutzeroberfläche bringen wir den Testverlauf direkt in den Kontext Test Plans Registerkarte für Build und Release. Die Testverlaufsinformationen werden auf progressive Weise bereitgestellt, beginnend mit der aktuellen Builddefinition oder Umgebung für den ausgewählten Test, gefolgt von anderen Branches und Umgebungen für den Build bzw. das Release.

Testverlauf im Kontext

Anzeigen abgebrochener Tests

Die Testausführung kann aus mehreren Gründen abgebrochen werden, z. B. aufgrund von fehlerhaftem Testcode, getesteter Quelle und Umgebungsproblemen. Unabhängig vom Grund für den Abbruch ist es wichtig, dass Sie das Verhalten diagnostizieren und die Grundursache identifizieren. Sie können nun die abgebrochenen Tests und Testläufe neben den abgeschlossenen Ausführungen in Test Plans anzeigen. Das Feature ist derzeit sowohl für Build- als auch für Releasepipelines mithilfe des VS-Testtasks in der Multi-Agent-Phase oder für die Veröffentlichung von Testergebnissen mithilfe von API(en) verfügbar. In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Anzeigen abgebrochener Tests

Unterstützung von Testablaufverfolgungs- und Releaseumgebungen im Testverlauf

Wir fügen Unterstützung für das Anzeigen des Verlaufs eines automatisierten Tests hinzu, der nach verschiedenen Releaseumgebungen gruppiert ist, in denen der Test ausgeführt wird. Wenn Sie Releaseumgebungen als Releasepipelines oder Testumgebungen modellieren und Tests in solchen Umgebungen ausführen, können Sie herausfinden, ob ein Test in der Entwicklungsumgebung bestanden wird, aber in der Integrationsumgebung fehlschlägt. Sie könnten herausfinden, ob es das englische Gebietsschema übergibt, aber in einer Umgebung mit dem gebietsschema "Türkisch" fehlschlägt. Für jede Umgebung finden Sie den Status des letzten Testergebnisses. Wenn der Test in dieser Umgebung fehlgeschlagen ist, finden Sie auch das Release, seit dem der Test fehlgeschlagen ist.

Überprüfen zusammengefasster Testergebnisse

Während der Testausführung kann ein Test mehrere Instanzen von Tests ergeben, die zum Gesamtergebnis beitragen. Einige Beispiele sind: Tests, die aufgrund von Fehlern erneut durchgeführtwerden, Tests, die aus einer geordneten Kombination anderer Tests bestehen (z. B. geordneter Test), oder Tests mit unterschiedlichen Instanzen, die auf dem bereitgestellten Eingabeparameter basieren (datengesteuerte Tests). Da diese Tests miteinander in Beziehung stehen, müssen sie zusammen mit dem auf den einzelnen Testergebnissen abgeleiteten Gesamtergebnis gemeldet werden. Mit diesem Update wird eine verbesserte Version der Testergebnisse eingeführt, die in einer Version auf der Registerkarte Tests als Hierarchie angezeigt wird. Schauen wir uns ein Beispiel an.

Zuvor haben wir die Möglichkeit eingeführt, fehlgeschlagene Tests im VS-Testtask erneut durchzuführen. Wir haben jedoch nur den letzten Testversuch gemeldet, der die Nützlichkeit dieses Features einschränkt. Wir haben dieses Feature nun erweitert, um jede Instanz der Testausführung als Versuch zu melden. Darüber hinaus unterstützt der Test Verwaltungs-API jetzt die Möglichkeit, hierarchische Testergebnisse zu veröffentlichen und abzufragen. Weitere Informationen finden Sie in der Dokumentation zur Testergebnis-API.

Debuggen der Testzusammenfassung

Hinweis

Metriken im Abschnitt mit der Testzusammenfassung (z. B. Tests gesamt, erfolgreich usw.) werden mithilfe der Stammebene der Hierarchie und nicht mit jeder einzelnen Iteration der Tests berechnet.

Anzeigen von Testanalysen in Pipelines

Die Nachverfolgung der Testqualität im Laufe der Zeit und die Verbesserung der Testmaterialien ist der Schlüssel zum Aufrechterhalten einer fehlerfreien Pipeline. Das Testanalysefeature bietet nahezu in Echtzeit Einblick in Ihre Testdaten für Builds und Releasepipelines. Sie trägt zur Verbesserung der Effizienz Ihrer Pipeline bei, indem sich wiederholende Probleme mit hoher Auswirkung auf die Qualität identifiziert werden.

Sie können Testergebnisse nach verschiedenen Elementen gruppieren, schlüsselbezogene Tests für Ihre Branch- oder Testdateien identifizieren oder einen Drilldown zu einem bestimmten Test durchführen, um Trends anzuzeigen und Qualitätsprobleme wie z. B. Unzuverlässigkeit zu verstehen.

Zeigen Sie test analytics for builds and release (Testanalyse für Builds und Release)an, vorschau unten:

Testanalyse

Weitere Informationen finden Sie in unserer Dokumentation.

Vereinfachen von Definitionen mit mehreren Aufgaben ohne Agent

Aufgaben in einer Phase ohne Agent werden von orchestriert und auf dem Server ausgeführt. Für Phasen ohne Agent sind weder ein Agent noch Zielcomputer erforderlich. Im Gegensatz zu Agentphasen konnte jeder Phase ohne Agent in den Definitionen nur eine Aufgabe hinzugefügt werden. Dies bedeutete, dass mehrere Phasen hinzugefügt werden mussten, wenn mehr als ein Task ohne Agent im Prozess vorhanden war, wodurch die Definition massenig wurde. Wir haben diese Einschränkung gelockert, wodurch Sie mehrere Aufgaben in phasenlosen Phasen verwalten können. Die Aufgaben in derselben Phase würden sequenziell ausgeführt werden, genau wie bei Agentphasen. Weitere Informationen finden Sie in der Dokumentation zu Serverphasen.

Schrittweises Verfügbar machen und Stufen von Bereitstellungen mithilfe von Releasegates

Mithilfe von Releasegates können Sie Anwendungszustandskriterien angeben, die erfüllt sein müssen, bevor ein Release in die nächste Umgebung heraufgestuft wird. Alle angegebenen Gates werden regelmäßig vor oder nach einer Bereitstellung ausgewertet, bis alle erfolgreich sind. Vier Arten von Gates sind sofort verfügbar, und Sie können weitere Gates aus dem Marketplacehinzufügen. Sie können überprüfen, ob alle erforderlichen Kriterien für eine Bereitstellung erfüllt wurden. Weitere Informationen finden Sie in der Dokumentation zu Releasegates.

Bereich "Releasegates"

Bereitstellungen halten, bis Gates konsistent erfolgreich sind

Releasegates ermöglichen die automatische Auswertung von Integritätskriterien, bevor ein Release auf die nächste Umgebung heraufgestuft wird. Standardmäßig wird das Release nach dem Empfang eines erfolgreichen Beispiels für alle Gates ausgeführt. Auch wenn ein Gate unregelmäßig ist und die erfolgreiche Stichprobe Rauschen ist, wird die Freigabe ausgeführt. Um diese Arten von Problemen zu vermeiden, können Sie jetzt das Release so konfigurieren, dass die Konsistenz der Integrität für eine mindestdauer überprüft wird, bevor der Fortschritt fortschreitet. Zur Laufzeit stellt das Release sicher, dass aufeinanderfolgende Auswertungen der Gates erfolgreich sind, bevor die Heraufstufung zugelassen wird. Die Gesamtzeit für die Auswertung hängt von der "Zeit zwischen erneuter Auswertung" ab und liegt in der Regel über der konfigurierten Mindestdauer. Weitere Informationen finden Sie in der Dokumentation release deployment control using gates (Steuerung der Releasebereitstellung mit Gates).

Gates-Hold-Einstellung

Automatische Bereitstellung für neue Ziele in einer Bereitstellungsgruppe

Als einer Bereitstellungsgruppe neue Ziele hinzugefügt wurden, war zuvor eine manuelle Bereitstellung erforderlich, um sicherzustellen, dass alle Ziele über das gleiche Release verfügen. Sie können jetzt die Umgebung so konfigurieren, dass das letzte erfolgreiche Release automatisch für die neuen Ziele bereitgestellt wird. Weitere Informationen finden Sie in der Dokumentation zu Bereitstellungsgruppen.

Bereitstellungsgruppen

Kontinuierliches Bereitstellen von Builds mit Tags nach der Buildverarbeitung

Continuous Deployment-Trigger erstellen nach Abschluss des Builds ein Release. Manchmal werden Builds jedoch nachverarbeitet, und der Build sollte erst nach Abschluss dieser Verarbeitung freigegeben werden. Jetzt können Sie Buildtags nutzen, die während der Nachverarbeitung in den Triggerfiltern des Release zugewiesen werden.

Buildtagtrigger

Festlegen einer Variablen zur Freigabezeit

In einer Releasedefinition können Sie jetzt die Variablen auswählen, die Sie beim Erstellen des Release festlegen möchten.

Releasevariable

Der Wert, der beim Erstellen des Release für die Variable angegeben wird, wird nur für dieses Release verwendet. Dieses Feature hilft Ihnen dabei, mehrere Schritte für "Create-in-Draft" zu vermeiden, die Variablen im Entwurf zu aktualisieren und das Release mit der Variablen auszulösen.

Releasevariable im Release

Übergeben von Umgebungsvariablen an Aufgaben

CI/CD-Taskautoren können eine neue Eigenschaft , showEnvironmentVariables,in task.json festlegen, um Umgebungsvariablen an Aufgaben zu übergeben. Wenn Sie dies tun, wird ein zusätzliches Steuerelement für die Aufgabe im Build-Editor gerendert. Dies ist für die PowerShell-, Cmd- und Bash-Aufgaben verfügbar.

Übergeben von Umgebungsvariablen

Dies ermöglicht zwei Szenarien:

  • Für eine Aufgabe ist eine Umgebungsvariable erforderlich, bei der die Case-Schreibung im Variablennamen beibehalten wird. Im obigen Beispiel wäre die an den Task übergebene Umgebungsvariable beispielsweise "foo" und nicht "FOO".
  • Sie ermöglicht die sichere Weitergabe von Geheimniswerten an die Skripts. Dies wird bevorzugt, wenn die Geheimnisse als Argumente an die Skripts übergeben werden, da das Betriebssystem auf dem Agent den Aufruf von Prozessen einschließlich ihrer Argumente protokollieren kann.

Klonen von Variablengruppen

Wir haben Unterstützung für das Klonen von Variablengruppen hinzugefügt. Wenn Sie eine Variablengruppe replizieren und nur einige der Variablen aktualisieren möchten, müssen Sie den mühsamen Prozess zum Hinzufügen von Variablen nacheinander nicht durchlaufen. Sie können jetzt schnell eine Kopie Ihrer Variablengruppe erstellen, die Werte entsprechend aktualisieren und als neue Variablengruppe speichern.

Klonen einer Variablengruppe

Hinweis

Die Werte der geheimen Variablen werden nicht kopiert, wenn Sie eine Variablengruppe klonen. Sie müssen die verschlüsselten Variablen aktualisieren und dann die geklonte Variablengruppe speichern.

Ignorieren eines Releasegates für eine Bereitstellung

Releasegates ermöglichen die automatische Auswertung von Integritätskriterien, bevor ein Release auf die nächste Umgebung heraufgestuft wird. Standardmäßig wird die Releasepipeline nur ausgeführt, wenn alle Gates gleichzeitig fehlerfrei sind. In bestimmten Situationen, z. B. beim Beschleunigen eines Release oder nach der manuellen Überprüfung der Integrität, möchte eine genehmigende Person möglicherweise ein Gate ignorieren und zulassen, dass das Release ausgeführt wird, auch wenn dieses Gate noch nicht als fehlerfrei ausgewertet werden muss. Weitere Informationen finden Sie in der Dokumentation zu Releasegates.

Gates ignorieren

Durchführen zusätzlicher Tests mithilfe eines Pull Request-Releasetriggers

Sie konnten einen Build basierend auf einem Pull Request (PR) auslösen und dieses schnelle Feedback vor einer Zusammenführung für eine Weile erhalten. Jetzt können Sie auch einen PR-Trigger für ein Release konfigurieren. Der Status des Release wird an das Code-Repository zurückgestellt und kann direkt auf der PR-Seite angezeigt werden. Dies ist hilfreich, wenn Sie zusätzliche funktionale oder manuelle Tests als Teil Ihres PR-Workflows durchführen möchten.

PR-Trigger in Release

Erstellen einer Azure-Dienstverbindung mit einem Dienstprinzipal, der sich mit einem Zertifikat authentifiziert

Sie können jetzt eine Azure-Dienstverbindung mit einem Dienstprinzipal und einem Zertifikat für die Authentifizierung definieren. Da die Azure-Dienstverbindung jetzt den Dienstprinzipal unterstützt, der sich mit einem Zertifikat authentifiziert, können Sie jetzt in Azure Stack bereitstellen, die mit AD FSkonfiguriert sind. Informationen zum Erstellen eines Dienstprinzipals mit Zertifikatauthentifizierung finden Sie im Artikel zum Erstellen eines Dienstprinzipals,der mit einem Zertifikat authentifiziert wird.

Verbindung über Dienstprinzipal herstellen

Ausführen von Paketen, die in Azure App Service-Bereitstellungen unterstützt werden

Die Version Azure App Service Deploy-Aufgabe (4.*) unterstützt jetzt RunFromPackage (zuvor als RunFromZipbezeichnet).

App Service unterstützt eine Reihe verschiedener Verfahren zum Bereitstellen Ihrer Dateien, z. B. msdeploy (auch bekannt als WebDeploy), Git, ARM und mehr. Alle diese Techniken haben jedoch eine Einschränkung. Ihre Dateien werden im Ordner wwwroot (insbesondere d:\home\site\wwwroot) bereitgestellt, und die Runtime führt dann die Dateien von dort aus aus.

Bei "Aus Paket ausführen" gibt es keinen Bereitstellungsschritt mehr, der die einzelnen Dateien in wwwroot kopiert. Stattdessen verweisen Sie einfach auf eine ZIP-Datei, und die ZIP-Datei wird auf wwwroot als schreibgeschütztes Dateisystem eingebunden. Dies hat mehrere Vorteile:

  • Reduziert das Risiko von Sperrungen beim Kopieren von Dateien.
  • Kann in einer Produktions-App (mit Neustart) bereitgestellt werden.
  • Sie können sich sicher sein, dass die Dateien, die in Ihrer App ausgeführt werden, sicher sind.
  • Verbessert die Leistung von Azure App Service Bereitstellungen.
  • Kann Kaltstartzeiten verringern, insbesondere für JavaScript-Funktionen mit großen npm-Paketstrukturen.

Bereitstellen von Linux-Containern mit dem Task "App Server Deploy"

Die 4.*-Version der Aufgabe Azure App Service Bereitstellen unterstützt jetzt die Bereitstellung Ihres eigenen benutzerdefinierten Containers für Azure Functions unter Linux.

Das Linux-Hostingmodell für Azure Functions basiert auf Docker-Containern, die mehr Flexibilität in Bezug auf die Paketierung und Nutzung app-spezifischer Abhängigkeiten bieten. Funktionen unter Linux können in zwei verschiedenen Modi gehostet werden:

  1. Integriertes Containerimage: Sie verwenden den Funktions-App-Code, und Azure stellt den Container bereit und verwaltet diesen (integrierter Imagemodus), sodass keine spezifischen Docker-bezogenen Kenntnisse erforderlich sind. Dies wird in der vorhandenen Version des Tasks App Service Bereitstellen unterstützt.
  2. Benutzerdefiniertes Containerimage: Wir haben die Aufgabe App Service Bereitstellen erweitert, um die Bereitstellung von benutzerdefinierten Containerimages in Azure Functions unter Linux zu unterstützen. Wenn Ihre Funktionen eine bestimmte Sprachversion oder eine bestimmte Abhängigkeit oder Konfiguration benötigen, die nicht im integrierten Image bereitgestellt wird, können Sie mithilfe von Azure Pipelines ein benutzerdefiniertes Image für Azure Functions unter Linux erstellen und bereitstellen.

Der Xcode-Task unterstützt neu veröffentlichte Xcode 10-

Zusammen mit der Apple-Veröffentlichung von Xcode 10 können Sie ihre Projekte jetzt so festlegen, dass sie speziell mit Xcode 10 erstellt oder getestet werden. Ihre Pipeline kann Aufträge auch parallel zu einer Matrix von Xcode-Versionen ausführen. Sie können den von Microsoft gehosteten macOS-Agentpool verwenden, um diese Builds auszuführen. Weitere Informationen finden Sie in der Anleitung zur Verwendung von Xcode in Azure Pipelines.

Xcode 10

Optimieren der Bereitstellung in Kubernetes mit Helm

Helm ist ein Tool, das die Installation und Verwaltung von Kubernetes-Anwendungen optimiert. Sie hat im letzten Jahr auch eine große Beliebtheit und Communityunterstützung erlangt. Eine Helm-Aufgabe in Release ist jetzt zum Packen und Bereitstellen von Helm-Charts in Azure Container Service (AKS) oder einem anderen Kubernetes-Cluster verfügbar.

Mit dem Hinzufügen dieser Helm-Aufgabe können Sie nun eine Helm-basierte CI/CD-Pipeline für die Bereitstellung von Containern in einem Kubernetes-Cluster einrichten. Weitere Informationen finden Sie in der Dokumentation Deploy using Kubernetes to Azure Container Service (Bereitstellen mit Kubernetes in Azure Container Service).

Helm-Aufgaben

Steuern der in Release verwendeten Helm-Version

Der Helm-Toolinstallationstask beschafft eine bestimmte Version von Helm aus dem Internet oder dem Toolscache und fügt sie dem PFAD des Agents (gehostet oder privat) hinzu. Verwenden Sie diese Aufgabe, um die Version von Helm zu ändern, die in nachfolgenden Aufgaben wie der .NET Core-CLI-Aufgabe verwendet wird. Wenn Sie diese Aufgabe vor der Helm Deploy-Aufgabe in einer Build- oder Releasedefinition hinzufügen, stellen Sie sicher, dass Sie Ihre App mit der richtigen Helm-Version verpacken und bereitstellen. Diese Aufgabe hilft auch bei der optionalen Installation des Kubectl-Tools, das eine Voraussetzung für die Funktion von Helm ist.

Kontinuierliche Bereitstellung in Azure Database for MySQL

Sie können die Bereitstellung jetzt kontinuierlich in Azure Database for MySQL – Der MySQL-Datenbank-as-a-Service von Azure – durchführen. Verwalten Sie Ihre MySQL-Skriptdateien in der Versionskontrolle, und stellen Sie sie kontinuierlich als Teil einer Releasepipeline mithilfe einer nativen Aufgabe anstelle von PowerShell-Skripts bereit.

Verwenden von verbesserten Windows PowerShell-remotebasierten Aufgaben

Neue und verbesserte Windows PowerShell-Remoteaufgaben sind verfügbar. Diese Verbesserungen umfassen mehrere Leistungskorrekturen und unterstützen Liveprotokolle und Konsolenausgabebefehle wie Write-Host und Write-Output.

PowerShell auf Zielaufgabe (Version: 3.*): Sie können Inlineskript hinzufügen, PSSession-Optionen ändern, "ErrorActionPreference" steuern und bei Standardfehlern einen Fehler ausführen.

Azure-Dateikopiertask (Version: 2.*): Wird mit dem neuesten AzCopy -Code (v7.1.0) geliefert, der ein GitHub Problem behandelt.

Filtern von Branches nach GitHub Enterprise oder externen Git-Artefakten

Beim Freigeben von GitHub Enterprise oder externen Git-Repositorys können Sie nun die spezifischen Branches konfigurieren, die veröffentlicht werden. Beispielsweise können Sie nur Builds bereitstellen, die aus einem bestimmten Branch für die Produktion kommen.

Branchfilter

Erstellen von in Go geschriebenen Anwendungen

Verwenden Sie den Task "Go Tool Installer", um eine oder mehrere Versionen des Go-Tools direkt zu installieren. Diese Aufgabe übernimmt eine bestimmte Version des Go-Tools, die für Ihr Projekt erforderlich ist, und fügt sie dem PFAD des Build-Agents hinzu. Wenn die Zielversion des Go-Tools bereits auf dem Agent installiert ist, überspringt diese Aufgabe den Prozess des Herunterladens und erneuten Installierens.

Mit der Go-Aufgabe können Sie Abhängigkeiten herunterladen, Ihre Anwendung erstellen oder testen. Sie können diese Aufgabe auch verwenden, um einen benutzerdefinierten Go-Befehl Ihrer Wahl auszuführen.

Ausführen von Inline- oder dateibasierten Python-Skripts in Ihrer Pipeline

Eine neue Python-Skriptaufgabe vereinfacht die Ausführung von Python-Skripts in Ihrer Pipeline. Der Task wird ein Skript aus einer Python-Datei (.py) in Ihrem Repository ausführen, oder Sie können manuell ein Skript in die Einstellungen der Aufgabe eingeben, um es als Teil Ihrer Pipeline zu speichern. Die Aufgabe verwendet die Version von Python im Pfad, oder Sie können einen absoluten Pfad zu einem zu verwendenden Python-Interpreter angeben.

Nutzen der verbesserten Xcode-Build- und Testausgabe von xcpretty

xcpretty verbessert die Lesbarkeit der xcodebuild-Ausgabe und generiert Testergebnisse im JUnit-Format. Der Xcode-Build-Task verwendet jetzt automatisch xcpretty, wenn er auf dem Agent-Computer verfügbar ist, da er sich auf gehosteten macOS-Agents befindet. Obwohl die xcpretty-Ausgabe anders und weniger ausführlich als die xcodebuild-Ausgabe sein kann, stellen wir die vollständigen xcodebuild-Protokolle für jeden Build zur Verfügung.

Test Plans

Test Runner -Client (Azure Test Plans), um manuelle Tests für Desktopanwendungen durchzuführen

Sie können jetzt den Test Runner -Client (Azure Test Plans) verwenden, um manuelle Tests für Desktopanwendungen durchzuführen. Dies hilft Ihnen beim Wechsel von Microsoft Test Manager zu Azure Test Plans. Weitere Informationen finden Sie in unserer Anleitung. Mithilfe Test Runner Client können Sie Ihre manuellen Tests ausführen und die Testergebnisse für jeden Testschritt aufzeichnen. Sie verfügen auch über Funktionen zur Datensammlung, z. B. Screenshot, Bildaktionsprotokoll und Audiovideoaufzeichnung. Wenn Sie beim Testen ein Problem feststellen, verwenden Sie Test Runner, um einen Fehler mit Testschritten, Screenshots und Kommentaren zu erstellen, die automatisch im Fehler enthalten sind.

Test Runner (Azure Test Plans) erfordert einen einmaligen Download und eine einmalige Installation des Runners. Wählen Sie Für Desktopanwendung ausführen aus, wie unten gezeigt.

Azure Test Runner

Azure Test Runner installieren

Artifacts

Upstreamquellen

Azure DevOps Server 2019 bietet erhebliche Updates für die Upstreamquellen, die in Ihren Azure Artifacts verfügbar sind:

  • Sie können nuget.org feeds hinzufügen, die in früheren TFS-Releases erstellt wurden. Suchen Sie nach dem Banner über den Feedpaketen, um weitere Informationen zu erhalten, einschließlich Verhaltensänderungen, die Sie vor dem Upgrade beachten sollten.
  • Sie können Ihrem Feed Azure DevOps Server Feeds andere Azure DevOps Server-Feeds hinzufügen. Dies bedeutet, dass Sie NuGet- und npm-Pakete aus diesen Feeds über Ihren Feed verwenden können.

Wir haben auch eine neue Rolle in Azure Artifacts eingeführt: "Projektmitarbeiter". Ein Projektmitarbeiter kann Pakete aus einer Upstreamquelle speichern, pakete jedoch nicht direkt im Feed veröffentlichen (z. B. mithilfe von nuget publish). Auf diese Weise können Sie die Paketveröffentlichung für einen vertrauenswürdigen Benutzer oder das Buildsystem einschränken, während Ihre Techniker neue Pakete aus Ihren Upstreamquellen verwenden können.

Folgen von Paketen

Wir haben es noch einfacher gemacht, Benachrichtigungen mit einer neuen Schaltfläche Folgen direkt in jedem Paket einrichten. Die Schaltfläche Folgen ist auch mit Releaseansichten kompatibel. Wenn Sie einem Paket folgen, während Sie es über eine Ansicht betrachten, erhalten Sie nur Updates für neue Versionen, die in diese Ansicht promotet werden.

Ändern der Feedeinstellungen ohne manuelles Speichern

Einige der Interaktionen auf der Seite mit den Feedeinstellungen wurden verbessert. Änderungen, die Sie vornehmen, z. B. das Hinzufügen eines Upstreams oder einer Berechtigung, werden sofort gespeichert. Dies bedeutet, dass Sie sich keine Gedanken über den Verlust von Änderungen machen müssen, wenn Sie zwischen den Pivots der Einstellungen wechseln.

Vereinfachen der Authentifizierung mithilfe des neuen plattformübergreifenden Credential Provider für NuGet

Die Interaktion mit authentifizierten NuGet feeds wurde deutlich verbessert. Die neue .NET Core-basierte Azure Artifacts Anmeldeinformationsanbieter funktioniert mit msbuild, dotnet und nuget(.exe) unter Windows, macOS und Linux. Jedes Mal, wenn Sie Pakete aus einem Azure Artifacts-Feed verwenden möchten, erhält und Anmeldeinformationsanbieter automatisch ein Token im Namen des NuGet-Clients, den Sie verwenden. Sie müssen ein Token nicht mehr manuell in einer Konfigurationsdatei speichern und verwalten.

Um den neuen Anbieter zu erhalten, besuchen Sie GitHub, und befolgen Sie die Anweisungen für Ihren Client und Ihre Plattform.

Komprimieren von Symbolen beim Veröffentlichen in einer Dateifreigabe

Wir haben den Task Index & Publish Symbols aktualisiert, um das Komprimieren von Symbolen zu unterstützen, wenn sie auf einer Dateifreigabe veröffentlicht werden.

Komprimieren von Symbolen

Wiki

Veröffentlichen von Markdowndateien aus einem Git-Repository als Wiki

Entwickler erstellen dokumentation für "APIs", "SDKs" und "Hilfedokumentation zur Codeerklärung" in Codereposis. Leser müssen dann Code durchsischen, um die richtige Dokumentation zu finden. Jetzt können Sie einfach Markdowndateien aus Coderepos repositorys veröffentlichen und sie im Wiki hosten.

Öffentlicher Code als Wiki-Aktion

Klicken Sie im Wiki zunächst auf Code als Wiki veröffentlichen. Als Nächstes können Sie einen Ordner in einem Git-Repository angeben, der hoch promotet werden soll.

Dialogfeld "Seiten veröffentlichen"

Nachdem Sie auf Veröffentlichen geklickt haben, werden alle Markdowndateien unter dem ausgewählten Ordner als Wiki veröffentlicht. Dadurch wird auch der Head of the Branch dem Wiki zuordnen, sodass alle Änderungen, die Sie am Git-Repository vornehmen, sofort widergespiegelt werden.

Weitere Informationen finden Sie im Blogbeitrag zur Produktdokumentation.

Jetzt können Sie auf das Linksymbol neben einer beliebigen Abschnittsüberschrift auf einer Wiki-Seite klicken, um eine URL direkt zu diesem Abschnitt zu generieren. Sie können diese URL dann kopieren und für Teammitglieder freigeben, um sie direkt mit diesem Abschnitt zu verknüpfen. Dieses Feature hat aufgrund eines Vorschlags Priorität erhalten.

URL der Wiki-Überschrift

Anfügen von Dateien und Bildern in Ordnern

Beim Offlinebearbeitung von Wiki-Seiten kann es einfacher sein, Dateianlagen und Bilder im gleichen Verzeichnis wie die Wiki-Seite hinzuzufügen. Nun können Sie eine Anlage oder ein Bild in einem beliebigen Ordner im Wiki hinzufügen und mit Ihrer Seite verknüpfen. Dieses Feature hat aufgrund eines Vorschlags Priorität erhalten.

Wiki-Bild im Git-Repositoryordner

Einbetten eines Videos in das Wiki

Jetzt können Sie Videos in eine Wiki-Seite einbetten, z. B. Onlinedienste Microsoft Stream youTube. Sie können die eingebettete Video-URL mit der folgenden Syntax hinzufügen:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Einbetten von Videos in das Wiki

Umbenennen eines Wikis

Jetzt können Sie Ihr Wiki auf der Wiki-Benutzeroberfläche umbenennen und REST-APIs verwenden. Klicken Sie im Menü Mehr auf Wiki umbenennen, um Ihrem Wiki einen einprägsamen Namen zu geben.

Wiki umbenennen

Seite auf neuer Registerkarte öffnen

Jetzt können Sie mit der rechten Maustaste auf eine Wiki-Seite klicken und sie auf einer neuen Registerkarte öffnen, oder einfach STRG+linker Klick auf eine Wiki-Seite drücken, um sie auf einer neuen Registerkarte zu öffnen.

Neue Registerkarte "Wiki"

Sonderzeichen in Wiki-Seitentiteln beibehalten

Sie können jetzt Wiki-Seiten mit Sonderzeichen wie : < > * ? | - erstellen. Seiten mit Titeln wie "FAQ?" oder "Einrichtungsleitfaden" kann im Wiki erstellt werden. Die folgenden Zeichen werden in ihre UTF-8-codierten Zeichenfolgen übersetzt:

Zeichen Codierte Zeichenfolge
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

Alle Links in einem Wiki, die nicht ordnungsgemäß verknüpft sind, werden in einer eindeutigen roten Farbe und einem fehlerhaften Linksymbol angezeigt, was Ihnen einen visuellen Hinweis auf alle fehlerhaften Links auf einer Wiki-Seite bietet.

Fehlerhafte Wiki-Links

Fehlerhafte Seitenlinks sind eine der führenden Ursachen für eine schlechte Seitenqualität in jeder Dokumentationslösung. Wenn Sie zuvor im Wiki eine Seite innerhalb der Struktur verschoben oder eine Seite umbenannt haben, konnte dies dazu kommen, dass Links zur Seite von anderen Seiten und Arbeitselementen entfernt wurden. Jetzt können Sie nach Links überprüfen und diese beheben, bevor sie beschädigt werden.

Wichtig

Denken Sie daran, die Markdownsyntax für Links auf Seiten und den []() Wiki-Seitenlinktyp in Arbeitselementen zu verwenden, damit Wiki diese möglicherweise fehlerhaften Links finden und beheben kann. Nur-Text-URLs und Links in Arbeitselementen werden von diesem Feature nicht verwendet.

Wenn Sie eine Seite umbenennen oder verschieben, werden Sie aufgefordert, nach betroffenen absoluten oder relativen Links zu überprüfen.

Dialogfeld "Seite verschieben"

Anschließend wird eine Liste der betroffenen Seitenlinks und Arbeitselemente angezeigt, bevor Sie Maßnahmen ergreifen.

Links zur Seite "Verschieben"

Erstellen eines Inhaltsverzeichnis für Wiki-Seiten

Manchmal können Wiki-Seiten lang werden, und Inhalte sind in mehrere Überschriften organisiert. Nun können Sie jeder Seite, die über mindestens eine Überschrift verfügt, mithilfe der -Syntax ein Inhaltsverzeichnis [[_TOC_]] hinzufügen.

Wiki-Inhaltsverzeichnis

Sie können das Inhaltsverzeichnis auch einfügen, indem Sie beim Bearbeiten der Seite im Formatbereich auf die entsprechende Schaltfläche klicken.

Wiki-ToC einfügen

Weitere Informationen zur Verwendung von Markdown in der Markdownanleitung finden Sie in Azure DevOps.

Surface-Metadaten für Wiki-Seiten und Codevorschau mitHILFE von YAML-Tags

Das Hinzufügen von Metadaten zur Dokumentation kann Lesern und Suchindizes helfen, aussagekräftige Inhalte zu übernehmen und anzuzeigen. In diesem Update wird jede Datei, die einen YAML-Block am Anfang der Datei enthält, in eine Metadatentabelle mit einem Kopf und einer Zeile transformiert. Der YAML-Block muss die Form eines gültigen YAML-Sets zwischen dreifach gestrichelten Zeilen haben. Er unterstützt alle grundlegenden Datentypen list und object as value. Die Syntax wird in der Wiki- und Codedateivorschau unterstützt.

Beispiel für YAML-Tags:

---
tag: post
title: Hello world
---

YAML-Tabelle

Beispiel für YAML-Tags mit Liste:

---
tags:
- post
- code
- web
title: Hello world
---

YAML-Tabelle mit Liste

Veröffentlichen von Code als Wiki mit Mitmingberechtigungen

Zuvor konnten nur Benutzer mit der Berechtigung Repository erstellen in einem Git-Repository Code als Wiki veröffentlichen. Dadurch wurden die Repositoryadministratoren oder -ersteller zu einem Engpass bei Allen Anforderungen, Markdowndateien zu veröffentlichen, die in Git-Repositorys als Wikis gehostet werden. Jetzt können Sie Code als Wiki veröffentlichen, wenn Sie nur über die Berechtigung Beitragen für das Coderepository verfügen.

Berichterstellung

Die Analytics-Marketplace-Erweiterung für die Berichterstellung ist jetzt verfügbar.

Die Analytics Marketplace-Erweiterung ist jetzt für Azure DevOps Server. Analytics ist die Zukunft der Berichterstellung für Azure DevOps Azure DevOps Server. Die Installation der Analytics-Erweiterung bietet erweiterte Widgets,Power BI Integrationund OData-Zugriff.

Weitere Informationen finden Sie unter Was ist Analytics? und in der Roadmap für die Berichterstellung. Analytics befindet sich in Public Preview. Sie enthält derzeit Daten für Boards und automatisierte Testergebnisse über Pipelines. Weitere Informationen finden Sie unter Verfügbare Daten im Analytics-Dienst.

Untersuchen des Buildverlaufs über ein neues Widget für das Builddashboard

Wir haben ein neues und verbessertes Widget für den Buildverlauf, das Sie Ihren Dashboards hinzufügen können. Mit diesem Widget können Sie nun einen Verlauf der Builds aus einem bestimmten Branch auf Ihrem Dashboard anzeigen und für anonyme Besucher in einem öffentlichen Projekt konfigurieren.

Wichtig

Wenn Sie Erkenntnisse zu Ihren XAML-Builds suchen, verwenden Sie weiterhin das ältere Widget, und lesen Sie mehr über die Migration von XAML-Builds zu neuen Builds. Andernfalls wird empfohlen, zum neueren Widget zu wechseln.


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


Seitenanfang