Azure DevOps Server 2019 – Versionshinweise

Entwickler-Community | Systemanforderungen | Lizenzbedingungen | DevOps-Blog | SHA-1-Hashes

In diesem Artikel finden Sie Informationen zur neuesten Version für Azure DevOps Server.

Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server-Bereitstellung finden Sie unter Azure DevOps Server Requirements. Um Azure DevOps-Produkte herunterzuladen, besuchen Sie die Seite "Azure DevOps Server-Downloads".

Direktes 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 einer früheren Version befindet, müssen Sie vor dem Upgrade auf Azure DevOps Server 2019 einige Zwischenschritte ausführen. 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 die Pipelineausführung (Build) ein, das basierend auf den Einstellungen auf Projektebene funktioniert.

Azure DevOps Server 2020 behandelt die Buildaufbewahrung anders, basierend auf Aufbewahrungsrichtlinien auf Pipelineebene. Bestimmte Richtlinienkonfigurationen führen dazu, dass Pipeline-Durchläufe nach dem Upgrade gelöscht werden. Pipelineausführungen, die manuell oder durch eine Freigabe aufbewahrt wurden, werden nach dem Upgrade nicht 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.

• Erweiterte die Liste der zulässigen Zeichen für PowerShell-Aufgaben zur Parameterüberprüfung von Argumenten für die Aktivierung von Shellaufgaben.

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 Agentupdates nicht installiert haben, wie in den Versionshinweisen für Patch 15 beschrieben, empfehlen wir, 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 Projektsammlungen aus, um die Installation und Anmeldung mit TFX-CLI durchzuführen.

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256-Hashwert
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Laden Sie Tasks20231103.zip herunter, und extrahieren Sie sie.
2. Wechseln Sie in das Verzeichnis der 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 

Pipeline-Anforderungen

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

• Zum Klassiker:

  Definieren Sie die Variable im Variablen-Tab 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; Sicherheitsrisiko bei der Azure DevOps Server-Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server zur Erhöhung von Berechtigungen.

Wichtig

Stellen Sie den Patch in einer Testumgebung bereit, und stellen Sie sicher, dass die Pipelines der Umgebung wie erwartet 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 hier herunter: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. Führen Sie die in der Dokumentation zu selbst gehosteten Windows-Agents beschriebenen Schritte aus, um den Agent bereitzustellen.  

Hinweis

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 Administrator-Eingabeaufforderung 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 Projektsammlungen aus, um die Installation und Anmeldung mit TFX-CLI durchzuführen.

Aktualisieren von Aufgaben mithilfe von TFX

1. Laden Sie Tasks_20230825.zip herunter und extrahieren Sie sie.
2. Wechseln Sie in das Verzeichnis der 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 AZP_75787_ENABLE_NEW_LOGIC = true-Variable in Pipelines festgelegt werden, die die betroffenen Aufgaben verwenden.

• Im klassischen Modus:

  Definieren Sie die Variable auf der Variablen-Registerkarte 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: Sicherheitsanfälligkeit in Azure DevOps Server durch 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 aller 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: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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.

• Behebung des UI-Fehlers in der Build-Definition.

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.

AzureResourceGroupDeploymentV2-Aufgabeninstallation

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 Node.js 14.15.1 und npm (im Node.js-Download enthalten) entsprechend Ihrer Maschine herunter und installieren Sie diese.

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 das Folgende 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 2019.0.1 Patch 9 Veröffentlichungsdatum: 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: Spoofing-Sicherheitsanfälligkeit in Azure DevOps Server
• CVE-2020-17135: Spoofing-Sicherheitsanfälligkeit in Azure DevOps Server
• CVE-2020-17145: Sicherheitsrisiko durch Spoofing in Azure DevOps Server und Team Foundation Server
• Behebung eines Problems mit TFVC, das nicht alle Ergebnisse verarbeitet

Wichtig

Lesen Sie die unten aufgeführten vollständigen Anweisungen, 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: Ausführen devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe ist die Datei, die aus dem obigen Link heruntergeladen wird. Die Ausgabe des Befehls gibt entweder an, 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 nach c:\Program Files\Azure DevOps Server 2019 installiert. Nach der Installation von Azure DevOps Server 2019.0.1 Patch 9 ist 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 das Azure PowerShell Az-Modul Azure Powershell auf Ihrem privaten Agent-Computer.

2. Erstellen Sie eine Pipeline mit der AzurePowerShellV4-Aufgabe . Sie werden nur einen Fehlschlag bei Standardfehler in der Aufgabe sehen.

Installieren

1. Extrahieren Sie das AzurePowerShellV4.zip-Paket in einen Ordner namens AzurePowerShellV4.

2. Laden Sie Node.js 14.15.1 und npm (im Node.js-Download enthalten) für Ihr System herunter und installieren Sie sie.

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 ist D:\tasks (1)\AzurePowerShellv4.

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

Azure DevOps Server 2019.0.1 Patch 8 Veröffentlichungsdatum: 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 2019.0.1 Patch 7 Veröffentlichungsdatum: 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: Sicherheitsrisiko bei websiteübergreifendem Skripting
• Die Buildpipeline zeigt eine falsche Verbindung für nicht autorisierte Benutzer beim Auswählen einer anderen Git-Quelle an.
• Behebung eines Fehlers beim Ändern der Vererbung in "Ein" oder "Aus" in der XAML-Builddefinition.

Azure DevOps Server 2019.0.1 Patch 6 Veröffentlichungsdatum: 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 sanitiert
• Hinzufügen von Unterstützung für SHA2 in SSH in Azure DevOps

Azure DevOps Server 2019.0.1 Patch 5 Veröffentlichungsdatum: 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 Erweiterung von Berechtigungen
• CVE 2020-0815: Erhöhung der Berechtigungen Sicherheitsanfälligkeit

Azure DevOps Server 2019.0.1 Patch 3 Veröffentlichungsdatum: 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: Cross-Site Scripting (XSS) Schwachstelle in Repos
• CVE-2019-1306: Sicherheitsrisiko durch Remotecodeausführung in Wiki

---

Azure DevOps Server 2019.0.1 Patch 2 Veröffentlichungsdatum: 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 2019.0.1 Patch 1 Veröffentlichungsdatum: 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

---

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

Azure DevOps Server 2019.0.1 ist ein Rollup von Fehlerbehebungen. Es enthält alle Fixes in den zuvor veröffentlichten Azure DevOps Server 2019-Patches. Sie können Azure DevOps Server 2019.0.1 oder ein Upgrade von Azure DevOps Server 2019 oder Team Foundation Server 2012 oder höher direkt installieren.

Hinweis

Das Datenmigrationstool ist ungefähr 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. Über die Entwickler-Community gemeldet.
• apiwitcontroller.executequery löst eine Ausnahme aus, wenn eine Abfrage mehrmals dieselbe Spalte aufweist.
• Im Clientobjektmodell mit dem vso.work_full oauth-Bereich schlägt WorkItemServer.DownloadFile() fehl.
• Das Kopieren eines eingebetteten Bilds aus einem Arbeitsaufgabenfeld in ein anderes Arbeitsaufgabenfeld in einem anderen Projekt kann zu einem fehlerhaften Bild führen.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• Die Registerkarte "Testanalyse" weist einen Stern (*) auf, der die Vorschau angibt, obwohl dieses Feature nicht in der Vorschau enthalten ist.
• Auf der Registerkarte "Versionen " 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 Landingpages „Releases“ wurde die Aktion „Entwurf einer Version starten“ anfangs zum Erstellen einer neuen Version verwendet; jetzt wird damit der Entwurf der Version gestartet.

Azure Testpläne

• Der 1-Stunden-Filter für testRuns und TestResults CompletedDate ist zu granular.
• Im Arbeitsaufgabentyp "Testfall" sollte der Typ "Testfall" nicht lokalisiert werden.
• Testfälle werden in MTM oder einem Browser nicht angezeigt.
• Fehler "Überprüfungsphase: Sie verfügen nicht über die Berechtigung zum Auslösen von Versionen in der zugehörigen Releasepipeline", wenn automatisierte Tests aus einem Testplan ausgeführt werden. Wird über die Entwicklercommunity gemeldet.
• Mithilfe der Löschfall-API können Testfälle aus anderen Projekten gelöscht werden. Wird über die Entwickler-Community gemeldet.
• Durch Klicken auf einen Arbeitsaufgabenlink in Test Runner wird die Arbeitsaufgaben-URL in Test Runner anstelle des Standardbrowsers geöffnet.
• Der Testfallstatus wird für Benutzer, die sich bei Test Runner abmelden, nicht aktualisiert.
• Benutzername und E-Mail-Adresse werden nicht in der Dropdownliste des Benutzers in Test Runner angezeigt.

Azure Artifacts

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

Analytik

• Analyseberichte zeigen möglicherweise unvollständige Daten an, da das Modell als "bereit" gekennzeichnet ist, bevor es tatsächlich abgeschlossen ist.
• Die Geschwindigkeits-, Burndown- und Burnup-Widgets zeigen unterschiedliche geplante Arbeit für Benutzer in verschiedenen Zeitzonen an.
• Während der Wartungsarbeiten kann eine Unterbrechung der Erfassung von Analysedaten auftreten, was zu veralteten Berichten führen kann.

Allgemein

• Die Elemente der Linksnavigation werden in Internet Explorer eingeengt, wenn nicht genügend Platz vorhanden ist.

Verwaltung

• Zusätzliche Protokollierung zum Sammlungsupgrade hinzugefügt, um das Debuggen von Problemen zu erleichtern.
• 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 möglicherweise Benachrichtigungen nicht korrekt.
• Die Code-Such-Indizierung startet nicht nach der Konfiguration der Suche.
• Es gibt nicht lokalisierte Zeichenfolgen auf Suchergebnissen.

Diese Version enthält das folgende Update:

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

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

---

Azure DevOps Server 2019 Patch 2 Veröffentlichungsdatum: 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 Cross-Site-Scripting (XSS) in den Testplänen
• 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

---

Veröffentlichungsdatum von Azure DevOps Server 2019 Patch 1: 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-Sicherheitsanfälligkeit 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 beim Einfügen von HTML in Pipelines
• CVE-2019-0870: Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
• CVE-2019-0871: Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Pipelines
• CVE-2019-0874: Sicherheitsanfälligkeit in Pipelines (Cross Site Scripting, XSS)
• CVE-2019-0875: Sicherheitsrisiko bei Erhöhung von Berechtigungen in Boards

---

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

Hinweis

Das Datenmigrationstool ist ungefähr drei Wochen nach dieser Version für Azure DevOps Server 2019 verfügbar. 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 folgende Funktionen hinzugefügt:

• Verknüpfen von GitHub Enterprise-Commits und Pullanforderungen an Azure Boards-Arbeitsaufgaben
• Konfigurieren von Builds mithilfe von YAML
• Kartenanmerkungen umfassen Fehler und benutzerdefinierte Arbeitsaufgabentypen
• Verbesserte Branchauswahl
• Änderungen an Artefakten und der Lizenzierung der Release-Management-Pipeline

---

RC1 Veröffentlichungsdatum: 19. November 2018

Zusammenfassung der Neuerungen in Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 führt eine neue Navigationsoberfläche und viele neue Features ein. 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
• Prozessvererbung bei neuen Sammlungen
• Hub für neue Arbeitsaufgaben
• Neue Boards, Backlogs und Sprints-Hubs
• Hub für neue Abfragen
• Standardisieren von Pullanforderungsbeschreibungen mithilfe von Vorlagen
• Change the target branch of a pull request (Ändern des Zielbranches eines Pull Requests)
• Verwalten von Buildpipelines mithilfe der neuen Builds-Seite
• Verwalten von Veröffentlichungspipelines mithilfe der neuen Seite "Freigaben"
• Visualisieren des Veröffentlichungsfortschritts
• Aktualisieren Sie lokal Ihren Agenten
• Schrittweise Offenlegung und phasenweise Bereitstellungen mithilfe von Release Gates
• Vorgelagerte Quellen
• Inhaltsverzeichnis für Wiki-Seiten erstellen

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 von Azure DevOps Server

Am 10. September haben wir Azure DevOps als Entwicklung von Visual Studio Team Services und Team Foundation Server angekündigt. Azure DevOps Server 2019 ist unsere erste lokale Version 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 Artefakten und der Lizenzierung der Release-Management-Bereitstellungspipeline

Basierend auf Benutzerfeedback nehmen wir zwei wichtige Änderungen an unseren Lizenzen mit Azure DevOps Server 2019 vor. Zuerst müssen Kunden die Artefakterweiterung nicht mehr erwerben, um Artefakte zu verwenden. Eine Artefaktlizenz wird jetzt in der Basislizenz enthalten sein. Alle Benutzer, denen eine Standardlizenz zugewiesen ist, können jetzt Artefakte verwenden. Zweitens müssen Kunden keine Versionsverwaltungsbereitstellungspipelines mehr erwerben. Genau wie Buildpipelines sind Versionsverwaltungsbereitstellungspipelines 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 unterstützung für Azure SQL-Datenbank (General Purpose S3 und höher) aktiviert. Auf diese Weise können Sie umfangreiche Sicherungsfeatures und Skalierungsoptionen für Ihre Anforderungen nutzen und gleichzeitig den Verwaltungsaufwand für die Ausführung des Diensts verringern. Beachten Sie, dass sich Ihre Host-VM in derselben Azure-Region wie Ihre Datenbank befinden muss, um die Latenz gering zu halten. Weitere Informationen finden Sie in der Dokumentation.

Arbeitselement- und Testclientobjektmodell-SOAP-APIs in zukünftigen Versionen

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

Verarbeitung der Vererbung bei neuen Sammlungen

Die Vererbung von Prozessen 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 bringen das erweiterte Suchfeld in der Produktkopfzeile zurück. Darüber hinaus können Sie das Suchfeld jetzt aufrufen, indem Sie einfach auf einer beliebigen Dienstseite in Azure DevOps auf "/" klicken.

Hier ist das Standardmäßige Suchfeld:

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

Mein Arbeits-Flyout

Ein neues Feature, auf das wir uns sehr freuen, ist das „Mein Arbeitsbereich“-Flyout. Wir haben Feedback gehört, dass Sie, wenn Sie sich in einem Teil des Produkts befinden und einige Informationen von einem anderen Teil benötigen, Ihren Kontext nicht verlieren möchten. Mit diesem neuen Feature können Sie von überall im Produkt aus auf dieses Flyout zugreifen, und es bietet Ihnen einen schnellen Blick auf wichtige Informationen, einschließlich Ihrer Arbeitsaufgaben, Pullanforderungen und aller Favoriten. Wenn Sie sich mit diesem neuen Flyout in Repos vertieft in Ihrem Code befinden, aber dann schnell überprüfen möchten, an welcher Aufgabe Sie als Nächstes arbeiten sollten, können Sie einfach auf das Flyout klicken, um die Ihnen zugewiesenen Aufgaben zu sehen und das nächste Element auszuwählen.

Unten sehen Sie das Flyout "Meine Arbeit", in dem die mir zugewiesenen Arbeitsaufgaben angezeigt werden:

Hier sehen Sie den zweiten Pivot, der die mir zugewiesenen PRs anzeigt. Im Flyout haben Sie mit einem Klick Zugriff, um weitere Pull-Requests anzuzeigen.

Hier können Sie das letzte Pivot sehen, bei dem es sich um alles handelt, was Sie als Favoriten ausgewählt haben. Dazu gehören Ihre bevorzugten Teams, Dashboards, Boards, Backlogs, Abfragen und Repositorys:

Bretter

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

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

Das Verknüpfen von Commits und Pull-Anforderungen mit Arbeitsaufgaben ist einfach. Erwähnen Sie die Arbeitsaufgabe mithilfe der folgenden Syntax:

AB#{work item ID}

Erwähnen Sie eine Arbeitsaufgabe in einer Commit-Nachricht, Pullanforderungstitel oder Pullanforderungsbeschreibung, und Azure Boards erstellt einen Link zu diesem Artefakt. Betrachten Sie z. B. eine Commit-Nachricht wie folgt:

Adds support for deleting connections. Fixes AB#20.

Dadurch wird ein Link aus der Arbeitsaufgabe #20 zum Commit in GitHub erstellt, der im Abschnitt "Entwicklung der Arbeitsaufgabe" angezeigt wird. ​

Wenn die Wörter "fix", "fixes" oder "fixed" vor der Erwähnung der Arbeitsaufgabe stehen (wie oben dargestellt), wird die Arbeitsaufgabe 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 Arbeitsaufgaben, die mit ihren GitHub-Commits verknüpft sind, in der Buildzusammenfassung.

Hub für neue Arbeitselemente

Der Hub für Arbeitsaufgaben ist unser neuer Hub, der als Zuhause Ihrer Arbeitsaufgaben dient! Hier haben Sie viele verschiedene Listenansichten Ihrer Arbeitsaufgaben, die speziell für Sie eingegrenzt sind. Sie können "Zugewiesen an mich" anzeigen, um schnell einen Blick auf alle Ihnen zugewiesenen Oder zuletzt aktualisierten Arbeiten zu erhalten, die Ihnen alle Arbeitsaufgaben in Ihrem Projekt zeigen, die zuletzt aktualisiert wurden. Alle Listenoptionen sind unten zu sehen:

Wenn Sie ihre Listen noch weiter einschränken möchten, können Sie nach Typ, zugewiesenem Typ, Status, Bereich, Tags und Schlüsselwort filtern. Sobald Sie die gewünschte Listenansicht haben, können Sie die Arbeitsaufgaben sortieren, indem Sie einfach auf die Spaltenüberschrift 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 können unten angezeigt werden:

Neue Boards, Backlogs und Sprint-Hubs

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

• Der Backlogs-Hub ist jetzt nur für die Backlogs eines Projekts. Ein Backlog ist eine priorisierte Liste der Arbeit für das Team. Backlogs bieten Planungstools wie Arbeitsaufgabenhierarchie, Prognose und neue Sprintplanungserfahrungen.
• Der neue Boards-Hub ist der zentrale Knotenpunkt aller Kanban-Boards für ein Projekt. Boards werden verwendet, um den Status und den Ablauf zu kommunizieren. Karten (Arbeitsaufgaben) wandern von links nach rechts über die Tafel durch Spalten, die vom Team definiert wurden.
• Der neue Sprints-Hub ist die zentrale Anlaufstelle für Features, die zum Planen und Ausführen eines Arbeitsschritts verwendet werden. Jeder Sprint enthält einen Sprint-Backlog, ein Taskboard und eine Ansicht zum Verwalten und Festlegen der Kapazität für das Team.

Hub für neue Abfragen

Der neue Abfragehub optimiert viele der vorhandenen Abfragefeatures vom alten Hub mit einem moderneren Erscheinungsbild und bietet neue Funktionen, um die Für Sie wichtigen Abfragen leichter zu erreichen. Einige Highlights der neuen Oberfläche sind:

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

Lesen Sie mehr über diese spannenden Updates in unserem DevOps-Blog.

Verschieben von Arbeitsaufgaben in ein anderes Projekt und Ändern eines Arbeitsaufgabentyps

Sie können nun den Arbeitsaufgabentyp ändern oder Arbeitsaufgaben in ein anderes Projekt in 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.

Sprintplanungsfunktionen

Die neuen Sprintplanungsfunktionen 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 Arbeitsaufgaben in zukünftige Sprints zu ziehen und abzulegen. Der Planungsbereich enthält Sprinttermine, Arbeitsaufgabenanzahl und geplante Arbeit.
• Fügen Sie Anforderungen oben im Taskboard hinzu, oder verwenden Sie die Schnellerstellung, um sie an den oberen, unteren oder einen gewünschten Platz in Ihrem Sprint-Backlog hinzuzufügen.
• Verwenden Sie Filter für Assignee, Work Item Type, State 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:

• Weiter dort, wo Sie aufgehört haben. Dieser neue Abschnitt bietet Ihnen einen schnellen Link direkt zum letzten (Board | Backlog | Sprint), auf dem Sie zuletzt waren.
• Favoriten Alle Ihre bevorzugten Boards, Sprints und Backlogs in allen Teams.
• Meine Tafeln, Backlogs und Sprints für Teams, zu denen Sie gehören.
• Alle Eine vollständige Liste Ihrer 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, wie das Anzeigen der Hierarchie in Backlogs oder das Ändern der Option "Gruppieren nach" auf einem Taskboard, um das Seitenfenster für die Zuordnung und Planung von Sprints zu aktivieren oder Arbeitsdetails-Diagramme zu untersuchen.

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

Kartenanmerkungen umfassen Fehler und benutzerdefinierte Arbeitsaufgabentypen

Kartenanmerkungen werden für ihre intuitive Prüflistenansicht und -interaktion geliebt. Zuvor waren Kartennotizen auf Standard-Backlog-Ebenentypen beschränkt und unterstützten Fehler oder benutzerdefinierte Typen nicht. Mit der neuen Version haben wir die Einschränkung für Arbeitsaufgabentypen entfernt und die Möglichkeit hinzugefügt, Fehler und alle benutzerdefinierten Arbeitsaufgabentypen als Kartenanmerkung anzuzeigen.

Tafeleinstellungen für Kartenanmerkungen wurden erweitert, um alle für diese Rückstandsebene verfügbaren Arbeitsaufgabentypen einzuschließen.

Wenn Kommentare für einen Arbeitsposten aktiviert sind, wird die Anzahl dieses Arbeitspostentyps auf der Karte als separate Checkliste aufgenommen.

Die schnelle Erstellung aktivierter Arbeitsaufgabentypen ist auch über das Kartenkontextmenü verfügbar.

Arbeiten verschieben unter Verwendung der vorgeschlagenen Bereiche und Iterationen

Es kann üblich sein, in demselben Bereich oder in derselben Iteration zu arbeiten und wiederholt durch die Hierarchien zu navigieren, wenn Arbeitsaufgaben verschoben werden. Die Steuerelemente für den Bereichs- und Iterationspfad enthalten nun eine Liste der zuletzt verwendeten Werte als Vorschläge, wodurch Sie schnell Werte festlegen und fortfahren können.

Darüber hinaus sind Iterationstermine rechts neben dem Namen enthalten, damit Sie schnell beurteilen können, wann eine Arbeitsaufgabe geliefert werden soll.

Arbeiten im Rahmen des Iterationsplans abfragen mit +/- @CurrentIteration

Das @CurrentIteration Makro, das Ihrem Team hilft, Die Arbeit basierend auf Ihrem Iterationszeitplan nachzuverfolgen, unterstützt jetzt den ganzzahligen Offset. Behalten Sie ganz einfach den Überblick über die Arbeit, die nicht mit @CurrentIteration - 1 abgeschlossen wurde, oder schauen Sie sich die Arbeit an, die mit @CurrentIteration + 1 für zukünftige Iterationen geplant ist. Weitere Informationen finden Sie im @CurrentIteration Beitrag im Microsoft DevOps-Blog.

Klären von Abfrage iterationszeitplänen mit dem @CurrentIteration Parameter "Team"

Wenn Sie das @CurrentIteration Makro in Abfragen in der Vergangenheit 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 teamübergreifend verwenden. Ein Beispiel kann eine Abfrage für Arbeitsaufgaben in zwei verschiedenen Teamprojekten sein, wobei verschiedene Iterationsnamen und sogar Zeitpläne verwendet werden. Dies bedeutet, dass keine Abfragen 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 einem oder mehreren Bereichspfaden zuordnen, womit Sie Backlogs, Boards, Pläne und sogar Dashboards auf die Arbeit dieses Teams konzentrieren können. Wenn Sie jedoch eine Abfrage für ein Team schreiben möchten, mussten Sie die spezifischen Bereichspfade für dieses Team in den Abfrageklauseln auflisten. Jetzt steht ihnen ein neues @TeamAreas Makro zur Verfügung, um auf einfache Weise auf die Bereichspfade zu verweisen, die dem angegebenen Team gehören.

Abfrage nach leeren Rich-Text-Feldern

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

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

Wenn Sie zwei vorhandene Arbeitsaufgaben miteinander verknüpfen möchten, können Sie jetzt ganz einfach das Element finden, das für Sie wichtig ist, indem Sie unser neues Suchsteuerelement für Arbeitsaufgaben verwenden. Die Abfrageauswahl wurde durch Inlinevorschläge basierend auf Ihren zuletzt geöffneten Arbeitsaufgaben sowie durch einen Einstiegspunkt ersetzt, um nach einer bestimmten Arbeitsaufgabe nach ID oder Titel zu suchen.

Arbeitselemente aus der Suche veröffentlichen

Zuvor konnte eine Arbeitsaufgabe nicht über die Suchergebnisseite geöffnet werden, wenn der Vorschaubereich der Arbeitsaufgabe deaktiviert wurde. Dies würde es erschweren, Ihre Suchergebnisse genauer zu untersuchen. Jetzt können Sie auf den Titel der Arbeitsaufgabe klicken, um die Arbeitsaufgaben in einem modalen Fenster zu öffnen.

Repos

Verbesserte Branchauswahl

Die meisten Erfahrungen in Azure Repos erfordern, dass Sie ein Repository und dann eine Verzweigung in diesem Repository auswählen. Um das Erlebnis für Organisationen mit einer großen Anzahl von Filialen zu verbessern, werden wir eine neue Filialauswahl einführen. Das Auswahlwerkzeug ermöglicht es Ihnen jetzt, Ihre bevorzugten Zweige auszuwählen oder schnell nach einem Zweig zu suchen.

Empfangen von Benachrichtigungen, wenn Pull-Anforderungsrichtlinien umgangen werden

Für Teams, die Pullanforderungen (Pull Requests, PRs) und Verzweigungsrichtlinien verwenden, kann es vorkommen, dass Personen diese Richtlinien aufheben 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, das richtige zu tun und die Außerkraftsetzungsfunktion sparsam zu verwenden. Gleichzeitig benötigen Teams eine Möglichkeit, zu überprüfen, ob diese Ausnahmen in den richtigen Situationen verwendet werden. Um dies zu unterstützen, haben wir einen neuen Benachrichtigungsfilter hinzugefügt, um Benutzern und Teams das Empfangen von E-Mail-Benachrichtigungen zu ermöglichen, sobald eine Richtlinie umgangen wird. Beginnen Sie mit der Vorlage A-Pull-Request wird erstellt oder aktualisiert und wählen Sie Richtlinienumgehung aus der Liste der Filter aus. Wählen Sie den Wert Richtlinien wurden umgangen aus, und Sie werden jedes Mal benachrichtigt, wenn eine PR abgeschlossen ist und Richtlinien umgangen werden.

Das Umgehen von Verzweigungsrichtlinien zulassen, ohne auf Push-Schutz zu verzichten

Es gibt viele Szenarien, in denen Sie gelegentlich eine Verzweigungsrichtlinie umgehen müssen – eine Änderung rückgängig machen, die einen Buildfehler verursacht hat, einen Hotfix mitten in der Nacht anwenden usw. Zuvor haben wir eine Berechtigung ("Ausgenommen von der Richtlinienerzwingung") angeboten, um Teams dabei zu helfen, festzulegen, welche Benutzer beim Abschließen einer Pullanforderung die Möglichkeit erhalten, Verzweigungsrichtlinien zu umgehen. Diese Berechtigung gewährte jedoch auch die Möglichkeit, direkt in den Branch zu verbreiten und den PR-Prozess vollständig zu umgehen.

Um das Nutzererlebnis zu verbessern, haben wir die alte Berechtigung aufgeteilt, damit Teams, die Umgehungsberechtigungen gewähren, mehr Kontrolle erhalten. Es gibt zwei neue Berechtigungen zum Ersetzen des alten:

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 übertragen, die benötigte Richtlinien konfiguriert haben.

Wenn Sie die erste Berechtigung erteilen und die zweite verweigern, kann ein Benutzer die Umgehungsoption bei Bedarf verwenden, hat aber trotzdem den Schutz vor versehentlichem Pushen an eine Verzweigung mit Richtlinien.

Hinweis

Durch diese Änderung werden keine Verhaltensänderungen eingeführt. Benutzern, denen früher Erlauben für „Von der Richtlinienerzwingung ausgenommen“ gewährt wurde, wird Erlauben für beide neuen Berechtigungen gewährt, sodass sie sowohl den Abschluss bei PRs außer Kraft setzen können als auch direkt in Zweige mit Richtlinien übertragen können.

Weitere Informationen finden Sie in der Dokumentation zu Zweigberechtigungen festlegen.

Schnelle Beschreibung von Pullanforderungen mithilfe von Commit-Nachrichten

Das Schreiben beschreibender Commit-Nachrichten fügt dem Verlauf eines beliebigen Git-Repositorys einen Mehrwert hinzu. Um Qualitäts-Commit-Nachrichten zu fördern, müssen Mitwirkende bei neuen Pullanforderungen (PR) mit mehreren Commits den Titel manuell eingeben.

Pull-Request-Beschreibungen bleiben standardmäßig leer, aber eine neue Funktion erleichtert das Einfügen der Commit-Nachrichten aus den Pull-Request-Commits in die Pull-Request-Beschreibung. Wenn Sie die Commit-Nachrichten hinzufügen möchten, klicken Sie einfach auf "Commit-Nachrichten hinzufügen", um die Commit-Nachrichten am Ende des PR-Beschreibungstexts anzufügen.

Erstellen von Pull-Anfragen ohne ein Standardteam als Reviewer

Als wir die Pull request (PR)-Erfahrung zum ersten Mal gestartet haben, dachten wir, dass es sinnvoll wäre, alle PRs dem Teamkontext zuzuweisen, den Sie beim Erstellen der PR ausgewählt haben. Dieses Verhalten ist ein Frustpunkt, da viele Personen die Verbindung zwischen dem Teamkontext und der PR-Aufgabe nicht bemerkt haben.

Im Rahmen der neuen Navigationsänderungen haben wir die Möglichkeit genommen, diese Standardzuordnung mit Teams zu ändern. Sie werden zwei Änderungen bemerken:

1. Beim Erstellen einer PR werden standardmäßig keine Reviewer hinzugefügt. Die Prüferliste verfügt über ein Feature, um das Hinzufügen von Personen und Gruppen zu erleichtern, 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 Hub für Pullanforderungen verfügt über einen neuen anpassbaren Abschnitt. In diesem Abschnitt werden standardmäßig PRs "Zugewiesen an meine Teams" angezeigt, die gleichwertige Funktionen wie der alte Abschnitt bereitstellen. Wenn Sie jedoch mehreren Teams angehören, werden in diesem Abschnitt PRs angezeigt, die einem Ihrer Teams zugewiesen sind. Der Abschnitt kann auch angepasst werden. Klicken Sie einfach auf die Aktion "Diese Ansicht anpassen" in der Nähe der Abschnittsüberschrift.

Standardisieren von Pullanforderungsbeschreibungen 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. Sie sind auch eine hervorragende Möglichkeit, um Dinge nachzuverfolgen, die für jede Änderung durchgeführt werden sollten, wie beispielsweise Tests, das Hinzufügen von Komponententests und das Aktualisieren der Dokumentation. Viele von Ihnen haben angefordert, dass wir Pull-Anforderungsvorlagen 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.

Verzweigungsspezifische Vorlagen werden auch unterstützt, wenn Sie eine andere Vorlage für eine PR auf eine bestimmte Verzweigung oder einen Verzweigungsordner anwenden möchten. Wenn Sie beispielsweise eine für alle Verzweigungen spezifische Vorlage haben möchten, die mit "hotfix/" beginnen, können Sie eine Vorlage hinzufügen, die für alle PRs in diesen Verzweigungen verwendet wird.

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

Ändern des Zielzweigs einer Pull-Anfrage

Für die meisten Teams zielen fast alle Pullanforderungen auf denselben Branch, wie main oder develop. Wenn Sie jedoch auf eine andere Verzweigung abzielen müssen, ist es einfach zu vergessen, die Zielverzweigung von der Standardeinstellung zu ändern. Mit dem neuen Feature zum Ändern des Zielzweigs einer aktiven Pullanforderung ist dies jetzt eine einfache Aktion. Klicken Sie einfach auf das Bleistiftsymbol in der Nähe des Zielzweignamens im Pull-Request-Header.

Das Feature zum Ändern von Zielverzweigungen ermöglicht es nicht nur, eine Pull Request zu "retargetieren", sondern erleichtert auch das Korrigieren von Fehlern, wenn die Zielverzweigung zusammengeführt oder gelöscht wurde. Ziehen Sie ein Szenario in Betracht, in dem Sie eine PR für eine Featurebranch haben, die einige Features enthält, von denen Ihre Änderungen abhängig sind. Sie möchten ihre abhängigen Änderungen isoliert von anderen Änderungen in der Featurebranch überprüfen, sodass Sie zunächst darauf abzielenfeatures/new-feature. Prüfer können dann nur Ihre Änderungen sehen und die entsprechenden Kommentare hinterlassen.

Überlegen Sie nun, was passiert, wenn der Feature-Branch auch eine PR aktiv hat und vor Ihren Änderungen in main zusammengeführt wurde? Zuvor hätten Sie Ihre Änderungen aufgeben und eine neue PR in main erstellen müssen, oder Ihre PR in features/new-feature zusammenführen und dann eine weitere PR von features/new-feature nach main erstellen müssen. Mit dieser neuen Aktion zur Aktualisierung des Zielzweigs können Sie einfach den Zielzweig des Pull Requests von features/new-feature zu main ändern und dabei den gesamten Kontext und die Kommentare beibehalten. Durch das Ändern der Ziel-Verzweigung wird sogar ein neues Update für die PR erstellt, wodurch es einfach ist, vor der Änderung der Zielzweigung vorherige Diffs zu betrachten.

Erweiterungsentwickler können den Kontext des aktuellen Repositorys abfragen.

Eine der Herausforderungen für einen Autor einer Versionssteuerungserweiterung 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 erweiterungsgeschützten Dienst hinzugefügt. Dadurch kann ein Erweiterungsautor Informationen zum aktuellen Git-Repositorykontext in der Web-UI 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 ist oder außerhalb der Azure Repos-Seiten auf den Dienst zugegriffen wird, wird NULL zurückgegeben.

Hier ist eine Beispielerweiterung, die diesen Dienst verwendet.

Pipelines

Verwalten von Buildpipelines mithilfe der neuen Builds-Seite

Wir führen mehrere Verbesserungen durch und führen eine neue Version der Builds-Seite aus. Diese neue Version kombiniert das Verzeichnis aller Buildpipelinen und die Liste der aktuellen Builds, sodass Sie schnell in den Builds Ihres Projekts navigieren können, um deren Status anzuzeigen. Außerdem enthält sie eine Vorschau der Testanalysen für die ausgewählte Pipeline.

Optimieren Sie Abschluss-E-Mails für Builds und Bereitstellungen durch eine verbesserte Formatierung.

E-Mails zum Abschluss von Builds und Bereitstellungen wurden aktualisiert, sodass sie besser anhand von E-Mail-Regeln gefiltert werden können. Jetzt enthält die Betreffzeile relevantere Informationen auf einen Blick, der Textkörper enthält weitere Details, und ihre Formatierung 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

Folgen Sie der neuen einheitlichen Terminologie von Azure Pipelines.

In allen Builds und Versionen wurden unterschiedliche Begriffe historisch für ähnliche Konzepte verwendet. In anderen Fällen waren Die Bedeutungen von Begriffen vage. Geben Sie beispielsweise den Unterschied zwischen einem Agentpool und einer Agentwarteschlange an.

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

Vorheriger Begriff	Einheitlicher Ausdruck	Bedeutung
Gehosteter Agent	Von Microsoft gehosteter Agent	Ein Build-/Release-Agent, der auf von Microsoft verwalteten cloudgehosteten Infrastruktur ausgeführt wird.
Privater Agent	Eigengehosteter Agent	Ein Build-/Release-Agent, der auf einem computer ausgeführt wird, der von Ihnen bereitgestellt und verwaltet wird.
Agentpool	Agentpool	Eine Gruppe von Agentcomputern auf Organisationsebene, die Builds oder Versionen ausführen können.
Agent-Warteschlange	Agentpool	Eine Gruppe von Agentcomputern auf Projektebene, die Builds oder Versionen ausführen können. Sie ist mit einem Agentpool auf Organisationsebene verknüpft.
Builddefinition	Build-Pipeline	Eine End-to-End-Gruppe von Buildschritten für eine Anwendung.
Entwickeln	Bauen	Eine Instanz einer Buildpipeline, die ausgeführt wird oder wurde.
Phase	Arbeit	Eine Reihe von Aufgaben, die sequenziell oder parallel auf einem Agent ausgeführt werden. Eine Build- oder Release-Pipeline kann einen Auftrag oder einen Graphen mehrerer Aufträge enthalten.
Freigabedefinition	Release-Pipeline	Eine End-to-End-Gruppe von Veröffentlichungsschritten für eine Anwendung, die über verschiedene Stufen hinweg bereitgestellt werden soll.
Veröffentlichung	Freigabe	Eine Instanz einer Releasepipeline, die läuft oder gelaufen ist.
Umwelt	Phase	Eine logische und unabhängige Entität, die angibt, wo Sie eine aus einer Releasepipeline generierte Version bereitstellen möchten.
Gleichzeitiger Job/Pipeline	Paralleler Auftrag	Ein paralleler Auftrag bietet Ihnen die Möglichkeit, einen einzelnen Build- oder Releaseauftrag gleichzeitig in Ihrer Organisation auszuführen. Mit mehr parallelen Aufträgen können Sie gleichzeitig weitere Build- und Releaseaufträge ausführen.
Dienstendpunkt	Dienstverbindung	Eine Gruppe von Einstellungen, z. B. Anmeldeinformationen, die zum Herstellen einer Verbindung mit externen Diensten verwendet werden, um Aufgaben in einem Build oder release auszuführen.

Weitere Informationen finden Sie in der Dokumentation zu Konzepten .

Verwalten Sie Release-Pipelines auf der neuen Seite "Releases"

Eine neue und vollständig überarbeitete Benutzeroberfläche steht für die Release-Startseite zur Verfügung. Sehen Sie sich auf der linken Seite eine Liste der Releasepipelines an, die Sie häufig veröffentlichen. Sie können Ihre Pipelines auch durchsuchen und sie als Favorit festlegen.

Ändern Sie die Ordneransicht, um Ordner für Organisation und Sicherheit zu erstellen. Sicherheit kann auf Ordnerebene festgelegt werden.

Visualisieren des Releasefortschritts

Die neue Ansicht "Versionsfortschritt" bietet Ihnen Liveupdates des Bereitstellungsfortschritts und mit nur einem Klick Zugriff auf weitere Details. Die neue Ansicht visualisiert die Release-Pipeline, sodass Sie leichter verstehen können, was passiert und welche relevanten Details und Aktionen in den verschiedenen Phasen des Releases angezeigt werden.

Pipeline, Versionsdetails und Umgebungen

Die Pipeline-Ansicht zeigt die Artefakte des Releases und die Umgebungen an, in denen sie bereitgestellt werden. Der Bereich "Release" enthält Versionsdetails wie den Releasetrigger, Artefaktversionen und Tags.

Umgebungen werden auf eine Weise modelliert, um ihren Status zusammen mit detaillierten Fortschritten zu verstehen. Sie können jederzeit zu den Protokollen gelangen, indem Sie in der Umgebung auf den Statuslink 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 Symbol für den Zustand der Umgebung klicken, das sich an der rechten oder linken Seite der Umgebung befindet.

Commits und Arbeitsaufgaben

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 zu finden, das Sie interessiert.

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-Dateikopierdienst und PowerShell auf dem Zielcomputer

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

• Sie müssen zur Taskversion 2.* der 'Windows-Computerdateikopie' wechseln und den vollständigen FQDN für den Zielcomputer anstelle des Computernamens angeben.
• Wechseln Sie zur Taskversion 2.* oder höher von "Powershell auf Zielcomputer" und geben Sie den vollständigen FQDN des Computers oder den Computernamen, 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, um Erweiterungen zu ermöglichen, um noch mehr Informationen für eine Umgebung anzuzeigen. Weitere Informationen finden Sie in der Dokumentation zu Beiträgen und Erweiterungen .

Konfigurieren von Builds mithilfe von YAML

YaML-basierte Buildpipelines sind in Ihrem Azure DevOps Server verfügbar. Automatisieren Sie Ihre fortlaufende Integrationspipeline mithilfe einer YAML-Datei, die in Ihr Repository eingecheckt ist. 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 neuen Ressourcen geändert, die Sie erstellen (z. B. Dienstverbindungen, Variablengruppen, Agentpools und sichere Dateien), damit sie in allen Pipelines dieses Projekts verwendet werden können. 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 mit Berechtigungen für die Verwendung der Ressource 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 Upstreambuild erstellt werden, können im späteren Build heruntergeladen und verwendet werden, und Sie können auch Daten aus diesen Variablen abrufen: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Weitere Informationen finden Sie in der Dokumentation zu Buildtriggern .

Denken Sie daran, dass in einigen Fällen ein einzelner mehrstufiger Build Ihre Anforderungen erfüllen könnte. Ein Buildabschlusstrigger ist jedoch nützlich, wenn Ihre Anforderungen verschiedene Konfigurationseinstellungen oder Optionen oder ein anderes Team enthalten, um den abhängigen Prozess zu steuern.

Lokal aktualisieren Sie Ihren Agent

Aufgaben, die Sie aus der Galerie installieren, erfordern gelegentlich eine neuere Version des Pipelines-Agents. Wenn Ihr Azure DevOps Server eine Verbindung mit dem Internet herstellen kann, werden neuere Versionen automatisch heruntergeladen. Wenn nicht, müssen Sie jeden Agent manuell aktualisieren. Ab dieser Version können Sie Ihren Azure DevOps-Server so konfigurieren, dass sie die Agent-Paketdateien auf dem lokalen Datenträger und nicht im Internet suchen. Dadurch können Sie sowohl flexibel sein als auch steuern, welche Agentversionen Sie zur Verfügung stellen, ohne Ihren Azure DevOps Server für das Internet verfügbar zu machen.

Neue Build-Status-Abzeichen-URL

Build-Badges, die in die Startseite eines Repositories eingebettet sind, sind eine gängige Methode, um die Gesundheit des Repositories anzuzeigen. Obwohl wir bisher Build-Badges hatten, gab es ein paar Probleme:

• Die URL war nicht intuitiv
• Das Abzeichen war nicht für eine Abteilung spezifisch.
• Es gab keine Möglichkeit, dass ein Benutzer auf das Signal klickt, um den Benutzer zum neuesten Build dieser Definition zu bringen.

Wir führen nun eine neue API für Build-Badges aus, die diese Probleme lösen. Mit der neuen API können Benutzer einen Status pro Zweig veröffentlichen und sie zum neuesten Build der ausgewählten Verzweigung führen. Sie können das Markdown für die neue Statusplaketten-URL abrufen, indem Sie die Menüaktion Statusplakette auf der neuen Builds-Seite auswählen.

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

Fügen Sie benutzerdefinierte Buildzähler zu Ihren Builds hinzu

Buildzähler bieten eine Möglichkeit, Builds eindeutig zu nummerieren und zu kennzeichnen. Zuvor konnten Sie die spezielle Variable $(rev:r) verwenden, um dies zu erreichen. Jetzt können Sie ihre eigenen Zählervariablen in Ihrer Builddefinition definieren, die jedes Mal automatisch erhöht werden, wenn Sie einen Build ausführen. Dies erfolgt auf der Registerkarte "Variablen" einer Definition. Diese neue Funktion gibt Ihnen mehr Handlungsmöglichkeiten auf folgende Weise:

• Sie können einen benutzerdefinierten Zähler definieren und dessen Ausgangswert festlegen. Sie können z. B. ihren Zähler bei 100 starten. $(rev:r) beginnt immer bei 0.
• Sie können ihre eigene benutzerdefinierte Logik verwenden, um einen Zähler zurückzusetzen. $(rev:r) ist an die Erstellung der Build-Nummern gebunden und wird automatisch zurückgesetzt, wenn in der Build-Nummer ein neues Präfix vorhanden ist.
• Sie können mehrere Indikatoren pro Definition definieren.
• Sie können den Wert eines Zählers außerhalb eines Builds abfragen. Beispielsweise können Sie die Anzahl der Builds zählen, die seit dem letzten Zurücksetzen mit einem Zähler ausgeführt wurden.

Weitere Informationen zu Build-Zählern finden Sie in der Dokumentation zu benutzerdefinierten Variablen.

Azure Policy compliance and security validations in Pipelines (Azure Policy-Konformitäts- und Sicherheitsüberprüfungen in Pipelines)

Wir wollen die Stabilität und Sicherheit der Software frühzeitig im Entwicklungsprozess sicherstellen und gleichzeitig Entwicklung, Sicherheit und Betrieb zusammenbringen. Dazu haben wir Unterstützung für Azure-Richtlinie 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-Richtlinie verwenden, bleiben Ressourcen mit Ihren Unternehmensstandards und Servicelevelvereinbarungen kompatibel.

Um die Einhaltung von Compliance- und Sicherheitsrichtlinien im Rahmen des Veröffentlichungsprozesses sicherzustellen, haben wir unsere Bereitstellungserfahrung für Azure-Ressourcengruppen optimiert. Jetzt schlagen wir die Azure Resource Group-Bereitstellungsaufgabe mit relevanten richtlinienbezogenen Fehlern bei Verstößen bei der Bereitstellung von ARM-Vorlagen fehl.

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

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

Der Open-Source- und plattformübergreifende Agent für Azure Pipelines wurde seit jeher auf 64-Bit (x64) Windows, macOS und Linux unterstützt. Mit dieser Version 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 aufzubauen.

Verbesserte Erfahrungen für Tests in Pipelines

Die Registerkarte "Tests" verfügt jetzt über eine moderne Benutzeroberfläche, die Ihnen umfassende, kontextbezogene Testinformationen für Pipelines bietet. Die neue Oberfläche bietet eine Testansicht in Echtzeit, ein umfassendes Debugging auf ganzer Seite, Testverlauf im Kontext, Berichte über abgebrochene Testausführungen und eine Laufstandszusammenfassung.

Anzeigen der Ausführung laufender Tests

Tests wie Integrations- und Funktionstests können lange ausgeführt werden, sodass es wichtig ist, die Testausführung zu einem bestimmten Zeitpunkt zu sehen. Mit der In-Progress-Testansicht müssen Sie nicht mehr warten, bis die Testausführung abgeschlossen ist, um das Testergebnis zu kennen. Ergebnisse stehen in nahezu Echtzeit zur Verfügung, während sie ausgeführt werden, sodass Sie schneller Maßnahmen ergreifen können. Sie können einen Fehler debuggen oder abbrechen, einen Fehler ablegen oder die Pipeline abbrechen. Das Feature ist derzeit sowohl für die Build- als auch für die Freigabepipeline mit VS Test Task in der Mehr-Agent-Phase verfügbar, mithilfe der Aufgabe zum Veröffentlichen von Testergebnissen oder durch das Veröffentlichen von Testergebnissen mithilfe von APIs. In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Die folgende Ansicht zeigt die Zwischenergebnisse der Tests in der neuen Fortschrittsansicht der Version, einschließlich der Gesamtzahl der Tests und der Anzahl der Testfehler zu einem bestimmten Zeitpunkt.

Wenn Sie oben auf die In-Progress Test-Zusammenfassung klicken, können Sie die detaillierte Testzusammenfassung zusammen mit fehlgeschlagenen oder abgebrochenen Testinformationen in Testplänen anzeigen. Die Testzusammenfassung wird in einem regelmäßigen Intervall aktualisiert, wobei die Detailansicht bei Bedarf aktualisiert werden kann, basierend auf der Verfügbarkeit neuer Ergebnisse.

Anzeigen von Testausführungs-Debugging-Details in voller Seite

Fehlermeldungen und Stapelspuren sind ausführlich und benötigen ausreichend Platz, um die Details während des Debuggings anzuzeigen. Um eine immersive Debugging-Erfahrung zu erzielen, können Sie jetzt die Test- oder Testausführungsansicht auf die Vollbildansicht erweitern, während Sie weiterhin die erforderlichen Vorgänge im Kontext ausführen, wie zum Beispiel Fehler erstellen oder Anforderungen für das aktuelle Testergebnis zuordnen können.

Anzeigen des Testverlaufs im Kontext

In der Vergangenheit müssten Teams zum Runs-Hub wechseln, um den Verlauf eines Testergebnisses anzuzeigen. Mit der neuen Erfahrung bringen wir den Testverlauf direkt im Kontext in die Registerkarte "Testpläne" für Build und Release. Die Testverlaufsinformationen werden schrittweise bereitgestellt, beginnend mit der aktuellen Build-Definition oder Umgebung für den ausgewählten Test, gefolgt von anderen Zweigen und Umgebungen für den Build bzw. die Freigabe.

Anzeigen abgebrochener Tests

Die Testausführung kann aus mehreren Gründen abgebrochen werden, z. B. fehlerhafter Testcode, Quelle unter Test und Umweltproblemen. Unabhängig vom Grund für den Abbruch ist es wichtig, dass Sie das Verhalten diagnostizieren und die Ursache identifizieren. Sie können nun die abgebrochenen Tests und Testläufe zusammen mit den abgeschlossenen Läufen in Testplänen anzeigen. Das Feature ist derzeit sowohl für build- als auch für die Releasepipeline mit VS Test Task in der Mehr-Agent-Phase oder für die Veröffentlichung von Testergebnissen mit API(n) verfügbar. In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Nachverfolgbarkeit von Tests und Freigabeumgebungen in der Testhistorie unterstützen

Wir fügen Unterstützung für die Anzeige des Verlaufs eines automatisierten Tests hinzu, gruppiert nach verschiedenen Releaseumgebungen, in denen der Test ausgeführt wird. Wenn Sie Releaseumgebungen als Releasepipelines oder Testumgebungen modellieren und Tests in solchen Umgebungen ausführen, können Sie herausfinden, ob ein Test in der Entwicklungsumgebung bestanden, aber in der Integrationsumgebung fehlschlägt. Sie könnten herausfinden, ob es im englischen Gebietsschema funktioniert, aber in einer Umgebung im türkischen Gebietsschema fehlschlägt. Für jede Umgebung finden Sie den Status des neuesten Testergebnisses, und wenn der Test in dieser Umgebung fehlgeschlagen ist, finden Sie auch die Version, seit der der Test fehlgeschlagen ist.

Ü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 sortierten Kombination anderer Tests bestehen (z. B. sortierter Test), oder Tests mit unterschiedlichen Instanzen basierend auf bereitgestelltem Eingabeparameter (datengesteuerte Tests). Da diese Tests miteinander verbunden sind, müssen sie zusammen mit dem Gesamtergebnis erfasst werden, das auf den einzelnen Testergebnissen basiert. Mit diesem Update stellen wir eine verbesserte Version von Testergebnissen vor, die als Hierarchie auf der Registerkarte "Tests " auf einer Version dargestellt werden. Betrachten wir dazu ein Beispiel.

Früher haben wir die Möglichkeit eingeführt, fehlgeschlagene Tests in der VS Test-Aufgabe erneut auszuführen. Wir haben jedoch nur über den letzten Versuch eines Tests berichtet, was die Nützlichkeit dieses Features etwas eingeschränkt hat. Wir haben dieses Feature nun erweitert, um jede Instanz 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 Laufe der Zeit und die Verbesserung der Testmaterialien sind entscheidende Maßnahmen zur Aufrechterhaltung einer gesunden Pipeline. Das Testanalysefeature bietet nahezu echtzeitbezogene Einblicke in Ihre Testdaten für Builds und Releasepipelinen. 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 Zweig oder Ihre Testdateien identifizieren oder einen Drilldown zu einem bestimmten Test durchführen, um Trends anzuzeigen und Qualitätsprobleme wie Instabilität (Flakiness) zu verstehen.

Betrachten Sie Testanalysen für Builds und Veröffentlichungen in der untenstehenden Vorschau.

Weitere Informationen finden Sie in unserer Dokumentation.

Vereinfachen von Definitionen mit mehreren agentlosen Aufgaben

Aufgaben in einer agentlosen Phase werden von dem Server orchestriert und ausgeführt. Agentlose Phasen erfordern keinen Agent oder keine Zielcomputer. Im Gegensatz zu Agentphasen konnte jeder agentlosen Phase in den Definitionen nur eine Aufgabe hinzugefügt werden. Dies bedeutete, dass mehrere Phasen hinzugefügt werden mussten, wenn es mehr als eine agentlose Aufgabe im Prozess gab, wodurch die Definition massenhaft wird. Wir haben diese Einschränkung entspannt, sodass Sie mehrere Aufgaben in einer agentlosen Phase verwalten können. Die Aufgaben in derselben Phase würden sequenziell ausgeführt, gerade so, wie sie es für Agentphasen tun. Weitere Informationen finden Sie in der Dokumentation zu Serverphasen .

Schrittweises Verfügbarmachen und Phasenbereitstellungen mithilfe von Freigabegaten

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

Halten Sie Bereitstellungen, bis Gates konsistent erfolgreich sind

Freigabetore ermöglichen die automatische Bewertung von Integritätskriterien, bevor eine Freigabe in die nächste Umgebung gefördert wird. Standardmäßig schreitet die Freigabe voran, nachdem eine erfolgreiche Probe für alle Gates empfangen wurde. Selbst wenn ein Tor unberechenbar ist und die empfangene erfolgreiche Probe nur Rauschen ist, wird die Freigabe fortschreiten. Um diese Arten von Problemen zu vermeiden, können Sie die Freigabe jetzt so konfigurieren, dass die Konsistenz des Zustands für eine minimale Dauer überprüft wird, bevor fortgefahren wird. Zur Laufzeit würde die Freigabe sicherstellen, dass aufeinander folgende Bewertungen der Tore erfolgreich sind, bevor die Promotion zugelassen wird. Die Gesamtzeit für die Auswertung hängt von der "Zeit zwischen der Neubewertung" ab und wäre in der Regel mehr als die konfigurierte Mindestdauer. Weitere Informationen finden Sie in der Dokumentation zur Releasebereitstellung mit Gates.

Automatische Bereitstellung an neue Ziele in einer Bereitstellungsgruppe

Früher war eine manuelle Bereitstellung erforderlich, wenn neue Ziele zu einer Bereitstellungsgruppe hinzugefügt wurden, um sicherzustellen, dass alle Ziele dieselbe Release-Version haben. Sie können jetzt die Umgebung so konfigurieren, dass die letzte erfolgreiche Version automatisch für die neuen Ziele bereitgestellt wird. Weitere Informationen finden Sie in der Dokumentation zu Bereitstellungsgruppen .

Fortlaufende Bereitstellung von Builds, die nach der Buildverarbeitung markiert sind

Fortlaufende Bereitstellungs-Trigger erstellen eine Freigabe nach Abschluss des Builds. Manchmal werden Builds jedoch nach der Verarbeitung verarbeitet, und der Build sollte erst nach Abschluss dieser Verarbeitung freigegeben werden. Jetzt können Sie Build-Tags nutzen, die während der Nachbearbeitung zugewiesen werden und in den Triggerfiltern der Freigabe verwendet werden können.

Festlegen einer Variablen zur Veröffentlichungszeit

In einer Releasedefinition können Sie nun die Variablen auswählen, die Sie beim Erstellen der Version festlegen möchten.

Der für die Variable bereitgestellte Wert, wenn die Version erstellt wird, wird nur für diese Version 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, im 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 Aufgaben Powershell, Cmd und Bash verfügbar.

Dies ermöglicht zwei Szenarien:

• Eine Aufgabe erfordert eine Umgebungsvariable, bei der die Groß-/Kleinschreibung im Variablennamen beibehalten wird. Im obigen Beispiel würde die an die Aufgabe übergebene Umgebungsvariable beispielsweise "foo" und nicht "FOO" lauten.
• Damit können geheime Werte sicher an die Skripts übergeben werden. Dies wird bevorzugt, um die geheimen Schlüssel als Argumente an die Skripts zu übergeben, da das Betriebssystem des Agents den Aufruf von Prozessen einschließlich ihrer Argumente protokollieren kann.

Variablengruppen klonen

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

Hinweis

Die werte der geheimen Variablen werden beim Klonen einer Variablengruppe nicht kopiert. Sie müssen die verschlüsselten Variablen aktualisieren und dann die geklonte Variablengruppe speichern.

Ignorieren eines Freigabegaters für eine Bereitstellung

Freigabetore ermöglichen die automatische Bewertung von Integritätskriterien, bevor eine Freigabe in die nächste Umgebung gefördert wird. Standardmäßig wird die Freigabepipeline nur ausgeführt, wenn alle Tore gleichzeitig fehlerfrei sind. In bestimmten Situationen, z. B. bei der beschleunigten Freigabe oder nach der manuellen Überprüfung des Gesundheitszustands, möchte ein Genehmiger möglicherweise eine Schranke ignorieren und die Freigabe zulassen, auch wenn diese Schranke noch nicht als fehlerfrei bewertet wurde. Bitte sehen Sie die Release Gates-Dokumentation für weitere Informationen ein.

Zusätzliche Tests durchführen mithilfe eines Pull-Request-Release-Triggers

Sie konnten schon seit einiger Zeit einen Build basierend auf einem Pull Request (PR) auslösen und dieses schnelle Feedback vor einem Merge erhalten. Jetzt können Sie auch einen PR-Trigger für eine Veröffentlichung konfigurieren. Der Status der Version wird wieder in das Code-Repository gepostet und kann direkt auf der PR-Seite angezeigt werden. Dies ist hilfreich, wenn Sie zusätzliche funktionale oder manuelle Tests als Teil Ihres PR-Workflows durchführen möchten.

Create Azure service connection with service principal that authenticates with a certificate (Erstellen einer Azure-Dienstverbindung mit einem Dienstprinzipal, der mit einem Zertifikat authentifiziert wird)

Sie können jetzt eine Azure-Dienstverbindung mit einem Dienstprinzipal und Zertifikat für die Authentifizierung definieren. Mit der Azure-Dienstverbindung, die jetzt einen Dienstprinzipal unterstützt, der sich mit einem Zertifikat authentifiziert, können Sie jetzt den Azure Stack bereitstellen, der 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.

Aus Paketen, die in Azure App Service-Bereitstellungen unterstützt werden, ausführen

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

Der App-Dienst unterstützt eine Reihe verschiedener Techniken zum Bereitstellen Ihrer Dateien wie msdeploy (auch als WebDeploy bezeichnet), Git, ARM und vieles mehr. Aber all diese Techniken haben eine Einschränkung. Ihre Dateien werden unter Ihrem Wwwroot-Ordner (insbesondere d:\home\site\wwwroot) bereitgestellt, und die Laufzeit führt dann die Dateien von dort aus aus aus.

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

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

Linux-Container mit dem App Server Deploy-Task bereitstellen

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

Das Linux-Hostingmodell für Azure Functions basiert auf Docker-Containern, die mehr Flexibilität beim Verpacken und Nutzen von appspezifischen Abhängigkeiten bieten. Funktionen unter Linux können in zwei verschiedenen Modi gehostet werden:

1. Integriertes Containerimage: Sie bringen den Funktions-App-Code mit und Azure stellt den Container bereit und verwaltet den Container (integrierten Imagemodus), sodass keine spezifischen Docker-bezogenen Kenntnisse erforderlich sind. Dies wird in der vorhandenen Version von App Service Deploy-Aufgabe unterstützt.
2. Benutzerdefiniertes Containerimage: Wir haben die Aufgabe "App Service Deploy" verbessert, 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 ein benutzerdefiniertes Image mithilfe von Azure Pipelines für Azure Function auf Linux erstellen und bereitstellen.

The Xcode task supports newly released Xcode 10 (Die Xcode-Aufgabe unterstützt das neu veröffentlichte Xcode 10)

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

Optimieren der Bereitstellung für Kubernetes mithilfe von Helm

Helm ist ein Tool, das die Installation und Verwaltung von Kubernetes-Anwendungen optimiert. Es hat auch im letzten Jahr eine Menge Popularität und Community-Unterstützung gewonnen. Eine Helmaufgabe in Release ist jetzt für das Packen und Bereitstellen von Helmdiagrammen in Azure Container Service (AKS) oder einem beliebigen anderen Kubernetes-Cluster verfügbar.

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

Steuerung der in der Release verwendeten Helm-Version

Die Aufgabe "Helm Tool Installer " erwirbt eine bestimmte Version von Helm aus dem Internet oder den Tools-Cache und fügt sie dem PFAD des Agents (gehostet oder privat) hinzu. Verwenden Sie diese Aufgabe, um die Version von Helm zu ändern, die in nachfolgenden Aufgaben wie der .NET Core Cli-Aufgabe verwendet wird. Durch Hinzufügen dieser Aufgabe vor der Aufgabe "Helm Deploy " in einer Build- oder Releasedefinition wird sichergestellt, dass Sie Ihre App mit der richtigen Helm-Version packen und bereitstellen. Diese Aufgabe hilft auch bei der optionalen Installation des Kubectl-Tools , was eine Voraussetzung dafür ist, dass Helm funktioniert.

Fortlaufende Bereitstellung in die Azure Database für MySQL

Sie können jetzt kontinuierlich in der Azure-Datenbank für MySQL – der MySQL-Datenbank von Azure als Dienst bereitstellen. Verwalten Sie Ihre MySQL-Skriptdateien in der Versionssteuerung und stellen Sie kontinuierlich als Teil einer Releasepipeline mithilfe einer systemeigenen Aufgabe statt mit PowerShell-Skripts bereit.

Verwenden verbesserter Windows-Remote-PowerShell-basierter Aufgaben

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

PowerShell für Zielaufgabe (Version: 3.*): Sie können Inlineskript hinzufügen, PSSession-Optionen ändern, "ErrorActionPreference" steuern und bei Standardfehlern fehlschlagen.

Azure File Copy-Aufgabe (Version: 2.*): Wird mit der neuesten AzCopy (v7.1.0) ausgeliefert, die ein GitHub-Problem behebt.

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

Wenn Sie von GitHub Enterprise oder externen Git-Repositories veröffentlichen, können Sie jetzt die spezifischen Branches konfigurieren, die veröffentlicht werden sollen. Sie können z. B. nur Builds bereitstellen, die aus einem bestimmten Branch in die Produktion kommen.

Erstellen von Anwendungen, die in Go geschrieben wurden

Verwenden Sie die Aufgabe "Go Tool Installer", um eine oder mehrere Versionen von Go Tool im Handumdrehen zu installieren. Diese Aufgabe erhält eine bestimmte Version des Go-Tools, die von Ihrem Projekt benötigt wird, und fügt sie dem PATH des Build-Agents hinzu. Wenn die zielorientierte Go-Tool-Version bereits auf dem Agent installiert ist, überspringt diese Aufgabe den Vorgang zum Herunterladen und Erneuten Installieren.

Die Go-Aufgabe hilft Ihnen beim Herunterladen von Abhängigkeiten, Erstellen oder Testen Ihrer Anwendung. Sie können diese Aufgabe auch verwenden, um einen benutzerdefinierten Go-Befehl Ihrer Wahl auszuführen.

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

Eine neue Python-Skriptaufgabe vereinfacht das Ausführen 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 als Teil Ihrer Pipeline zu speichern. Die Aufgabe verwendet die Version von Python im Pfad, oder Sie können einen absoluten Pfad zu einem Python-Interpreter angeben, der verwendet werden soll.

Nutzen Sie die verbesserte Xcode-Build-Prozess- und Testausgabe von xcpretty

xcpretty verbessert die Lesbarkeit der xcodebuild-Ausgabe und generiert Testergebnisse im JUnit-Format. Die Xcode-Buildaufgabe verwendet jetzt automatisch xcpretty, wenn sie auf dem Agentcomputer verfügbar ist, da sie sich auf gehosteten macOS-Agents befindet. Obwohl die xcpretty-Ausgabe unterschiedlich und weniger ausführlich als die xcodebuild-Ausgabe sein kann, stellen wir die vollständigen xcodebuild-Protokolle mit jedem Build zur Verfügung.

Testpläne

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

Sie können jetzt den Test Runner (Azure Test Plans)-Client verwenden, um manuelle Tests für Desktopanwendungen auszuführen. Auf diese Weise können Sie von Microsoft Test Manager zu Azure Test-Plänen wechseln. Bitte lesen Sie hier unsere Anleitungen. 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 im Fehler enthalten sind.

Test Runner (Azure Test Plans) erfordert einen einmaligen Download und die Installation des Läufers. Wählen Sie "Für Desktopanwendung ausführen" aus, wie unten dargestellt.

Artefakte

Upstream-Quellen

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

• Sie können nuget.org Upstreamquellen zu vorhandenen Feeds hinzufügen, die in früheren TFS-Versionen erstellt wurden. 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 weitere Azure DevOps Server-Feeds als Upstreamquellen 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 Mitarbeiter kann Pakete aus einer Upstreamquelle speichern, Pakete jedoch nicht direkt im Feed veröffentlichen (z. B. durch die Verwendung von nuget publish). Auf diese Weise können Sie die Paketveröffentlichung auf einen vertrauenswürdigen Benutzer oder das Buildsystem beschränken und es Ihren Technikern ermöglichen, neue Pakete aus Ihren Upstreamquellen zu verwenden.

Pakete verfolgen

Wir haben es noch einfacher gemacht, Benachrichtigungen mit einer neuen Schaltfläche "Folgen " direkt in jedem Paket einzurichten. Die Schaltfläche "Folgen " ist auch mit Freigabeansichten kompatibel. Wenn Sie einem Paket folgen, während Sie es in einer Ansicht betrachten, erhalten Sie nur Updates für neue Versionen, die in diese Ansicht höhergestuft werden.

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

Einige der Interaktionen auf der Seite "Feedeinstellungen" wurden verbessert. Jetzt werden Änderungen, die Sie vornehmen, z. B. das Hinzufügen eines Upstreams oder einer Berechtigung, sofort gespeichert. Dies bedeutet, dass Sie sich keine Sorgen machen müssen, dass Änderungen verloren gehen könnten, wenn Sie zwischen den Einstellungen hin und her wechseln.

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

Die Interaktion mit authentifizierten NuGet-Feeds ist viel besser geworden. Der neue .NET Core-basierte Azure Artifacts-Anmeldeinformationsanbieter funktioniert mit msbuild, dotnet und nuget(.exe) unter Windows, macOS und Linux. Jedes Mal, wenn Sie Pakete aus einem Azure Artifacts-Feed verwenden möchten, wird vom Credential-Provider automatisch ein Token für den NuGet-Client, den Sie verwenden, erworben und gespeichert. 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- und Veröffentlichungssymbole" aktualisiert, um komprimierende Symbole zu unterstützen, wenn sie in einer Dateifreigabe veröffentlicht werden.

Wiki

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

Entwickler erstellen Dokumentation für "APIs", "SDKs" und "Hilfedokumente zur Erläuterung von Code" in Coderepositorys. Leser müssen dann Code durchforsten, um die richtige Dokumentation zu finden. Jetzt können Sie Markdowndateien einfach aus Coderepositorys veröffentlichen und in Wiki hosten.

Beginnen Sie in Wiki, indem Sie auf "Code als Wiki veröffentlichen" klicken. Als Nächstes können Sie einen Ordner in einem Git-Repository angeben, der höhergestuft werden soll.

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

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 auf einer Wiki-Seite klicken, um eine URL direkt zu diesem Abschnitt zu generieren. Sie können diese URL dann kopieren und für Teammitglieder freigeben, um sie direkt mit diesem Abschnitt zu verknüpfen.

Anfügen von Dateien und Bildern in Ordnern

Bei der Offlinebearbeitung von Wiki-Seiten kann es einfacher sein, Dateianhänge 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 in eine Wiki-Seite aus Onlinedienste wie Microsoft Stream und YouTube 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 in der Wiki-Benutzeroberfläche umbenennen und REST-APIs verwenden. Klicken Sie im Menü "Weitere " auf "Wiki umbenennen", um Ihrem Wiki einen unvergesslichen Namen zu geben.

Seite in neuer Registerkarte öffnen

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

Beibehalten von Sonderzeichen in Wiki-Seitentiteln

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

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

Fehlerhafte Links anzeigen

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

Beheben fehlerhafter Links beim Verschieben von Seiten

Fehlerhafte Seitenlinks sind eine der führenden Ursachen für schlechte Seitenqualität in jeder Dokumentationslösung. Wenn Sie zuvor in Wiki eine Seite innerhalb der Struktur verschoben oder eine Seite umbenannt haben, könnte es möglicherweise Links zu der Seite von anderen Seiten und Arbeitsaufgaben unterbrechen. Jetzt können Sie Links überprüfen und reparieren, bevor sie kaputt gehen.

Wichtig

Denken Sie daran, die []() Markdownsyntax für Links auf Seiten und den Wiki-Seitenlinktyp in Arbeitsaufgaben zu verwenden, damit Wiki diese potenziell fehlerhaften Links finden und beheben kann. URLs und Hyperlinks im Klartext in Arbeitselementen werden von dieser Funktion nicht erkannt.

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

Sie werden dann eine Liste der betroffenen Seitenlinks und Arbeitselemente angezeigt, bevor Sie Maßnahmen ergreifen.

Inhaltsverzeichnis für Wiki-Seiten erstellen

Manchmal können Wiki-Seiten lang werden, wobei Inhalte in mehreren Überschriften organisiert sind. Jetzt können Sie ein Inhaltsverzeichnis zu einer beliebigen Seite hinzufügen, die über mindestens eine Überschrift verfügt, indem Sie die [[_TOC_]] Syntax verwenden.

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

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

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

Das Hinzufügen von Metadaten zur Dokumentation kann Lesern und Suchindizes helfen, aussagekräftige Inhalte aufzunehmen und anzuzeigen. In diesem Update werden alle Dateien, die einen YAML-Block am Anfang der Datei enthalten, in eine Metadatentabelle mit einem Kopf und einer Zeile umgewandelt. Der YAML-Block muss die Form eines gültigen YAML-Satzes zwischen dreifach gestrichelten Linien aufweisen. Es unterstützt alle grundlegenden Datentypen, Listen, Objekte 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
---

Code als Wiki mit der Berechtigung „Mitwirkender“ veröffentlichen

Früher konnten nur Benutzer mit der Berechtigung "Repository erstellen" in einem Git-Repository Code als Wiki veröffentlichen. Dadurch haben die Repositoryadministratoren oder Ersteller einen Engpass für alle Anforderungen zum Veröffentlichen von Markdowndateien gemacht, 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 Code-Repository verfügen.

Berichterstattung

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 und the Reporting Roadmap. Die Analytik befindet sich in der öffentlichen Vorschauphase. Es enthält derzeit Daten für Boards und automatisierte Testergebnisse über Pipelines. Siehe Daten, die in Analytics Service verfügbar sind.

Untersuchen Sie den Buildverlauf mithilfe eines neuen Widgets im Build-Dashboard.

Wir verfügen über ein neues und verbessertes Erstellungsverlaufs-Widget, das Sie zu Ihren Dashboards hinzufügen können. Mit diesem Widget können Sie jetzt einen Verlauf von Builds aus einer bestimmten Verzweigung auf Ihrem Dashboard anzeigen und für anonyme Besucher in einem öffentlichen Projekt konfigurieren.

Wichtig

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

---

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und über Entwicklercommunity nachverfolgen und Ratschläge zu Stack Overflow erhalten.

---

Seitenanfang