versionshinweise zu Azure DevOps Server 2019

| Entwicklercommunity 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-Bereitstellung finden Sie unter Azure DevOps Server Anforderungen. Um Azure DevOps-Produkte herunterzuladen, besuchen Sie die Seite Azure DevOps Server Downloads.

Das direkte Upgrade auf Azure DevOps Server 2020 wird von Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie auf Azure DevOps Server 2019 aktualisieren. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps lokal.

---

Sicheres Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020

Azure DevOps Server 2020 führt ein neues Aufbewahrungsmodell für Pipelineausführungen (Build) ein, das basierend auf Einstellungen auf Projektebene funktioniert.

Azure DevOps Server 2020 behandelt die Buildaufbewahrung basierend auf Aufbewahrungsrichtlinien auf Pipelineebene unterschiedlich. Bestimmte Richtlinienkonfigurationen führen dazu, dass Pipelineausführungen nach dem Upgrade gelöscht werden. Pipelineausführungen, die manuell aufbewahrt wurden oder von einem Release beibehalten werden, werden nach dem Upgrade nicht mehr gelöscht.

Weitere Informationen zum sicheren Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020 finden Sie in unserem Blogbeitrag.

Azure DevOps Server 2019.0.1 Patch 16 Veröffentlichungsdatum: 14. November 2023

Wir haben einen Patch für Azure DevOps Server 2019 Update 1.2 veröffentlicht, der Korrekturen für Folgendes enthält.

• Die Liste der zulässigen PowerShell-Aufgaben wurde für die Parameterüberprüfung von Argumenten für Shellaufgaben aktivieren erweitert.

Hinweis

Um Korrekturen für diesen Patch zu implementieren, müssen Sie eine Reihe von Schritten ausführen, um Aufgaben manuell zu aktualisieren.

Patches installieren

Wichtig

Wir haben Updates für den Azure Pipelines-Agent mit Patch 15 veröffentlicht, der am 12. September 2023 veröffentlicht wurde. Wenn Sie die Agent-Updates nicht wie in den Versionshinweisen für Patch 15 beschrieben installiert haben, wird empfohlen, diese Updates vor der Installation von Patch 16 zu installieren. Die neue Version des Agents nach der Installation von Patch 15 ist 3.225.0.

Konfigurieren von TFX

1. Führen Sie die Schritte in der Dokumentation zum Hochladen von Aufgaben in die Projektsammlung aus, um sie zu installieren und sich mit tfx-cli anzumelden.

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED034D2E5

1. Laden SieTasks20231103.zipherunter, und extrahieren Sie sie .
2. Ändern Sie das Verzeichnis in die extrahierten Dateien.
3. Führen Sie die folgenden Befehle aus, um die Aufgaben hochzuladen:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Pipelineanforderungen

Um das neue Verhalten zu verwenden, muss eine Variable AZP_75787_ENABLE_NEW_LOGIC = true in Pipelines festgelegt werden, die die betroffenen Aufgaben verwenden.

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 15 Veröffentlichungsdatum: 12. September 2023

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

• CVE-2023-33136: Azure DevOps Server Sicherheitsanfälligkeit bezüglich Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server

Wichtig

Stellen Sie den Patch in einer Testumgebung bereit, und stellen Sie sicher, dass die Pipelines der Umgebung erwartungsgemäß funktionieren, bevor Sie den Fix auf die Produktion anwenden.

Hinweis

Um Korrekturen für diesen Patch zu implementieren, müssen Sie eine Reihe von Schritten ausführen, um den Agent und die Aufgaben manuell zu aktualisieren.

Patches installieren

1. Laden Sie Azure DevOps Server 2019.0.1 Patch 15 herunter, und installieren Sie es.

Aktualisieren des Azure Pipelines-Agents

1. Laden Sie den Agent von: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Verwenden Sie die Schritte in der Dokumentation zu selbstgehosteten Windows-Agents , um den Agent bereitzustellen.  

Hinweis

Die AZP_AGENT_DOWNGRADE_DISABLED muss auf "true" festgelegt werden, um zu verhindern, dass der Agent herabgestuft wird. Unter Windows kann der folgende Befehl in einer Administratoreingabeaufforderung verwendet werden, gefolgt von einem Neustart. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurieren von TFX

1. Führen Sie die Schritte in der Dokumentation zum Hochladen von Aufgaben in die Projektsammlung aus, um sie zu installieren und sich mit tfx-cli anzumelden.

Aktualisieren von Aufgaben mithilfe von TFX

1. Laden SieTasks_20230825.zipherunter, und extrahieren Sie sie .
2. Ändern Sie das Verzeichnis in die extrahierten Dateien.
3. Führen Sie die folgenden Befehle aus, um die Aufgaben hochzuladen:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Pipelineanforderungen

Um das neue Verhalten zu verwenden, muss eine Variable AZP_75787_ENABLE_NEW_LOGIC = true in Pipelines festgelegt werden, die die betroffenen Aufgaben verwenden.

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 14 Veröffentlichungsdatum: 8. August 2022

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

• CVE-2023-36869: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.

Azure DevOps Server 2019.0.1 Patch 13 Veröffentlichungsdatum: 17. Mai 2022

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

• Widerrufen Sie alle persönlichen Zugriffstoken, nachdem das Active Directory-Konto eines Benutzers deaktiviert wurde.

Azure DevOps Server 2019.0.1 Patch 12 Veröffentlichungsdatum: 26. Januar 2022

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

• Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.

Installationsschritte

1. Aktualisieren Sie den Server mit Patch 12.
2. Überprüfen Sie den Registrierungswert unter HKLM:\Software\Elasticsearch\Version. Wenn der Registrierungswert nicht vorhanden ist, fügen Sie einen Zeichenfolgenwert hinzu, und legen Sie die Version auf 5.4.1 fest (Name = Version, Wert = 5.4.1).
3. Führen Sie den Updatebefehl PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update wie in der Readme-Datei angegeben aus. Möglicherweise wird eine Warnung wie die folgende angezeigt: Es kann keine Verbindung mit dem Remoteserver hergestellt werden. Schließen Sie das Fenster nicht, da das Update so lange wiederholt wird, bis es abgeschlossen ist.

Hinweis

Wenn Azure DevOps Server und Elasticsearch auf verschiedenen Computern installiert sind, führen Sie die unten beschriebenen Schritte aus.

1. Aktualisieren Sie den Server mit Patch 12.
2. Überprüfen Sie den Registrierungswert unter HKLM:\Software\Elasticsearch\Version. Wenn der Registrierungswert nicht vorhanden ist, fügen Sie einen Zeichenfolgenwert hinzu, und legen Sie die Version auf 5.4.1 fest (Name = Version, Wert = 5.4.1).
3. Kopieren Sie den Inhalt des Ordners „zip“ unter C:\Program Files\{TFS Version Folder}\Search\zip in den Remotedateiordner von Elasticsearch.
4. Führen Sie Configure-TFSSearch.ps1 -Operation update auf dem Elasticsearch-Servercomputer aus.

SHA-256 Hash: 96C7AF3E3ED67C76451BA28427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Patch 11 Veröffentlichungsdatum: 10. August 2021

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

• Fehler bei der Builddefinitionsbenutzeroberfläche behoben.

Azure DevOps Server 2019.0.1 Patch 10 Veröffentlichungsdatum: 13. April 2021

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

• CVE-2021-27067 : Veröffentlichung von Informationen

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

Installation des AzureResourceGroupDeploymentV2-Tasks

Hinweis

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

Installieren

1. Extrahieren Sie das 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

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

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

6. 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 von Patch 9 2019.0.1: 8. Dezember 2020

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

• CVE-2020-1325: Sicherheitsanfälligkeit in Azure DevOps Server Spoofing
• CVE-2020-17135: Sicherheitsanfälligkeit in 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

Bitte lesen Sie die vollständigen Anweisungen unten, bevor Sie diesen Patch installieren.

Allgemeine Patchinstallation

Wenn Sie über Azure DevOps Server 2019.0.1 verfügen, sollten Sie Azure DevOps Server 2019.0.1 Patch 9 installieren.

Überprüfen der Installation

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

• 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 auf c:\Program Files\Azure DevOps Server 2019 installiert. Nach der Installation von Azure DevOps Server 2019.0.1 Patch 9 lautet die Version 17.143.30723.4 .

AzurePowerShellV4-Aufgabeninstallation

Hinweis

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

Voraussetzungen

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

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

Installieren

1. Extrahieren Sie das AzurePowerShellV4.zip-Paket in einen Ordner namens 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

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

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

6. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Der Pfad des extrahierten Pakets lautet D:\tasks (1)\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server Veröffentlichungsdatum von Patch 8 2019.0.1: 8. September 2020

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

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

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

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

• CVE-2020-1326: Sicherheitsanfälligkeit bei websiteübergreifender Skripterstellung
• Die Buildpipeline zeigt eine falsche Verbindung für nicht autorisierte Benutzer an, wenn Sie Andere Git-Quelle auswählen.
• Fehler beim Ändern der Vererbung in der XAML-Builddefinition in Ein oder Aus behoben.

Azure DevOps Server Veröffentlichungsdatum von Patch 6 2019.0.1: 10. Juni 2020

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

• CVE-2020-1327: Sicherstellen, dass Azure DevOps Server Benutzereingaben bereinigen
• Hinzufügen von Unterstützung für SHA2 in SSH in Azure DevOps

Azure DevOps Server Veröffentlichungsdatum von Patch 5 2019.0.1: 10. März 2020

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

• CVE-2020-0700 : Sicherheitsrisiko durch Cross-Site Scripting
• CVE-2020-0758 : Sicherheitsrisiko durch Rechteerweiterungen
• CVE 2020-0815: Sicherheitsrisiko bei Rechteerweiterungen

Azure DevOps Server Veröffentlichungsdatum von Patch 3 2019.0.1: 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 von Patch 2019.0.1: 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 Informationen zu Dienstverbindungen hinzugefügt, um zu verdeutlichen, dass sie standardmäßig für alle Pipelines autorisiert sind.

---

Azure DevOps Server Veröffentlichungsdatum von Patch 1 2019.0.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 höher durchführen.

Hinweis

Das Datenmigrationstool ist etwa drei Wochen nach dieser Version für Azure DevOps Server 2019.0.1 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 über Entwicklercommunity gemeldet.
• apiwitcontroller.executequery löst eine Ausnahme aus, wenn eine Abfrage mehrmals dieselbe Spalte aufweist.
• Im Clientobjektmodell, das den bereich vso.work_full oauth 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 fehlerhaften Bild führen.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• Die Registerkarte "Testanalyse" verfügt über einen star (*), der die Vorschau angibt, obwohl sich dieses Feature nicht in der Vorschau befindet.
• Auf der Registerkarte Releases wird die Aktion zum Verwalten der Sicherheit nun allen Benutzern angezeigt, unabhängig davon, ob sie die Berechtigungen ändern können oder nicht.
• Auf den Startseiten der Releases wurde durch die Startentwurfsaktion ein neues Release erstellt, aber 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 in MTM oder in einem Browser nicht angezeigt.
• Fehler "Validierungsphase: Sie verfügen nicht über die Berechtigung zum Auslösen von Releases in der zugeordneten Releasepipeline", wenn automatisierte Tests aus einem Testplan ausgeführt werden. Wird über Entwicklercommunity gemeldet.
• Mithilfe der Api zum Löschen von Testfällen können Testfälle aus anderen Projekten gelöscht werden. Wird über Entwicklercommunity gemeldet.
• Wenn Sie in Test Runner auf einen Arbeitselementlink klicken, wird die Arbeitselement-URL in Test Runner anstelle des Standardbrowsers geöffnet.
• Der Testfall status wird für Benutzer, die sich von Test Runner abmelden, nicht aktualisiert.
• Benutzername und E-Mail-Adresse werden in test Runner nicht in der Dropdownliste "Benutzer" angezeigt.

Azure Artifacts

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

Analyse

• Analyseberichte können unvollständige Daten anzeigen, da das Modell als "bereit" gekennzeichnet ist, bevor es tatsächlich abgeschlossen ist.
• Die Geschwindigkeits-, Burndown- und Burnupwidgets zeigen unterschiedliche geplante Arbeit für Benutzer in verschiedenen Zeitzonen an.
• Bei der Wartung kann ein Haltepunkt für die Analysedatenerfassung platziert werden, was zu veralteten Berichten führen kann.

Allgemein

• Linke Navigationselemente werden in IE gedrückt, wenn nicht genügend Platz vorhanden ist.

Verwaltung

• Zusätzliche Protokollierung zum Sammlungsupgrade hinzugefügt, um Probleme zu debuggen.
• Wenn TfsConfig offlineDetach fehlschlägt, kann die Fehlermeldung nicht ausgeführt werden.
• TfsJobAgent-Dienst stürzt ab.
• Die Sucherweiterung wird nach Abschluss der Konfiguration nicht installiert.
• Die Verwaltungskonsole reagiert nicht mehr, wenn die Konfigurationsdatenbank beschädigt ist.
• Service Hooks verarbeiten Benachrichtigungen möglicherweise nicht ordnungsgemäß.
• Die Codesuche-Indizierung wird nach dem Konfigurieren der Suche nicht gestartet.
• Es gibt nicht zugeordnete Zeichenfolgen in Suchergebnissen.

Dieses Release enthält das folgende Update:

Unterstützung für Visual Studio 2019 (VS2019) im Visual Studio-Testtask

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

---

Azure DevOps Server Veröffentlichungsdatum von Patch 2019: 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: Sicherheitsanfälligkeit durch HTML-Einschleusung 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 bei cross site scripting (XSS) in Pipelines
• CVE-2019-0875: Sicherheitsrisiko bei Rechteerweiterungen in Boards

---

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

Hinweis

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

---

RC2-Veröffentlichungsdatum: 22. Januar 2019

Zusammenfassung der Neuerungen in Azure DevOps Server 2019 RC2

Wir haben RC2 die folgenden Features hinzugefügt:

• Verknüpfen von GitHub Enterprise-Commits und Pull Requests mit Azure Boards Arbeitselementen
• Konfigurieren von Builds mithilfe von YAML
• Kartenanmerkungen enthalten Fehler und benutzerdefinierte Arbeitselementtypen.
• Verbesserte Branchauswahl
• Änderungen an der Lizenzierung der Artefakt- und Release Management-Bereitstellungspipeline

---

RC1-Veröffentlichungsdatum: 19. November 2018

Zusammenfassung der Neuerungen in Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 wird eine neue Navigationsoberfläche und viele neue Features eingeführt. Einige der Highlights sind unter anderem:

• Neue Navigationsoberfläche
• Die Analytics Marketplace-Erweiterung für die Berichterstellung ist jetzt verfügbar.
• Unterstützung für Azure SQL-Datenbank
• Verarbeiten der Vererbung für neue Sammlungen
• Hub für neue Arbeitselemente
• Neue Boards, Backlogs und Sprints-Hubs
• Neuer Abfragehub
• Standardisieren von Pull Request-Beschreibungen mithilfe von Vorlagen
• Ändern des Zielbranchs eines Pull Requests
• Verwalten von Buildpipelines mithilfe der neuen Seite "Builds"
• Verwalten von Releasepipelines mithilfe der neuen Releaseseite
• Visualisieren des Releasefortschritts
• Lokales Aktualisieren Ihres Agents
• Schrittweises Verfügbarmachen und Phasenbereitstellungen mithilfe von Releasegates
• Upstreamquellen
• Erstellen eines Inhaltsverzeichnisses für Wiki-Seiten

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

• Allgemein
• Boards
• Repos
• Pipelines
• Test Plans
• Artefakte
• Wiki
• Berichterstellung

---

Allgemein

Ankündigung Azure DevOps Server

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

Neue Navigationsoberfläche

Wir führen eine neue Navigation ein, um die Benutzererfahrung zu modernisieren. Diese neue Navigation wurde für den Azure DevOps-Dienst eingeführt und ist jetzt in Azure DevOps Server 2019 verfügbar. Weitere Informationen finden Sie in unserem Blog .

Änderungen an der Lizenzierung der Artefakt- und Release Management-Bereitstellungspipeline

Basierend auf Benutzerfeedback nehmen wir mit Azure DevOps Server 2019 zwei wichtige Änderungen an unseren Lizenzen vor. Erstens müssen Kunden die Artifact-Erweiterung nicht mehr erwerben, um Artifacts verwenden zu können. Die Verwendung einer Artifacts-Lizenz ist jetzt in der Basislizenz enthalten. Alle Benutzer, denen eine Basislizenz zugewiesen ist, können jetzt Artefakte verwenden. Zweitens müssen Kunden keine Release Management Bereitstellungspipelines mehr erwerben. Genau wie Buildpipelines sind Release Management Bereitstellungspipelines 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 Database (Universell S3 und höher) aktiviert. Auf diese Weise können Sie umfangreiche Sicherungsfeatures und Skalierungsoptionen nutzen, die Ihren Anforderungen entsprechen, und gleichzeitig den Verwaltungsaufwand für die Ausführung des Diensts reduzieren. Beachten Sie, dass sich Ihre Host-VM in derselben Azure-Region wie Ihre Datenbank befinden muss, um die Latenz niedrig zu halten. Weitere Informationen finden Sie in der Dokumentation .

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

Azure DevOps Server 2019 unterstützt weiterhin die SOAP-API für die Arbeitselementnachverfolgung und das Clientobjektmodell. Es wird jedoch in zukünftigen Versionen von Azure DevOps Server als veraltet markiert. 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 Gewissensentscheidung über das Prozessmodell treffen. In unserer Dokumentation erfahren Sie, was das Vererbungsmodell ist und wie es sich von XML unterscheidet.

Erweitertes Suchfeld

Wir verstehen die Bedeutung der Suche und stellen das erweiterte Suchfeld im Produktheader wieder her. Darüber hinaus können Sie das Suchfeld jetzt aufrufen, indem Sie einfach auf einer beliebigen Dienstseite in Azure DevOps auf "/" klicken.

Hier sehen Sie das Standardsuchfeld:

Nachdem Sie ein "/" eingegeben haben, wird das erweiterte Suchfeld angezeigt:

Flyout "Meine Arbeit"

Ein neues Feature, das wir sehr freuen, ist das Flyout "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 benötigen. Mit diesem neuen Feature können Sie von überall im Produkt auf dieses Flyout zugreifen, und es bietet Ihnen einen schnellen Überblick über wichtige Informationen, einschließlich Ihrer Arbeitselemente, Pull Requests und aller Favoriten. Mit diesem neuen Flyout können Sie einfach auf das Flyout klicken, die Ihnen zugewiesenen Arbeitselemente anzeigen und das nächste Element auswählen.

Unten sehen Sie das Flyout "Meine Arbeit " mit den mir zugewiesenen Arbeitselementen:

Hier sehen Sie den zweiten Pivot, der die mir zugewiesenen PRs anzeigt. Im Flyout haben Sie auch einen Klickzugriff, um weitere Pull Requests anzuzeigen:

Hier sehen Sie den letzten Pivot, bei dem es sich um alles handelt, was Sie als Favoriten ausgewählt haben. Dies umfasst Ihre bevorzugten Teams, Dashboards, Boards, Backlogs, Abfragen und Repositorys:

Boards

Verknüpfen von GitHub Enterprise-Commits und Pull Requests mit Azure Boards Arbeitselementen

Teams, die GitHub Enterprise für Code verwenden und umfassende Projektverwaltungsfunktionen benötigen, können jetzt ihre Repositorys in Azure Boards integrieren. Durch das Verbinden von GitHub und Azure Boards können Sie alle Features wie Backlogs, Boards, Sprintplanungstools, mehrere Arbeitselementtypen und weiterhin über einen Workflow verfügen, der in Entwicklerworkflows in GitHub integriert ist.

Das Verknüpfen von Commits und Pull Requests mit Arbeitselementen ist einfach. Erwähnen Sie das Arbeitselement mit 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. ​

Wenn die Wörter "fix", "fixes" oder "fixed" dem Arbeitselement Erwähnung vorangestellt sind (wie oben gezeigt), wird das Arbeitselement in den Status Abgeschlossen verschoben, wenn der Commit mit dem Standardbranch zusammengeführt wird.

Teams, die Azure Pipelines zum Erstellen von Code in GitHub verwenden, sehen auch die mit ihren GitHub-Commits verknüpften Arbeitselemente in der Buildzusammenfassung.

Hub für neue Arbeitselemente

Der Hub für Arbeitselemente ist unser neuer Hub, der als Zuhause Für Ihre Arbeitselemente dient! Hier verfügen Sie über viele verschiedene Listenansichten Ihrer Arbeitselemente, die für Sie abgegrenzt sind. Sie können mir zugewiesen anzeigen, um schnell einen Blick auf alle Ihnen zugewiesenen Arbeit zu erhalten, oder Zuletzt aktualisiert , in der alle Arbeitselemente in Ihrem Projekt angezeigt werden, die zuletzt aktualisiert wurden. Alle Ihre Listenoptionen finden Sie unten:

Wenn Sie ihre Listen noch weiter nach unten ausweiten möchten, können Sie nach Typ, Zugewiesenem, Status, Bereich, Tags und Schlüsselwort (keyword) filtern. Sobald Sie ihre 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 Kopfzeilenbereich ganz einfach ändern. Diese Erfahrungen sind unten zu sehen:

Neue Boards, Backlogs und Sprints-Hubs

Der Backlogs-Hub wurde in drei verschiedene Hubs aufgeteilt, um die Benutzererfahrung zu verbessern. Obwohl der alte Backlogs-Hub sehr leistungsfähig war, gab es zu viele Funktionen. Dies machte es oft schwierig, das Feature oder die Funktion zu finden, nach der benutzer gesucht haben. Um dieses Problem zu beheben, haben wir den Backlogs-Hub unterteilt in:

• Der Backlogs-Hub enthält jetzt nur noch die Backlogs für ein Projekt. Ein Backlog ist eine priorisierte Liste der Arbeit für das Team. Backlogs bieten Planungstools wie Arbeitselementhierarchie, Vorhersage und neue Sprintplanungsfunktionen.
• Der neue Boards-Hub beherbergt alle Kanban-Boards für ein Projekt. Boards werden verwendet, um status und Flow zu kommunizieren. Karten (Arbeitselemente) werden von links nach rechts durch spaltenweise verschoben, die vom Team definiert werden.
• Der neue Sprints-Hub enthält Features, die zum Planen und Ausführen eines Inkrements der Arbeit verwendet werden. Jeder Sprint enthält ein Sprintbacklog, ein Taskboard und eine Ansicht zum Verwalten und Festlegen der Kapazität für das Team.

Neuer Abfragehub

Der neue Abfragehub optimiert viele der vorhandenen Abfragefeatures des alten Hubs mit einem moderneren Erscheinungsbild und bietet neue Funktionen, um den Zugriff auf die für Sie wichtigen Abfragen zu vereinfachen. Zu den Highlights der neuen Benutzeroberfläche gehören:

• Verzeichnisseiten mit zuletzt geänderten Informationen und der Möglichkeit, nach Abfragen zu suchen
• Breadcrumb mit eindeutigen URLs für Ordner zum Lesezeichen für wichtige Gruppen von Abfragen
• Schneller Zugriff auf Ihre bevorzugten Abfragen über die Ergebnisseite

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

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

Sie können jetzt 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, verwenden Sie den Analytics-Dienst, um Ihre Berichterstellungsanforderungen zu unterstützen. Weitere Informationen zum Deaktivieren des Data Warehouse finden Sie unter Deaktivieren des Data Warehouse und des 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 .
• Verwenden Sie den neuen Planungsbereich in Ihrem Backlog, um Arbeitselemente in zukünftige Sprints zu ziehen und abzuwerfen. Der Bereich Planung enthält Sprinttermine, Anzahl von Arbeitselementen und geplanten Aufwand.
• Fügen Sie anforderungen am anfang des Taskboards hinzu, oder verwenden Sie die Schnellerstellung, um in Ihrem Sprintbacklog oben, unten oder zeile ihrer Wahl hinzuzufügen.
• Verwenden Sie Filter für Zugewiesene, Arbeitselementtyp, Status und Tags, um die Ansichten an Ihre Anforderungen anzupassen.

Neue Verzeichnisseiten

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

• Fahren Sie dort fort, wo Sie aufgehört haben Dieser neue Abschnitt bietet Ihnen einen Schnellen Link direkt zum letzten (Board | Backlog | Sprint) war aktiviert.
• Favoriten Alle Ihre Lieblingsboards, Sprints und Backlogs in allen Teams.
• Meine Alle Boards, Backlogs und Sprints für Teams, zu der Sie gehören.
• Alle Eine vollständige Liste aller Boards, Backlogs und Sprints.

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. das Anzeigen von Hierarchien in Backlogs oder das Ändern der Option Gruppieren nach auf einem Taskboard, um den Seitenbereich für zuordnungs- und planungssprints zu aktivieren oder Arbeitsdetaildiagramme zu untersuchen.

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

Kartenanmerkungen enthalten Fehler und benutzerdefinierte Arbeitselementtypen.

Kartenanmerkungen werden wegen ihrer intuitiven Ansicht und Interaktion von Prüflisten geliebt. Bisher waren Karte Anmerkungen auf Standardmäßige Backlogebenentypen beschränkt und unterstützten keine Fehler oder benutzerdefinierte Typen. Mit der neuen Version haben wir die Einschränkung für Arbeitselementtypen entfernt und die Möglichkeit hinzugefügt, Fehler und jeden benutzerdefinierten Arbeitselementtyp als Karte Anmerkung anzuzeigen.

Boardeinstellungen für Karte Anmerkungen wurden erweitert, um alle Arbeitselementtypen einzuschließen, die für diese Backlogebene verfügbar sind.

Wenn Anmerkungen für Arbeitselemente aktiviert sind, wird die Anzahl für diesen Arbeitselementtyp im Karte als separate Prüfliste enthalten.

Die schnelle Erstellung aktivierter Arbeitselementtypen ist auch über Karte Kontextmenü verfügbar.

Verschieben von Arbeiten mithilfe vorgeschlagener Bereiche und Iterationen

Es kann üblich sein, im selben Bereich oder in derselben Iteration zu arbeiten und beim Verschieben von Arbeitselementen wiederholt durch die Hierarchien zu navigieren. Die Steuerelemente "Bereich" und "Iterationspfad " enthalten jetzt eine Liste der zuletzt verwendeten Werte als Vorschläge, sodass Sie schnell auf festlegen und fortfahren können.

Darüber hinaus werden Iterationsdaten rechts neben dem Namen eingeschlossen, sodass Sie schnell beurteilen können, wann ein Arbeitselement geliefert werden soll.

Abfragen der Arbeit im gesamten Iterationszeitplan mit +/- @CurrentIteration

Das @CurrentIteration Makro, mit dem Ihr Team die Arbeit basierend auf Ihrem Iterationszeitplan nachverfolgen kann, unterstützt jetzt den Ganzzahloffset. Behalten Sie einfach die Arbeit im Blick, die nicht mit @CurrentIteration - 1 geschlossen wurde, oder sehen Sie sich die arbeit an, die für zukünftige Iterationen mit @CurrentIteration + 1 geplant ist. Weitere Informationen finden Sie im @CurrentIteration-Beitrag im Microsoft DevOps-Blog.

Klären der Abfrageiterationszeitpläne mit dem @CurrentIteration Team-Parameter

Wenn Sie das @CurrentIteration Makro in der Vergangenheit in Abfragen verwendet haben, haben Sie möglicherweise bemerkt, dass die Ergebnisse variieren können, wenn sich der Teamkontext in Teams mit unterschiedlichen Iterationszeitplänen ändert. Wenn Sie nun eine Abfrage mit dem @CurrentIteration Makro erstellen oder ä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 verwenden, aber teamsübergreifend. Ein Beispiel kann eine Abfrage für Arbeitselemente in zwei verschiedenen Teamprojekten sein, die unterschiedliche Iterationsnamen und sogar Zeitpläne verwenden. 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.

Abfragearbeit 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, wodurch Sie Backlogs, Boards, Pläne und 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 ist ein neues @TeamAreas Makro verfügbar, mit dem Sie problemlos auf die Bereichspfade im Besitz des angegebenen Teams verweisen können.

Abfrage für leere Rich-Text-Felder

Suchen Sie Arbeitselemente mit einem leeren Rich-Text-Feld, z. B. Beschreibung, mithilfe des neuen IsEmpty-Abfrageoperators .

Einfaches Auffinden vorhandener Arbeitselemente in Verknüpfungen und Erwähnung Erfahrungen

Wenn Sie zwei vorhandene Arbeitselemente miteinander verknüpfen möchten, können Sie das für Sie wichtige Element jetzt ganz einfach mithilfe unseres neuen Arbeitselements-Suchsteuerelements finden. Die Abfrageauswahl wurde durch Inlinevorschläge ersetzt, die auf Ihren zuletzt verwendeten Arbeitselementen basieren, sowie durch einen Einstiegspunkt zum Suchen nach einem bestimmten Arbeitselement nach ID oder Titel.

Öffnen von Arbeitselementen aus der Suche

Bisher konnte ein Arbeitselement nicht über die Suchergebnisseite geöffnet werden, wenn der Vorschaubereich des Arbeitselements deaktiviert war. Dies würde es schwierig machen, ihre Suchergebnisse zu untersuchen. Jetzt können Sie auf den Titel des Arbeitselements klicken, um die Arbeitselemente in einem modalem Fenster zu öffnen.

Repos

Verbesserte Branchauswahl

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

Empfangen von Benachrichtigungen, wenn Pull Request-Richtlinien umgangen werden

Für Teams, die Pull Requests (PRs) und Branchrichtlinien verwenden, kann es Vorkommen geben, in denen Benutzer diese Richtlinien außer Kraft setzen und umgehen müssen, z. B. bei der Bereitstellung eines Hotfixes für ein Produktionsproblem mitten in der Nacht. Es ist sinnvoll, Entwicklern zu vertrauen, dass sie das Richtige tun und die Überschreibungsfunktion sparsam nutzen. 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, mit dem Benutzer und Teams jederzeit E-Mail-Warnungen empfangen können, wenn eine Richtlinie umgangen wird. 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. Sie werden jedes Mal benachrichtigt, wenn ein PR abgeschlossen ist, und Richtlinien werden umgangen.

Umgehung von Branchrichtlinien zulassen, ohne den Pushschutz aufzugeben

Es gibt viele Szenarien, in denen Sie gelegentlich eine Branchrichtlinie umgehen müssen: Rückgängigmachen einer Änderung, die eine Buildunterbrechung verursacht hat, Anwenden eines Hotfixes mitten in der Nacht usw. Zuvor haben wir eine Berechtigung ("Ausgenommen von der Richtlinienerzwingung") angeboten, um Teams bei der Verwaltung zu helfen, welche Benutzer beim Abschließen eines Pull Requests die Möglichkeit erhalten haben, Branchrichtlinien zu umgehen. Diese Berechtigung gewährte jedoch auch die Möglichkeit, direkt in 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. Richtlinien beim Abschließen von Pull Requests umgehen. Benutzer mit dieser Berechtigung können die „Außerkraftsetzen“-Erfahrung für Pull Requests verwenden.
2. Richtlinien bei Pushvorgängen umgehen. Benutzer mit dieser Berechtigung können direkt an Branches pushen, für die die erforderlichen Richtlinien konfiguriert sind.

Wenn sie die erste Berechtigung erteilen und die zweite verweigern, kann ein Benutzer bei Bedarf die Umgehungsoption verwenden, hat jedoch weiterhin den Schutz vor versehentlichem Pushen in einen Branch mit Richtlinien.

Hinweis

Durch diese Änderung werden keine Verhaltensänderungen eingeführt. Benutzern, denen zuvor die Berechtigung "Ausnahme von Richtlinienerzwingung" gewährt wurde, wird für beide neuen Berechtigungen Zulassen gewährt, sodass sie sowohl die Vervollständigung auf PRs überschreiben als auch direkt mit Richtlinien an Branches pushen können.

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

Schnelles Beschreiben von Pull Requests mithilfe von Commitnachrichten

Das Schreiben von beschreibenden Commitnachrichten fügt dem Verlauf jedes Git-Repositorys einen Mehrwert hinzu. Um Qualitativ hochwertige Commitnachrichten zu fördern, müssen neue Pull Requests (PR) mit mehreren Commits von Mitwirkenden einen Titel manuell eingeben.

Pull Request-Beschreibungen sind weiterhin standardmäßig leer, aber ein neues Feature erleichtert es, die Commitnachrichten aus den PR-Commits in die PR-Beschreibung zu integrieren. 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 ein Standardteam als Prüfer

Als wir die Pull Request-Benutzeroberfläche (PR) zum ersten Mal gestartet haben, dachten wir, 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 bemerkten.

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

1. Beim Erstellen eines PR werden standardmäßig keine Prüfer hinzugefügt. Die Liste der Prüfer verfügt über ein Feature, das das Hinzufügen von Personen und Gruppen erleichtert, die kürzlich zu PRs hinzugefügt wurden. Die erforderliche Prüferrichtlinie 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. Standardmäßig wird in diesem Abschnitt die PRs "Meinen Teams zugewiesen" angezeigt, sodass gleichwertige Funktionen wie der alte Abschnitt bereitgestellt werden. 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 der Abschnittsüberschrift 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, um Reviewern zu vermitteln, was sie beim Code Review erwarten können. PR-Beschreibungen sind auch eine hervorragende Möglichkeit, um Dinge nachzuverfolgen, die für jede Änderung durchgeführt werden sollten, z. B. Testen, Hinzufügen von Komponententests und Aktualisieren der Dokumentation. Viele von Ihnen haben angefordert, dass wir Pull Request-Vorlagen hinzufügen, um Teams das Schreiben großartiger Beschreibungen zu erleichtern, und wir haben dieses Feature jetzt hinzugefügt.

Zusätzlich zur Unterstützung einer standardmäßigen 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 aus einer beliebigen Vorlage im Repository auszuwählen, um sie an die PR-Beschreibung anzufügen.

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 beispielsweise eine Vorlage speziell für alle Branches verwenden möchten, die mit "hotfix/" beginnen, können Sie eine Vorlage hinzufügen, die für alle PRs verwendet wird.

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

Ändern des Zielbranchs eines Pull Requests

Für die meisten Teams zielen fast alle Pull Requests auf denselben Branch ab, z main . B. oder develop. Wenn Sie jedoch einen anderen Branch als Ziel verwenden müssen, können Sie leicht vergessen, den Zielbranch vom Standard zu ändern. Mit dem neuen Feature zum Ändern des Zielbranchs eines aktiven Pull Requests ist dies jetzt eine einfache Aktion. Klicken Sie einfach auf das Stiftsymbol in der Nähe des Zielbranchnamens im Pull Request-Header.

Das Feature zum Ändern von Zielverzweigungen erleichtert neben der bloßen Korrektur von Fehlern auch die "Neuzuweisung" eines Pull Requests, wenn der Zielbranch zusammengeführt oder gelöscht wurde. Stellen Sie sich ein Szenario vor, in dem Sie über einen PR für eine Featurebranch verfügen, die einige Features enthält, von denen Ihre Änderungen abhängig sind. Sie möchten Ihre abhängigen Änderungen isoliert von anderen Änderungen im Featurebranch überprüfen, sodass Sie zunächst als Ziel features/new-featureverwenden. Prüfer können dann nur Ihre Änderungen sehen und die entsprechenden Kommentare hinterlassen.

Überlegen Sie nun, was passiert, wenn die Featurebranch auch einen PR aktiv hätte und vor Ihren Änderungen in main zusammengeführt wurde? Zuvor mussten Sie Ihre Änderungen aufgeben und einen neuen PR in mainerstellen, oder Ihren PR in features/new-featurezusammenführen und dann einen weiteren PR von in features/new-featuremainerstellen. Mit dieser neuen Aktion zum Aktualisieren des Zielbranchs können Sie einfach den Zielbranch des PR von in features/new-featuremainändern, wobei der gesamte Kontext und die Kommentare beibehalten werden. Wenn Sie den Zielbranch ändern, wird sogar ein neues Update für den PR erstellt, was es einfach macht, auf frühere Unterschiede zurückzublicken, bevor sich der Zielbranch ändert.

Erweiterungsautoren können den 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 den VersionControlRepositoryService als erweiterungszugängigen Dienst hinzugefügt. Dadurch kann ein Erweiterungsautor Informationen zum aktuellen Git-Repositorykontext auf der Web-Benutzeroberfläche abfragen. Es 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 wird oder auf den Dienst außerhalb der Azure Repos Seiten zugegriffen wird, wird NULL zurückgegeben.

Hier sehen Sie eine Beispielerweiterung , die diesen Dienst verwendet.

Pipelines

Verwalten von Buildpipelines mithilfe der neuen Seite "Builds"

Wir nehmen mehrere Verbesserungen vor und führen eine neue Version der Buildseite aus. 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. Es enthält auch eine Vorschau der Testanalysen für die ausgewählte Pipeline.

Bessere Verwaltung von Build- und Bereitstellungsabschluss-E-Mails mithilfe einer verbesserten Formatierung

E-Mails zum Abschluss von Build und Bereitstellung wurden aktualisiert, um nach E-Mail-Regeln besser zu filtern. Jetzt enthält die Betreffzeile auf einen Blick relevantere Informationen, der Textkörper 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 allen Builds und Releases wurden in der Vergangenheit unterschiedliche Begriffe für ähnliche Konzepte verwendet. In anderen Fällen waren die Bedeutungen von Begriffen vage. Beispiel: Angeben des Unterschieds zwischen einem Agentpool und einer Agent-Warteschlange.

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

Vorheriger Begriff	Einheitlicher Begriff	Bedeutung
Gehosteter Agent	Von Microsoft gehosteter Agent	Ein Build-/Release-Agent, der in einer in der Cloud gehosteten Infrastruktur ausgeführt wird, die von Microsoft verwaltet wird.
Privater Agent	Selbstgehosteter Agent	Ein Build-/Release-Agent, der auf einem von Ihnen bereitgestellten und verwalteten Computer ausgeführt wird.
Agentpool	Agentpool	Ein organization Satz von Agent-Computern, auf denen Builds oder Releases ausgeführt werden können.
Agent-Warteschlange	Agentpool	Eine Gruppe von Agent-Computern auf Projektebene, die Builds oder Releases ausführen können. Sie ist mit einem Agentpool auf organization-Ebene verknüpft.
Builddefinition	Buildpipeline	Ein End-to-End-Satz von Buildschritten für eine Anwendung.
Entwickeln	Entwickeln	Ein instance 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 aus mehreren Aufträgen enthalten.
Releasedefinition	Releasepipeline	Ein End-to-End-Satz von Releaseschritten für eine Anwendung, die über verschiedene Phasen hinweg bereitgestellt werden soll.
Freigabe	Freigabe	Ein instance einer Releasepipeline, die ausgeführt wird oder ausgeführt wurde.
Environment	Phase	Eine logische und unabhängige Entität, die angibt, wo Sie ein Release bereitstellen möchten, das aus einer Releasepipeline generiert wurde.
Gleichzeitiger Auftrag/gleichzeitige Pipeline	Paralleler Auftrag	Mit einem parallelen Auftrag können Sie jeweils einen einzelnen Build- oder Releaseauftrag in Ihrem organization 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 verwendet werden, um eine Verbindung mit externen Diensten herzustellen, um Aufgaben in einem Build oder Release auszuführen.

Weitere Informationen finden Sie in der Dokumentation zu Konzepten .

Verwalten von Releasepipelines mithilfe der neuen Releaseseite

Eine neue und vollständig überarbeitete Benutzeroberfläche steht für die Release-Landing Page zur Verfügung. Eine Liste der Releasepipelines, die Sie häufig veröffentlichen, finden Sie auf der linken Seite. Sie können auch Ihre Pipelines durchsuchen und als Favoriten auswählen.

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

Visualisieren des Releasefortschritts

Die neue Statusansicht des Release bietet Ihnen Liveupdates des Bereitstellungsfortschritts und 1-Klick-Zugriff auf weitere Details. Die neue Ansicht visualisiert die Releasepipeline, sodass sie leichter zu verstehen ist, was passiert, und es werden entsprechende Details und Aktionen in den verschiedenen Phasen des Release angezeigt.

Pipeline, Releasedetails und Umgebungen

In der Pipelineansicht 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 ihre status sowie detaillierte Fortschritte besser verstehen. Sie können jederzeit zu den Protokollen gelangen, indem Sie in der Umgebung auf den Link status klicken.

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 durch das Vorhandensein von Genehmigungen und Gates angezeigt. Der Fortschritt von Genehmigungen und Gates zeigt sich auch im Status der Umgebung. Sie können Maßnahmen ergreifen oder weitere Details anzeigen, indem Sie auf das Bedingungssymbol der Umgebung klicken, das auf der rechten oder linken Seite der Umgebung hängt.

Commits und Arbeitselemente

Mit jedem neuen Release können Sie die Liste der zugehörigen 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 von Interesse zu finden.

Bereitstellungsstatus und -protokolle

Die Umgebungen zeigen Liveupdates für aktuell ausgeführte Bereitstellungen an, einschließlich der Anzahl der abgeschlossenen Phasen und Tasks und der Ausführungsdauer. Durch Klicken auf den Umgebungsstatus wird eine Ansicht mit den Protokollen geöffnet, wobei der Schwerpunkt auf dem aktuell aktiven Vorgang liegt.

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

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

Computergruppen unter Test Hub wurden in TFS 2017 RTM als veraltet gekennzeichnet . Mit Azure DevOps Server 2019 ist der Computergruppendienst nicht mehr verfügbar. Dies wirkt sich auf die Benutzer der Taskversion 1.* und der Aufgabe "PowerShell auf Zielcomputern", Version 1.*, aus. Damit Ihre Pipelines weiterhin funktionieren,

• Sie müssen zur Aufgabe "Windows Machine File Copy", Version 2.* wechseln und den vollständigen Fqdn für den Zielcomputer anstelle des Computernamens angeben.
• Wechseln Sie zum Task "PowerShell auf Zielcomputer", Version 2.* oder höher, und geben Sie den vollständigen Fqdn des Computer- 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 geöffnet, die Testdetails enthält, einschließlich der Ergebnisse anderer Erweiterungen, die zum Prozess beitragen.

Vorhandene Erweiterungen funktionieren in dieser neuen Ansicht, und es gibt neue Erweiterbarkeitspunkte, damit Erweiterungen entwickelt werden, um noch mehr Informationen für eine Umgebung anzuzeigen. Weitere Informationen finden Sie in der Dokumentation zu Beiträge und Erweiterungen.

Konfigurieren von Builds mithilfe von YAML

YAML-basierte Buildpipelines sind in Ihrem Azure DevOps Server verfügbar. Automatisieren Sie Ihre Continuous Integration-Pipeline mithilfe einer YAML-Datei, die in Ihr Repository eingecheckt wird. Eine vollständige Referenz zum YAML-Schema finden Sie hier.

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

Verketten verwandter Builds mithilfe von Buildabschlusstriggern

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 Upstream Komponente (z. B. eine Bibliothek) ändert, müssen die Downstreamabhängigkeiten neu erstellt und überprüft werden. Teams verwalten diese Abhängigkeiten in der Regel manuell.

Jetzt können Sie einen Build nach erfolgreichem Abschluss eines anderen Builds auslösen. Artefakte, die von einem Upstream Build erstellt werden, können heruntergeladen und im späteren Build verwendet werden, und Sie können auch Daten aus den folgenden Variablen abrufen: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Weitere Informationen finden Sie in der Dokumentation zu Buildtriggern .

Beachten Sie, 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 für den abhängigen Prozess umfassen.

Lokales Aktualisieren Ihres Agents

Für Aufgaben, die Sie aus dem Katalog installieren, ist manchmal eine neuere Version des Pipelines-Agents erforderlich. Wenn Ihr Azure DevOps Server eine Verbindung mit dem Internet herstellen kann, werden neuere Versionen automatisch heruntergeladen. Andernfalls müssen Sie jeden Agent manuell aktualisieren. Ab dieser Version können Sie Ihren Azure DevOps Server so konfigurieren, dass die Agent-Paketdateien auf dem lokalen Datenträger und nicht über das Internet gesucht werden. Dadurch erhalten Sie sowohl Flexibilität als auch Kontrolle darüber, welche Agent-Versionen Sie zur Verfügung stellen, ohne Ihre Azure DevOps Server im Internet verfügbar machen zu müssen.

Neue Build-status-Badge-URL

Build-Badges, die in die Startseite eines Repositorys eingebettet sind, sind eine gängige Methode, um die Integrität des Repositorys anzuzeigen. Obwohl wir bis jetzt Buildabzeichen 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 das Signal zu klicken, um den Benutzer zum neuesten Build dieser Definition zu bringen.

Wir führen nun eine neue API für Build-Badges ein, die diese Probleme löst. Die neue API ermöglicht Es Benutzern, eine status pro Branch zu veröffentlichen und Benutzer zum neuesten Build des ausgewählten Branchs zu bringen. Sie können den Markdown für die neue status Badge-URL abrufen, indem Sie auf der neuen Seite Builds die Menüaktion Status-Badge auswählen.

Aus Gründen der Abwärtskompatibilität werden wir auch weiterhin die älteren Build-Badge-URLs berücksichtigen.

Hinzufügen benutzerdefinierter Buildindikatoren zu Ihren Builds

Buildindikatoren bieten eine Möglichkeit, Builds eindeutig zu nummerieren und zu bezeichnen. Zuvor konnten Sie dazu die spezielle Variable $(rev:r) verwenden. Jetzt können Sie ihre eigenen Zählervariablen in Ihrer Builddefinition definieren, die bei jeder Ausführung eines Builds automatisch inkrementiert werden. Dies geschieht auf der Registerkarte "Variablen" einer Definition. Dieses neue Feature bietet Ihnen auf folgende Weise mehr Leistung:

• Sie können einen benutzerdefinierten Leistungsindikator definieren und dessen Ausgangswert festlegen. Für instance können Sie Ihren Zähler bei 100 starten. $(rev:r) beginnt immer bei 0.
• Sie können eine 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 Indikatoren pro Definition definieren.
• Sie können den Wert eines Indikators außerhalb eines Builds abfragen. Für instance können Sie die Anzahl der Builds, die seit dem letzten Zurücksetzen ausgeführt wurden, mithilfe eines Leistungsindikators zählen.

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

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

Wir möchten die Stabilität und Sicherheit von Software frühzeitig im Entwicklungsprozess gewährleisten und gleichzeitig Entwicklung, Sicherheit und Betrieb zusammenbringen. Dazu haben wir Unterstützung für Azure Policy hinzugefü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 mit Ihren Unternehmensstandards und Vereinbarungen zum Servicelevel konform.

Zur Einhaltung von Compliance- und Sicherheitsrichtlinien im Rahmen des Releaseprozesses haben wir unsere Azure-Ressourcengruppenbereitstellung verbessert. Jetzt schlägt die Azure-Ressourcengruppenbereitstellungsaufgabe mit relevanten richtlinienbezogenen Fehlern fehl, falls bei der Bereitstellung von ARM-Vorlagen Verstöße auftreten.

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.

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

Der plattformübergreifende Agent von Azure Pipelines Open Source wurde immer unter 64-Bit (x64) Windows, macOS und Linux unterstützt. Mit diesem Release führen wir zwei neue unterstützte Plattformen ein: Linux/ARM und Windows/32-Bit. Diese neuen Plattformen bieten Ihnen die Möglichkeit, auf weniger gängigen, aber nicht weniger wichtigen Plattformen wie dem Raspberry Pi, einem Linux-/ARM-Computer, zu bauen.

Verbesserte Funktionen für Tests in Pipelines

Die Registerkarte "Tests" verfügt jetzt über eine moderne Oberfläche, die Ihnen umfassende kontextbezogene Testinformationen für Pipelines bietet. Die neue Benutzeroberfläche bietet eine aktuelle Testansicht, eine vollständige Debugoberfläche, einen Kontexttestverlauf, berichte über abgebrochene Testausführungen und eine Zusammenfassung auf Ausführungsebene.

Anzeigen der Ausführung laufender Tests

Tests, z. B. Integrations- und Funktionstests, können für eine lange Zeit ausgeführt werden, sodass es wichtig ist, die Testausführung jederzeit zu sehen. Mit der In-Progress Testansicht müssen Sie nicht mehr warten, bis die Testausführung abgeschlossen ist, um das Testergebnis zu kennen. Die Ergebnisse sind nahezu in Echtzeit verfügbar, da sie ausgeführt werden, sodass Sie schneller Aktionen ausführen können. Sie können einen Fehler debuggen oder abbrechen, einen Fehler melden oder die Pipeline abbrechen. Das Feature ist derzeit sowohl für die Build- als auch für die Releasepipeline verfügbar, indem der VS-Testtask in der Multi-Agent-Phase verwendet wird, der Task Testergebnisse veröffentlichen oder Testergebnisse mithilfe von API(s) veröffentlicht wird. 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, in der die Gesamtanzahl der Tests und die Anzahl der Testfehler zu einem bestimmten Zeitpunkt gemeldet werden.

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

Details zum Debuggen des Testlaufs auf der ganzen Seite anzeigen

Fehlermeldungen und Stapelüberwachungen sind langwierig und benötigen genügend Immobilien, um die Details während des Debuggens anzuzeigen. Um eine immersive Debugerfahrung zu erhalten, können Sie jetzt die Test- oder Testlaufansicht auf die vollständige Seitenansicht erweitern, während Sie weiterhin die erforderlichen in Kontextvorgängen wie Fehlererstellung oder Anforderungszuordnung für das aktuelle Testergebnis ausführen können.

Anzeigen des Testverlaufs im Kontext

In der Vergangenheit mussten Teams zum Run Hub wechseln, um den Verlauf eines Testergebnisses anzuzeigen. Mit der neuen Benutzeroberfläche bringen wir den Testverlauf direkt in Test Plans Registerkarte für Build und Release in den Kontext. Die Testverlaufsinformationen werden schrittweise 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. release.

Anzeigen abgebrochener Tests

Die Testausführung kann aus mehreren Gründen abgebrochen werden, z. B. aufgrund von fehlerhaftem Testcode, zu testbarer Quelle und zu Umweltproblemen. 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 zusammen mit den abgeschlossenen Ausführungen in Test Plans anzeigen. Das Feature ist derzeit sowohl für die Build- als auch für die Releasepipeline mit VS-Testtask in der Multi-Agent-Phase oder für die Veröffentlichung von Testergebnissen mithilfe von API(s) verfügbar. In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Unterstützung von Testverfolgbarkeit und Releaseumgebungen im Testverlauf

Wir fügen Unterstützung für die Anzeige 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 diesen Umgebungen ausführen, können Sie herausfinden, ob ein Test in der Entwicklungsumgebung erfolgreich ist, aber in der Integrationsumgebung fehlschlägt. Sie könnten herausfinden, ob es im englischen Gebietsschema passiert, aber in einer Umgebung mit türkischem Gebietsschema fehlschlägt. Für jede Umgebung finden Sie die status des letzten Testergebnisses, und wenn der Test in dieser Umgebung fehlgeschlagen ist, finden Sie auch das Release, seit dem der Test fehlschlägt.

Überprüfen zusammengefasster Testergebnisse

Während der Testausführung kann ein Test mehrere Instanzen von Tests erzeugen, die zum Gesamtergebnis beitragen. Einige Beispiele sind: Tests, die aufgrund von Fehlern erneut ausgeführt werden, Tests, die aus einer geordneten Kombination anderer Tests bestehen (z. B. geordneter Test) oder Tests mit unterschiedlichen Instanzen basierend auf dem bereitgestellten Eingabeparameter (datengesteuerte Tests). Da diese Tests 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 als Hierarchie auf der Registerkarte Tests für ein Release angezeigt wird. Schauen wir uns ein Beispiel an.

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

Hinweis

Metriken im Abschnitt „Testzusammenfassung“ (z. B. Gesamttests, bestandene Tests usw.) werden anhand der Stammebene der Hierarchie und nicht mit jeder einzelnen Iteration der Tests berechnet.

Anzeigen von Testanalysen in Pipelines

Das Nachverfolgen der Testqualität im Zeitverlauf und die Verbesserung der Testsicherheit ist für die Aufrechterhaltung einer fehlerfreien Pipeline von entscheidender Seite. Die Testanalysefunktion bietet nahezu in Echtzeit Einblick in Ihre Testdaten für Builds und Releasepipelines. Dies trägt dazu bei, die Effizienz Ihrer Pipeline zu verbessern, indem wiederkehrende Qualitätsprobleme mit hohen Auswirkungen erkannt werden.

Sie können Testergebnisse nach verschiedenen Elementen gruppieren, wichtige Tests für Ihren Branch oder Ihre Testdateien identifizieren oder einen Drilldown zu einem bestimmten Test durchführen, um Trends anzuzeigen und Qualitätsprobleme wie Flakiness zu verstehen.

Sehen Sie sich test analytics for builds and release (Vorschau unten) an:

Weitere Informationen finden Sie in unserer Dokumentation.

Vereinfachen von Definitionen mit mehreren Aufgaben ohne Agent

Aufgaben in einer Phase ohne Agent werden vom Server orchestriert und ausgeführt. Phasen ohne Agent erfordern keinen Agent oder Keine Zielcomputer. 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 eine Aufgabe ohne Agent im Prozess vorhanden war, was die Definition sperrig machte. Wir haben diese Einschränkung gelockert, sodass Sie mehrere Aufgaben in phasen ohne Agent verwalten können. Die Aufgaben in derselben Phase würden sequenziell ausgeführt, genau wie bei Agentphasen. Weitere Informationen finden Sie in der Dokumentation zu Serverphasen .

Schrittweises Verfügbarmachen und Phasenbereitstellungen mithilfe von Releasegates

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

Halten Sie Bereitstellungen so lange fest, bis Gates konsistent erfolgreich sind.

Releasegates ermöglichen die automatische Auswertung von Integritätskriterien, bevor ein Release in die nächste Umgebung höhergestuft wird. Standardmäßig wird das Release fortgesetzt, nachdem ein erfolgreiches Beispiel für alle Gates empfangen wurde. Selbst wenn ein Tor erratisch ist und das erfolgreiche Beispiel rauschend ist, schreitet die Freigabe voran. Um diese Arten von Problemen zu vermeiden, können Sie das Release jetzt so konfigurieren, dass die Konsistenz der Integrität für eine mindeste Dauer vor dem Fortschritt überprüft wird. Zur Laufzeit würde das Release sicherstellen, dass aufeinanderfolgende Auswertungen der Gates erfolgreich sind, bevor die Heraufstufung zugelassen wird. Die Gesamtzeit für die Auswertung hängt von der "Zeit zwischen der Neubewertung" ab und liegt in der Regel über der konfigurierten Mindestdauer. Weitere Informationen finden Sie in der Dokumentation Zur Freigabe der Bereitstellungssteuerung mithilfe von Gates .

Automatische Bereitstellung für neue Ziele in einer Bereitstellungsgruppe

Wenn einer Bereitstellungsgruppe zuvor neue Ziele hinzugefügt wurden, war eine manuelle Bereitstellung erforderlich, um sicherzustellen, dass alle Ziele über dasselbe 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 .

Fortlaufende Bereitstellung von Builds mit Tags nach der Buildverarbeitung

Continuous Deployment-Trigger erstellen ein Release nach Abschluss des Builds. Manchmal werden Builds jedoch nachbearbeitet, 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 Releases zugewiesen würden.

Festlegen einer Variablen zur Releasezeit

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

Der für die Variable bereitgestellte Wert, wenn das Release erstellt wird, wird nur für dieses Release verwendet. Dieses Feature hilft Ihnen, mehrere Schritte für Create-in-Draft zu vermeiden, die Variablen im Entwurf zu aktualisieren und die Freigabe mit der Variablen auszulösen.

Übergeben von Umgebungsvariablen an Aufgaben

CI/CD-Aufgabenautoren können eine neue Eigenschaft, showEnvironmentVariables, in der 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.

Dies ermöglicht zwei Szenarien:

• Eine Aufgabe erfordert eine Umgebungsvariable mit beibehaltener Groß-/Kleinschreibung im Variablennamen. Für instance lautet im obigen Beispiel die an die Aufgabe übergebene Umgebungsvariable "foo" und nicht "FOO".
• Es ermöglicht es, Geheimnissewerte auf sichere Weise an die Skripts zu übergeben. Dies wird bevorzugt, um die Geheimnisse als Argumente an die Skripts zu übergeben, da das Betriebssystem auf dem Agent den Aufruf von Prozessen einschließlich ihrer Argumente protokolliert.

Klonen von Variablengruppen

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

Hinweis

Die Werte der Geheimvariablen werden beim Klonen einer Variablengruppe nicht kopiert. 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 in die nächste Umgebung höhergestuft wird. Standardmäßig wird die Releasepipeline nur dann fortgesetzt, wenn alle Gates gleichzeitig fehlerfrei sind. In bestimmten Situationen, z. B. beim Beschleunigen einer Freigabe oder nach der manuellen Überprüfung der Integrität, möchte ein genehmigender Benutzer möglicherweise ein Gate ignorieren und zulassen, dass die Freigabe fortgesetzt wird, auch wenn dieses Gate noch nicht als fehlerfrei bewertet wurde. Weitere Informationen finden Sie in der Dokumentation zu Releasegates .

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

Sie können einen Build basierend auf einem Pull Request (PR) auslösen und dieses schnelle Feedback vor einer Zusammenführung erhalten. Jetzt können Sie auch einen PR-Trigger für ein Release konfigurieren. Die status des Release wird zurück in das Coderepository veröffentlicht und kann direkt auf der PR-Seite angezeigt werden. Dies ist hilfreich, wenn Sie zusätzliche funktionale oder manuelle Tests im Rahmen Ihres PR-Workflows durchführen möchten.

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 FS konfiguriert ist. Informationen zum Erstellen eines Dienstprinzipals mit Zertifikatauthentifizierung finden Sie im Artikel zum Erstellen eines Dienstprinzipals, der sich mit einem Zertifikat authentifiziert.

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 (früher RunFromZip genannt).

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

Mit Run From Package gibt es keinen Bereitstellungsschritt mehr, der die einzelnen Dateien in wwwroot kopiert. Stattdessen zeigen Sie es einfach auf eine ZIP-Datei, und die ZIP-Datei wird in 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 Azure App Service Bereitstellungen.
• Kann Kaltstartzeiten verringern, insbesondere für JavaScript-Funktionen mit großen npm-Paketstrukturen.

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

Die 4.*-Version des Azure App Service Deploy-Tasks 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 beim Packen und Nutzen appspezifischer Abhängigkeiten bieten. Funktionen unter Linux können in 2 verschiedenen Modi gehostet werden:

1. Integriertes Containerimage: Sie bringen den Funktions-App-Code ein, und Azure stellt den Container (integrierter Imagemodus) bereit und verwaltet diese, sodass keine spezifischen Docker-Kenntnisse erforderlich sind. Dies wird in der vorhandenen Version von App Service Deploy-Aufgabe unterstützt.
2. Benutzerdefiniertes Containerimage: Wir haben den Task App Service Bereitstellen erweitert, um die Bereitstellung benutzerdefinierter Containerimages für Azure Functions unter Linux zu unterstützen. Wenn Ihre Funktionen eine bestimmte Sprachversion benötigen 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 in Azure Function unter Linux erstellen und bereitstellen.

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

Mit dem Release von Xcode 10 von Apple können Sie jetzt festlegen, dass Ihre Projekte speziell mit Xcode 10 erstellt oder getestet werden. Ihre Pipeline kann Aufträge auch parallel mit 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 den Anleitungen zur Verwendung von Xcode in Azure Pipelines.

Optimieren der Bereitstellung in Kubernetes mithilfe von Helm

Helm ist ein Tool, das die Installation und Verwaltung von Kubernetes-Anwendungen optimiert. Es hat auch viel Popularität und Communityunterstützung im letzten Jahr gewonnen. Eine Helm-Aufgabe in Release ist jetzt zum Packen und Bereitstellen von Helm-Diagrammen in Azure Container Service (AKS) oder einem beliebigen anderen Kubernetes-Cluster verfügbar.

Mit dieser Helm-Aufgabe können Sie jetzt eine Helm-basierte CI/CD-Pipeline für die Bereitstellung von Containern in einen Kubernetes-Cluster einrichten. Weitere Informationen finden Sie in der Dokumentation Bereitstellen mit Kubernetes in Azure Container Service .

Helm-Steuerelementversion, die in Release verwendet wird

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

Fortlaufende Bereitstellung in Azure Database for MySQL

Sie können jetzt kontinuierlich in Azure Database for MySQL bereitstellen: Die MySQL-Datenbank als Dienst von Azure. Verwalten Sie Ihre MySQL-Skriptdateien in der Versionskontrolle und stellen Sie kontinuierlich als Teil einer Releasepipeline bereit, indem Sie eine native Aufgabe anstelle von PowerShell-Skripts verwenden.

Verwenden verbesserter Windows-Remote-PowerShell-basierter Aufgaben

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

PowerShell on Target task (Version: 3.*): Sie können Inlineskript hinzufügen, PSSession-Optionen ändern, "ErrorActionPreference" steuern und beim Standardfehler fehlschlagen.

Azure File Copy-Aufgabe (Version: 2.*): Wird mit dem neuesten AzCopy (v7.1.0) geliefert, das ein GitHub-Problem behebt.

Filtern von Branches für GitHub Enterprise oder externe Git-Artefakte

Wenn Sie über GitHub Enterprise oder externe Git-Repositorys freigeben, können Sie jetzt die spezifischen Branches konfigurieren, die freigegeben werden. Beispielsweise können Sie nur Builds aus einem bestimmten Branch für die Produktion bereitstellen.

Erstellen von Anwendungen, die in Go geschrieben wurden

Verwenden Sie den Task Go Tool Installer , um eine oder mehrere Versionen von Go Tool on the Fly zu installieren. Dieser Task ruft eine bestimmte Version von Go Tool ab, die für Ihr Projekt benötigt wird, und fügt sie dem PFAD des Build-Agents hinzu. Wenn die zielorientierte Go Tool-Version bereits auf dem Agent installiert ist, überspringt diese Aufgabe den Prozess des Herunterladens und erneuten Installierens.

Mit dem Go-Task 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

Ein neuer Python-Skripttask vereinfacht die Ausführung von Python-Skripts in Ihrer Pipeline. Die Aufgabe führt ein Skript aus einer Python-Datei (.py) in Ihrem Repository aus, oder Sie können ein Skript manuell 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-Buildtask verwendet jetzt automatisch xcpretty, wenn es auf dem Agent-Computer verfügbar ist, wie bei gehosteten macOS-Agents. Obwohl die xcpretty-Ausgabe anders und weniger ausführlich sein kann als die xcodebuild-Ausgabe, stellen wir die vollständigen xcodebuild-Protokolle für jeden Build zur Verfügung.

Test Plans

Test Runner-Client (Azure Test Plans) zum Ausführen manueller Tests für Desktopanwendungen

Sie können jetzt den Test Runner-Client (Azure Test Plans) verwenden, um manuelle Tests für Desktopanwendungen auszuführen. Dadurch können Sie von Microsoft Test Manager zu Azure Test Plans wechseln. Weitere Informationen finden Sie hier in unserer Anleitung. Mit dem Test Runner-Client können Sie Ihre manuellen Tests ausführen und die Testergebnisse für jeden Testschritt aufzeichnen. Außerdem verfügen Sie über Datensammlungsfunktionen wie Screenshot, Bildaktionsprotokoll und Audiovideoaufzeichnung. Wenn beim Testen ein Problem auftritt, verwenden Sie Test Runner, um einen Fehler mit Testschritten, Screenshots und Kommentaren zu erstellen, die automatisch in den Fehler eingeschlossen werden.

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

Artifacts

Upstreamquellen

Azure DevOps Server 2019 bietet umfangreiche Updates für die Upstream Quellen, die in Ihren Azure Artifacts-Feeds verfügbar sind:

• Sie können vorhandenen Feeds, die in früheren TFS-Releases erstellt wurden, nuget.org Upstream Quellen hinzufügen. Suchen Sie nach dem Banner über den Paketen Ihres Feeds, um weitere Informationen zu erhalten, einschließlich Verhaltensänderungen, die Sie vor dem Upgrade beachten sollten.
• Sie können Ihrem Feed andere Azure DevOps Server Feeds als Upstream Quellen 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: "Mitarbeiter". Ein Projektmitarbeiter kann Pakete aus einer Upstream Quelle speichern, pakete jedoch nicht direkt im Feed veröffentlichen (z. B. mithilfe von nuget publish). Auf diese Weise können Sie die Paketveröffentlichung auf einen vertrauenswürdigen Benutzer oder das Buildsystem beschränken, während Ihre Techniker neue Pakete aus Ihren Upstream Quellen verwenden können.

Folgen von Paketen

Wir haben es noch einfacher gemacht, Benachrichtigungen mit einer neuen Schaltfläche "Folgen" direkt auf jedem Paket einzurichten. 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 heraufgestuft werden.

Ändern der Feedeinstellungen, ohne manuell speichern zu müssen

Einige der Interaktionen auf der Seite mit den Feedeinstellungen wurden verbessert. Änderungen, die Sie vornehmen, z. B. das Hinzufügen eines Upstream oder einer Berechtigung, werden sofort gespeichert. Dies bedeutet, dass Sie sich keine Sorgen machen müssen, dass Änderungen verloren gehen, wenn Sie zwischen den Einstellungen pivots wechseln.

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

Die Interaktion mit authentifizierten NuGet-Feeds ist deutlich besser geworden. Der neue .NET Core-basierte Azure Artifacts-Anmeldeinformationsanbieter funktioniert mit msbuild, dotnet und nuget(.exe) unter Windows, macOS und Linux. Wenn Sie Pakete aus einem Azure Artifacts-Feed verwenden möchten, ruft der Anmeldeinformationsanbieter automatisch ein Token im Namen des verwendeten NuGet-Clients ab und speichert es. Sie müssen ein Token nicht mehr manuell in einer Konfigurationsdatei speichern und verwalten.

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

Komprimieren von Symbolen beim Veröffentlichen in einer Dateifreigabe

Wir haben die Aufgabe Index & Veröffentlichen von Symbolen aktualisiert, um das Komprimieren von Symbolen zu unterstützen, wenn sie in einer Dateifreigabe veröffentlicht werden.

Wiki

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

Entwickler erstellen Dokumentationen für "APIs", "SDKs" und "Hilfedokumentationen zur Codeerklärung" in Coderepositorys. Leser müssen dann Code durchsuchen, um die richtige Dokumentation zu finden. Jetzt können Sie einfach Markdowndateien aus Coderepositorys veröffentlichen und in Wiki hosten.

Klicken Sie in Wiki auf Code als Wiki veröffentlichen. Als Nächstes können Sie einen Ordner in einem Git-Repository angeben, der höher gestuft werden soll.

Sobald Sie auf Veröffentlichen klicken, werden alle Markdowndateien unter dem ausgewählten Ordner als Wiki veröffentlicht. Dadurch wird auch der Hauptteil des Branchs dem Wiki zugeordnet, sodass alle Änderungen, die Sie am Git-Repository vornehmen, sofort widerzuspiegeln.

Weitere Informationen finden Sie im Blogbeitrag zur Produktdokumentation .

Verknüpfen mit Überschriften innerhalb einer Seite

Jetzt können Sie auf das Linksymbol neben einer beliebigen Abschnittsüberschrift in einer Wiki-Seite klicken, um eine URL direkt zu diesem Abschnitt zu generieren. Anschließend können Sie diese URL kopieren und für Teammitglieder freigeben, um sie direkt mit diesem Abschnitt zu verknüpfen.

Anfügen von Dateien und Bildern in Ordnern

Während der Offlinebearbeitung von Wiki-Seiten kann es einfacher sein, Dateianlagen und Bilder im selben Verzeichnis wie die Wiki-Seite hinzuzufügen. Jetzt können Sie eine Anlage oder ein Bild in einem beliebigen Ordner im Wiki hinzufügen und mit Ihrer Seite verknüpfen.

Einbetten eines Videos in das Wiki

Jetzt können Sie Videos aus Onlinedienste wie Microsoft Stream und YouTube in eine Wiki-Seite einbetten. Sie können die eingebettete Video-URL mithilfe 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>
:::

Umbenennen eines Wikis

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

Öffnen der Seite in einer neuen Registerkarte

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

Sonderzeichen in Wiki-Seitentiteln beibehalten

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

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

Anzeigen fehlerhafter Links

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

Beheben fehlerhafter Links beim Verschieben von Seiten

Fehlerhafte Seitenlinks sind eine der Hauptursachen für schlechte Seitenqualität in jeder Dokumentationslösung. Wenn Sie zuvor in Wiki eine Seite innerhalb der Strukturstruktur verschoben oder eine Seite umbenannt haben, konnte dies möglicherweise Links zur Seite von anderen Seiten und Arbeitselementen unterbrechen. Jetzt können Sie Links suchen und 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 potenziell fehlerhaften Links finden und beheben kann. Nur-Text-URLs und Hyperlinks in Arbeitselementen werden von diesem Feature nicht erfasst.

Wenn Sie eine Seite umbenennen oder verschieben, werden Sie aufgefordert, nach den betroffenen absoluten oder relativen Links zu suchen.

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

Erstellen eines Inhaltsverzeichnisses für Wiki-Seiten

Manchmal können Wiki-Seiten lang werden, wobei Inhalte in mehreren Überschriften organisiert sind. Jetzt können Sie mithilfe der Syntax einer beliebigen Seite mit mindestens einer Überschrift [[_TOC_]] ein Inhaltsverzeichnis hinzufügen.

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

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

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 erkennen 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 einer gültigen YAML-Gruppe zwischen dreifach gestrichelten Zeilen aufweisen. Es unterstützt alle grundlegenden Datentypen, Liste, Objekt als Wert. Die Syntax wird in der Wiki - und Codedateivorschau unterstützt.

BEISPIEL FÜR YAML-Tags:

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

BEISPIEL für YAML-Tags mit Liste:

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

Veröffentlichen von Code als Wiki mit Den Berechtigungen "Mitwirken"

Zuvor konnten nur Benutzer mit der Berechtigung Repository erstellen für ein Git-Repository Code als Wiki veröffentlichen. Dies machte die Repositoryadministratoren oder Ersteller zu einem Engpass für alle 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 Mitwirken 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 verfügbar. Analytics ist die Zukunft der Berichterstellung für Azure DevOps und Azure DevOps Server. Die Installation der Analytics-Erweiterung bietet erweiterte Widgets, Power BI-Integration und OData-Zugriff.

Weitere Informationen finden Sie unter What is Analytics and the Reporting Roadmap. Analytics befindet sich in der öffentlichen Vorschau. Sie enthält derzeit Daten für Boards und automatisierte Testergebnisse über Pipelines. Weitere Informationen finden Sie unter In Analytics Service verfügbare Daten.

Untersuchen des Buildverlaufs mithilfe eines neuen Build-Dashboard-Widgets

Wir verfügen über ein neues und verbessertes Buildverlaufswidget, das Sie Ihren Dashboards hinzufügen können. Mit diesem Widget können Sie jetzt einen Verlauf von Builds aus einem bestimmten Branch auf Ihrem Dashboard anzeigen und ihn für ein öffentliches Projekt für anonyme Besucher 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, es über Entwicklercommunity nachverfolgen und Sich zu Stack Overflow beraten lassen.

---

Seitenanfang