Azure DevOps Server 2019 – Versionshinweise

| Entwicklercommunity 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 die Pipeline nach dem Upgrade gelöscht wird. Pipelineausführungen, die manuell aufbewahrt oder von einer Version 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 Liste der zulässigen PowerShell-Aufgaben für die Parameterüberprüfung von Argumenten zum Aktivieren von Shellaufgabenargumenten.

Patches installieren

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 Hash
Tasks20231103.zip	389BA66EEBC3262FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Pipelineanforderungen

Um das neue Verhalten zu verwenden, muss eine 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 Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• CVE-2023-33136; 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.

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.  

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. Download and extract Tasks_20230825.zip.
2. Ändern Sie das Verzeichnis in die extrahierten Dateien.
3. Führen Sie die folgenden Befehle aus, um die Aufgaben hochzuladen:

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

Pipelineanforderungen

Um das neue Verhalten zu verwenden, muss eine 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 Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• CVE-2023-36869: Sicherheitsanfälligkeit in Azure DevOps Server für 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.

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

SHA-256 Hash: 96C7AF3E3ED67C76451BA28427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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

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

• Beheben des Fehlers der Builddefinitions-UI.

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

Installieren

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

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

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

npm install -g tfx-cli

4. Erstellen Sie ein persönliches Zugriffstoken mit Vollzugriffsberechtigungen, und kopieren Sie es. Dieses persönliche Zugriffstoken wird beim Ausführen des Befehls tfx login verwendet.

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Verwenden Sie den Pfad der extrahierten ZIP-Datei aus Schritt 1.

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

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

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

AzurePowerShellV4-Aufgabeninstallation

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 . In der Aufgabe wird nur ein Fehler beim Standardfehler angezeigt.

Installieren

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

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

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

npm install -g tfx-cli

4. Erstellen Sie ein persönliches Zugriffstoken mit Vollzugriffsberechtigungen, und kopieren Sie es. Dieses persönliche Zugriffstoken wird beim Ausführen des Befehls tfx login verwendet.

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Der Pfad des extrahierten Pakets 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 Rechteerweiterungen
• CVE 2020-0815: Sicherheitsanfälligkeit in Höhe von Rechten

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: Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Repositorys
• CVE-2019-1306: Sicherheitsrisiko durch Remotecodeausführung in Wiki

---

Azure DevOps Server 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 Dienstverbindungen Informationen 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.

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

Azure Boards

• "Die Feldkriterien für diesen Plan haben einen Fehler." beim Konfigurieren eines Plans. Wird über Entwicklercommunity gemeldet.
• apiwitcontroller.executequery löst eine Ausnahme aus, wenn eine Abfrage mehrmals dieselbe Spalte aufweist.
• Im Clientobjektmodell 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 Start-Entwurfsversionsaktion zum Erstellen einer neuen Version erstellt, aber jetzt wird die Entwurfsversion gestartet.

Azure Test Plans

• 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 Entwicklercommunity gemeldet.
• Mithilfe der Löschfall-API können Testfälle aus anderen Projekten gelöscht werden. Wird über Entwicklercommunity 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.

Analyse

• 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.
• Bei der Wartung, die veraltete Berichte verursachen kann, kann ein Halteraum für die Analysedatenaufnahme platziert werden.

Allgemein

• Linksnavigationselemente werden auf IE gedrückt, wenn nicht genügend Platz vorhanden ist.

Verwaltung

• Zusätzliche Protokollierung, die dem Sammlungsupgrade hinzugefügt wurde, 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.
• Dienst-Hooks verarbeiten möglicherweise keine ordnungsgemäßen Benachrichtigungen.
• Die Codesuche-Indizierung wird nach der Konfiguration der Suche nicht gestartet.
• 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 Visual Studio 2019-Testaufgabe in Pipelines Unterstützung für Visual Studio 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 websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) in Test Plans
• CVE-2019-0971: Sicherheitsrisiko bei der Veröffentlichung von Informationen in der Repos-API
• CVE-2019-0979: Sicherheitsrisiko beim websiteübergreifenden Erstellen von Skripts (Cross-Site Scripting, XSS) im Benutzerhub

---

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

---

RC2 Veröffentlichungsdatum: 22. Januar 2019

Zusammenfassung der Neuerungen in Azure DevOps Server 2019 RC2

Wir haben rc2 die folgenden Features hinzugefügt:

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

---

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
• Verarbeiten der Vererbung für neue 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 Releasepipelines mithilfe der neuen Seite "Versionen"
• Visualisieren des Veröffentlichungsfortschritts
• Lokal aktualisieren Sie Ihren Agent
• Schrittweises Verfügbarmachen und Phasenbereitstellungen mithilfe von Freigabegaten
• 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 versionsverwaltungspipelinelizenzierung

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.

Verarbeiten der Vererbung für neue Sammlungen

Die Prozessvererbung ist jetzt für neue Sammlungen verfügbar. Benutzer müssen beim Erstellen einer neuen Sammlung eine Gewissensentscheidung über das Prozessmodell treffen. In unserer Dokumentation erfahren Sie, was das Vererbungsmodell ist und wie es sich von XML unterscheidet.

(Erweitertes Suchfeld)

Wir verstehen die Bedeutung der Suche und 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, das wir sehr freuen, ist das Flyout meiner Arbeit . 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 im Code befinden, aber dann schnell überprüfen möchten, an welcher Arbeitsaufgabe Sie als Nächstes arbeiten sollten, können Sie einfach auf das Flyout klicken und die Ihnen zugewiesenen Arbeitsaufgaben anzeigen und das nächste Element auswä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 auch einen Klick Zugriff, um weitere Pullanforderungen 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:

Boards

Verknüpfen von GitHub Enterprise-Commits und Pullanforderungen an 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 Arbeitsaufgaben

Der Hub für Arbeitsaufgaben ist unser neuer Hub, der als Zuhause Ihrer Arbeitsaufgaben dient! Hier haben Sie viele verschiedene Listenansichten Ihrer Arbeitsaufgaben, die für Sie vorgesehen 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 Sprints Hubs

Der Backlogs-Hub wurde in drei verschiedene Hubs aufgeteilt, um die Benutzererfahrung zu verbessern. Obwohl leistungsfähig, war der alte Backlogs-Hub zu viele Features. 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 die Backlogs für ein Projekt. 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 die Heimat aller Kanban-Boards für ein Projekt. Boards werden verwendet, um Status und Fluss zu kommunizieren. Karten (Arbeitsaufgaben) bewegen sich von links nach rechts über das Board durch spalten, die vom Team definiert wurden.
• Der neue Sprints-Hub ist die Heimat von Features, die zum Planen und Ausführen eines Inkrements von Arbeit 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
• Breadcrumb mit eindeutigen URLs für Ordner zum Lesezeichen wichtiger Gruppen von Abfragen
• 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.

Sprintplanungsfeatures

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

• Erstellen Sie Ihren nächsten Sprint, oder abonnieren Sie einen vorhandenen Sprintzeitplan direkt über den Sprints-Hub .
• Verwenden Sie den neuen Planungsbereich in Ihrem Backlog, um Arbeitsaufgaben in zukünftige Sprints zu ziehen und abzulegen. Der Planungsbereich enthält Sprinttermine, Arbeitsaufgabenanzahl und geplante Arbeit.
• Fügen Sie oben im Taskboard Anforderungen hinzu, oder verwenden Sie eine schnelle Erstellung, um dem oberen, unteren oder der gewünschten Reihe 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, wo Sie aufgehört haben. Dieser neue Abschnitt bietet Ihnen einen Schnellen Link direkt zum letzten (Board | Backlog | Sprint) sie waren auf.
• Favoriten Alle Ihre bevorzugten Boards, Sprints und Backlogs in allen Teams.
• Meine Tafeln, Backlogs und Sprints für Teams, zu der Sie gehören.
• Alle Eine vollständige Liste aller Boards, Backlogs und Sprints.

Menü "Neue Ansichtsoptionen"

Die neuen Hubs, einschließlich Backlogs, Boards und Sprints, verfügen über ein neues Menü "Ansichtsoptionen" . Dies ist eine neue Startseite für alle Aktionen zum Anpassen von Layout- und Seiteninhalten. Verwenden Sie Ansichtsoptionen , um zusätzliche Ansichten zu aktivieren, z. B. das Anzeigen 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 Arbeitsdetailseitediagramme 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 Kartenanmerkungen auf Standard-Backlog-Ebenentypen beschränkt und unterstützen 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.

Boardeinstellungen für Kartenanmerkungen wurden erweitert, um alle für diese Backlogebene verfügbaren Arbeitsaufgabentypen einzuschließen.

Wenn Anmerkungen für Arbeitsaufgabe aktiviert sind, ist die Anzahl dieses Arbeitsaufgabentyps auf der Karte als separate Prüfliste enthalten.

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

Verschieben von Arbeiten mit vorgeschlagenen Bereichen 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, sodass Sie schnell auf das Festlegen und Fortfahren zugreifen können.

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

Abfragearbeit im Iterationszeitplan mit +/- @CurrentIteration

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

Klären 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, aber in teamsü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 einen oder mehrere Bereichspfade zuordnen, mit denen Sie Backlogs, Boards, Pläne, sogar Dashboards auf die Arbeit für dieses Team 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 Arbeitsaufgaben in Verknüpfungs- und Erwähnungserfahrungen

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 schwierig machen, in Ihre Suchergebnisse einzugraben. 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 diese Erfahrung für Organisationen mit einer großen Anzahl von Filialen zu verbessern, werden wir eine neue Branch-Auswahl einführen. Mit der Auswahl können Sie jetzt Ihre bevorzugten Verzweigungen auswählen oder schnell nach einer Verzweigung 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 außer Kraft setzen und umgehen müssen , z. B. bei der Bereitstellung eines Hotfixes für ein Produktionsproblem in der Mitte 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 Richtlinienüberschreibungen 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 A-Pull-Anforderung wird erstellt oder aktualisiert , und wählen Sie "Richtlinienumgehung " aus der Liste der Filter aus. Ausgewählte Richtlinien wurden als Wert umgangen , und Sie werden jedes Mal benachrichtigt, wenn eine PR abgeschlossen ist, und Richtlinien werden umgangen.

Umgehung von Verzweigungsrichtlinien zulassen, ohne Pushschutz aufzugeben

Es gibt viele Szenarien, in denen Sie gelegentlich eine Verzweigungsrichtlinie umgehen müssen – eine Änderung wiederherstellen, die einen Buildunterbrechung verursacht hat, einen Hotfix in der Mitte der Nacht usw. anwenden. Zuvor haben wir eine Berechtigung ("Ausgenommen von der Richtlinienerzwingung") angeboten, um Teams bei der Verwaltung zu unterstützen, welche Benutzer beim Abschließen einer Pullanforderung Die Möglichkeit erhalten haben, Verzweigungsrichtlinien zu umgehen. Diese Berechtigung gewährte jedoch auch die Möglichkeit, direkt an die Verzweigung zu übertragen und den PR-Prozess vollständig zu umgehen.

Um diese Erfahrung zu verbessern, haben wir die alte Berechtigung geteilt, um Teams mehr Kontrolle zu bieten, die Umgehungsberechtigungen gewähren. 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 Verzweigungen übertragen, die erforderliche 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.

Weitere Informationen finden Sie in der Dokumentation zu "Verzweigungsberechtigungen 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 neue Pullanforderungen (PR) mit mehreren Commits Mitwirkende manuell einen Titel eingeben.

Pull-Anforderungsbeschreibungen sind standardmäßig weiterhin leer, aber ein neues Feature erleichtert das Integrieren der Commit-Nachrichten aus den PR-Commits in die PR-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 Pullanforderungen ohne standardteam als Prüfer

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 Bearbeiter 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. PR-Beschreibungen sind auch eine hervorragende Möglichkeit, um Dinge nachzuverfolgen, die für jede Änderung durchgeführt werden sollten, z. B. Testen, Hinzufügen von Komponententests und Aktualisieren der Dokumentation. Viele von Ihnen haben angefordert, dass wir Pull-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 .

Change the target branch of a pull request (Ändern des Zielbranches eines Pull Requests)

Für die meisten Teams zielen fast alle Pullanforderungen auf dieselbe Verzweigung ab, z main . B. 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 Pullanforderungsheader.

Das Feature zum Ändern von Zielverzweigungen erleichtert nicht nur das Korrigieren von Fehlern, wenn die Zielverzweigung zusammengeführt oder gelöscht wurde, eine Pullanforderung zu "retargetieren". 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 die Featurebranch auch eine PR aktiv hatte und vor Ihren Änderungen zusammengeführt main wurde? Zuvor müssten Sie Ihre Änderungen aufgeben und eine neue PR mainerstellen oder Ihre PR zusammenführen und dann eine weitere PR features/new-featureerstellen features/new-feature main. Mit dieser neuen Aktion zum Aktualisieren der Ziel-Verzweigung können Sie einfach den Zielzweig der PR ändern features/new-feature mainund dabei den gesamten Kontext und 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.

Kontext für das aktuelle Repository durch Erweiterungsentwickler 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.

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

Build- und Bereitstellungsabschluss-E-Mails wurden aktualisiert, um nach E-Mail-Regeln besser zu filtern. 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 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	Selbstgehosteter 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	Buildpipeline	Eine End-to-End-Gruppe von Buildschritten für eine Anwendung.
Entwickeln	Entwickeln	Eine Instanz einer Buildpipeline, die ausgeführt wird oder ausgeführt wird.
Phase	Job	Eine Reihe von Aufgaben, die sequenziell oder parallel auf einem Agent ausgeführt werden. Eine Build- oder Releasepipeline kann einen Auftrag oder ein Diagramm mehrerer Aufträge enthalten.
Releasedefinition	Releasepipeline	Eine End-to-End-Gruppe von Veröffentlichungsschritten für eine Anwendung, die über verschiedene Stufen hinweg bereitgestellt werden soll.
Release	Release	Eine Instanz einer Releasepipeline, die ausgeführt wird oder ausgeführt wird.
Environment	Phase	Eine logische und unabhängige Entität, die angibt, wo Sie eine aus einer Releasepipeline generierte Version bereitstellen möchten.
Gleichzeitiger Auftrag/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 von Releasepipelines mithilfe der neuen Seite "Versionen"

Eine neue und vollständig überarbeitete Benutzeroberfläche steht für die Release-Startseite zur Verfügung. Sehen Sie sich eine Liste der Releasepipelines an, die Sie häufig auf der linken Seite freigeben. 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 Releasepipeline, sodass Sie leichter verstehen können, was passiert und welche Details und Aktionen in verschiedenen Phasen der Version angezeigt werden.

Pipeline, Versionsdetails und Umgebungen

In der Pipelineansicht werden die Artefakte der Version und der Umgebungen angezeigt, 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 Bedingungssymbol der Umgebung klicken, das von der rechten oder linken Seite der Umgebung hängt.

Commits und Arbeitselemente

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

Bereitstellungsstatus und -protokolle

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

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

Auswirkungen des Upgrades auf Azure DevOps Server 2019 auf Aufgaben: Windows Machine File Copy and PoweShell on Target Machine

Computergruppen unter Test Hub wurden in TFS 2017 RTM veraltet . 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 "PowerShell auf Zielcomputern" (TaskVersion 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 zu "Powershell auf Zielcomputer", und geben Sie den vollständigen Fqdn des Computers oder des Computernamens gefolgt von den Windows-Remoteverwaltungsports (http/https) an. Beispiel: targetMachine:5985 oder targetMachine:5986

Testergebnisse und Erweiterbarkeit

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

Vorhandene Erweiterungen funktionieren in dieser neuen Ansicht, und es gibt neue Erweiterbarkeitspunkte, 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 unterschiedliche Konfigurationseinstellungen, Optionen oder ein anderes Team enthalten, um den abhängigen Prozess zu besitzen.

Lokal aktualisieren Sie Ihren Agent

Aufgaben, die Sie aus dem Katalog installieren, erfordern manchmal 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 Buildstatus-Signal-URL

Build badges embedded into the homepage of a repository are a common way to show the health of the repository. Obwohl wir bisher Build-Badges hatten, gab es ein paar Probleme:

• Die URL war nicht intuitiv
• Das Signal war für eine Verzweigung nicht 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 Verzweigungsstatus veröffentlichen und benutzer zum neuesten Build der ausgewählten Verzweigung bringen. Sie können die Markdown-URL für die neue Statussignal-URL abrufen, indem Sie auf der Seite "Builds" die Menüaktion "Statussignal" auswählen.

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

Builds benutzerdefinierte Buildzähler hinzufügen

Buildzähler bieten eine Möglichkeit zum eindeutigen Erstellen von Nummern- und Bezeichnungsbuilds. 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. Dieses neue Feature bietet Ihnen folgende Möglichkeiten:

• 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 von Nummern gebunden und wird automatisch zurückgesetzt, wenn in der Buildnummer 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 Buildzä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 Compliance- und Sicherheitsrichtlinien im Rahmen des Veröffentlichungsprozesses einzuhalten, haben wir die Bereitstellung von Azure-Ressourcengruppen verbessert. 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.

Erstellen unter Linux-/ARM- und Windows-Plattformen (32 Bit)

Der Open Source-Agent für Azure Pipelines wurde immer unter 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 in Bearbeitung ausgeführte Testansicht, vollständige Seitendebuggingerfahrung, im Kontexttestverlauf, berichte über abgebrochene Testausführung und Zusammenfassung der Ausführungsebene.

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 die Freigabepipeline mit VS Test Task in der Mehr-Agent-Phase verfügbar, mithilfe der Veröffentlichung von Testergebnissen aufgabe oder veröffentlichen Testergebnisse mithilfe von API(n). In Zukunft planen wir, diese Erfahrung für die Testausführung mit einem einzelnen Agent zu erweitern.

Die folgende Ansicht zeigt die In-Progress Test-Zusammenfassung in der neuen Statusansicht der Version, die Gesamtzahl der Testergebnisse und die 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ührungsdebuggingdetails auf der ganzen Seite

Fehlermeldungen und Stapelüberwachungen sind langwierig und benötigen genügend Platz, um die Details während des Debuggings anzuzeigen. Um eine immersive Debugerfahrung zu haben, können Sie jetzt die Test- oder Testausführungsansicht auf die vollseitige Ansicht erweitern und gleichzeitig die erforderlichen in Kontextvorgängen ausführen können, z. B. Fehlererstellung oder Anforderungszuordnung für das aktuelle Testergebnis.

Anzeigen des Testverlaufs im Kontext

In der Vergangenheit müssten Teams zum Runs-Hub wechseln, um den Verlauf eines Testergebnisses anzuzeigen. Mit der neuen Oberfläche bringen wir den Testverlauf direkt im Kontext auf der Registerkarte "Testpläne " zur Erstellung und Veröffentlichung. Die Testverlaufsinformationen werden schrittweise bereitgestellt, beginnend mit der aktuellen Builddefinition oder Umgebung für den ausgewählten Test, gefolgt von anderen Verzweigungen und Umgebungen für den Build bzw. release.

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.

Unterstützung von Testablaufverfolgungs- und Freigabeumgebungen im Testverlauf

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 das englische Gebietsschema übergibt, aber in einer Umgebung mit türkischem 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 .

View test analytics in Pipelines (Anzeigen von Testanalysen in Pipelines)

Das Nachverfolgen der Testqualität im Laufe der Zeit und die Verbesserung der Testsicherheiten ist der Schlüssel 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 Ihre Verzweigung oder Testdateien identifizieren oder einen Drilldown zu einem bestimmten Test durchführen, um Trends anzuzeigen und Qualitätsprobleme wie Flakiness zu verstehen.

Sehen Sie sich Testanalysen für Builds und Veröffentlichungen an, und zeigen Sie eine Vorschau unten an:

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, genau wie für Agentphasen. 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 wird die Freigabe nach einem erfolgreichen Beispiel für alle Gates empfangen. Selbst wenn ein Tor erratisch ist und die empfangene erfolgreiche Probe Rauschen ist, wird die Freigabe vorankommen. Um diese Arten von Problemen zu vermeiden, können Sie die Version jetzt so konfigurieren, dass die Konsistenz der Integrität für eine minimale Dauer vor dem Fortschritt überprüft 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 Freigabebereitstellung mithilfe von Gates .

Automatische Bereitstellung für neue Ziele in einer Bereitstellungsgruppe

Wenn einer Bereitstellungsgruppe zuvor neue Ziele hinzugefügt wurden, war eine manuelle Bereitstellung erforderlich, um sicherzustellen, dass alle Ziele dieselbe Version aufweisen. 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 Bereitstellungstrigger erstellen eine Veröffentlichung 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 Buildtags nutzen, die während der Nachbearbeitung in den Triggerfiltern der Version zugewiesen würden.

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.

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. beim Beschleunigen einer Freigabe oder nach der manuellen Überprüfung der Integrität, möchte ein Genehmiger möglicherweise ein Tor ignorieren und die Freigabe zulassen, auch wenn dieses Gate noch nicht als fehlerfrei ausgewertet werden muss. Die Release Gates Dokumentation für weitere Informationen.

Durchführen zusätzlicher Tests mithilfe eines Pullanforderungs-Releasetriggers

Sie konnten einen Build basierend auf einer Pullanforderung (PR) auslösen und dieses schnelle Feedback vor einem Seriendruck für eine Weile 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 den Dienstprinzipal unterstützt, der sich mit einem Zertifikat authentifiziert, können Sie jetzt mit AD FS konfigurierten Azure Stack bereitstellen. 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

Die version Azure-App Service Deploy task (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 Sperrungen beim Kopieren von Dateien.
• Kann in einer Produktions-App (mit Neustart) bereitgestellt werden.
• Sie können sich sicher sein, dass die Dateien, die in Ihrer App ausgeführt werden, sicher sind.
• Verbessert die Leistung von Azure-App 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)

Coinciding with Apple es release of Xcode 10, you can now set your projects to build or be test specifically with Xcode 10. 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 ".

Steuerelement-Helmversion, die in Release verwendet wird

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 Der Azure-Datenbank 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 Verzweigungen für GitHub Enterprise- oder externe Git-Artefakte

Bei der Veröffentlichung von GitHub Enterprise oder externen Git-Repositorys können Sie jetzt die spezifischen Verzweigungen konfigurieren, die veröffentlicht werden sollen. Sie können z. B. nur Builds bereitstellen, die von einer bestimmten Verzweigung zur Produktion stammen.

Erstellen von Anwendungen, die in Go geschrieben wurden

Verwenden Sie die Aufgabe "Toolinstallationsprogramm wechseln", um eine oder mehrere Versionen von Go Tool on the fly 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 Aufgabe "Gehe zu" hilft Ihnen beim Herunterladen von Abhängigkeiten, Build 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 der verbesserten Xcode-Build- 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.

Test Plans

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.

Artifacts

Upstreamquellen

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. mithilfe der Nuget-Veröffentlichung). 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.

Folgen von Paketen

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, wenn Sie zwischen den Einstellungen pivots wechseln.

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

Die Interaktion mit authentifizierten NuGet-Feeds ist 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, erwirbt und speichert der Anmeldeinformationsanbieter automatisch ein Token im Auftrag des nuGet-Clients, den Sie verwenden. Sie müssen ein Token nicht mehr manuell in einer Konfigurationsdatei speichern und verwalten.

Um den neuen Anbieter zu erhalten, 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

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

Einbetten eines Videos in das Wiki

Jetzt können Sie Videos 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 auf einer neuen Registerkarte öffnen oder einfach STRG+links auf eine Wiki-Seite klicken, um sie auf einer neuen Registerkarte 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 "Einrichtungshandbuch" kann in Wiki erstellt werden. Die folgenden Zeichen werden in ihre UTF-8-codierten Zeichenfolgen übersetzt:

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

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 nach Links suchen und korrigieren, bevor sie unterbrochen werden.

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.

Reporting

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

Untersuchen des Buildverlaufs über ein neues Build-Dashboard-Widget

Wir verfügen über ein neues und verbessertes Buildverlaufs-Widget, das Sie 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.

---

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