Versionshinweise zu Azure DevOps Server Update 1 2019

| Entwicklercommunity Systemanforderungen | Lizenzbedingungen | DevOps Blog | SHA-1 Hashes

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

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

Das direkte Upgrade auf Azure DevOps Server 2020 wird ab Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2019 durchfü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 wird ein neues Aufbewahrungsmodell für die Pipelineausführung (Build) eingeführt, das auf Projektebeneneinstellungen basiert.

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

Lesen Sie unseren Blogbeitrag für weitere Informationen zum sicheren Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020.

Azure DevOps Server 2019 Update 1.2 Patch 8 Veröffentlichungsdatum: 12. März 2024

Datei	SHA-256 Hash
devops2019.1.2patch8.exe	67E78EA7D67A09A6EE06309614F92E6D8495DEF52FF442E4E7C7979244FAD20A

Wir haben Patch 8 für Azure DevOps Server 2019 Update 1.2 veröffentlicht, das Fehlerbehebungen für Folgendes enthält:

• Es wurde ein Problem behoben, bei dem der Proxyserver nach der Installation von Patch 7 nicht mehr funktionierte.

Azure DevOps Server 2019 Update 1.2 Patch 7 Veröffentlichungsdatum: 13. Februar 2024

Datei	SHA-256 Hash
devops2019.1.2patch7.exe	8C67C72A83C9215302BDEFB752A7C4E3F876D4D17FCFA63A02B955FCFB5455AA

Wir haben Patch 7 für Azure DevOps Server 2019 Update 1.2 veröffentlicht, das Fehlerbehebungen für Folgendes enthält:

• Ein Fehler wurde behoben, bei dem der vom Proxycacheordner belegte Speicherplatz falsch berechnet und der Ordner nicht ordnungsgemäß bereinigt wurde.
• CVE-2024-20667: Azure DevOps Server Sicherheitsanfälligkeit bezüglich Remotecodeausführung.

Azure DevOps Server 2019 Update 1.2 Patch 6 Veröffentlichungsdatum: 14. November 2023

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

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

Hinweis

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

Patches installieren

Wichtig

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

Konfigurieren von TFX

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

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019 Update 1.2 Patch 5 Veröffentlichungsdatum: 12. September 2023

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

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

Wichtig

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

Hinweis

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

Patches installieren

1. Laden Sie Azure DevOps Server 2019 Update 1.2 Patch 5 herunter, und installieren Sie es.

Aktualisieren des Azure Pipelines-Agents

1. Laden Sie den Agent von 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 selbstgehosteten Windows-Agents beschriebenen Schritte aus, um den Agent bereitzustellen.  

Hinweis

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

Konfigurieren von TFX

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

Aktualisieren von Aufgaben mithilfe von TFX

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019 Update 1.2 Patch 4 Veröffentlichungsdatum: 8. August 2023

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

• CVE-2023-36869: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Aktualisieren Sie den SSH-Dienst, um SHA2-256 und SHA2-512 zu unterstützen. Wenn Ssh-Konfigurationsdateien für die Verwendung von RSA hartcodiert sind, sollten Sie auf SHA2 aktualisieren oder den Eintrag entfernen.
• Ein Endlosschleifenfehler in CronScheduleJobExtension wurde behoben.

Azure DevOps Server 2019 Update 1.2 Patch 3 Veröffentlichungsdatum: 13. Juni 2023

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

• Es wurde ein Fehler behoben, der das Pushen von Paketen beim Upgrade von 2018 oder früher beeinträchtigt hat.

Azure DevOps Server 2019 Update 1.2 Patch 2 Veröffentlichungsdatum: 13. Dezember 2022

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

• Fehler im "Account Parallelism Sync Analytics-Auftrag" wurden behoben.

Azure DevOps Server 2019 Update 1.2 Patch 1 Veröffentlichungsdatum: 12. Juli 2022

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

• In Testausführungs-APIs war das zurückgegebene Fortsetzungstoken größer als der angegebene Wert "maxLastUpdatedDate".
• Beim Bearbeiten einer klassischen Pipeline war die Aufbewahrungsregisterkarte leer, nachdem Änderungen auf einer anderen Registerkarte verworfen wurden.

Azure DevOps Server 2019 Update 1.2 Veröffentlichungsdatum: 17. Mai 2022

Azure DevOps Server 2019 Update 1.2 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2019 Update 1.2 oder ein Upgrade von Azure DevOps Server 2019 oder Team Foundation Server 2013 oder höher direkt installieren.

Hinweis

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

Dieses Release enthält Korrekturen für Folgendes:

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

Azure DevOps Server 2019 Update 1.1 Patch 13 Veröffentlichungsdatum: 26. Januar 2022

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

• Email Benachrichtigungen wurden nicht gesendet, wenn das @mention Steuerelement in einem Arbeitselement verwendet wurde.
• Die bevorzugte E-Mail-Adresse wurde im Benutzerprofil nicht aktualisiert. Dies führte dazu, dass E-Mails an die vorherige E-Mail-Adresse gesendet wurden.
• Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.

Installationsschritte

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

Hinweis

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

1. Aktualisieren Sie den Server mit Patch 13.
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: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 Update 1.1 Patch 12 Veröffentlichungsdatum: 15. September 2021

Patch 12 für Azure DevOps Server 2019 Update 1.1 enthält Korrekturen für Folgendes.

• Korrigieren Sie das Arbeitselementmakro für Abfragen mit "Enthält Wörter". Zuvor haben Abfragen falsche Ergebnisse für Werte zurückgegeben, die einen Zeilenumbruch enthielten.
• Lokalisierungsproblem bei Layoutzuständen für benutzerdefinierte Arbeitselemente.
• Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
• Problem mit der NOTSAMEAS-Regelauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

Azure DevOps Server 2019 Update 1.1 Patch 11 Veröffentlichungsdatum: 14. September 2021

Patch 11 für Azure DevOps Server 2019 Update 1.1 enthält Korrekturen für Folgendes.

• Beheben des Problems, das in diesem Entwicklercommunity-Feedbackticket gemeldet wurde.

Azure DevOps Server 2019 Update 1.1 Patch 10 Veröffentlichungsdatum: 10. August 2021

Patch 10 für Azure DevOps Server 2019 Update 1.1 enthält Korrekturen für Folgendes.

• Beheben sie das Problem mit E-Mail-Übermittlungsaufträgen für einige Arbeitselementtypen.

Azure DevOps Server 2019 Update 1.1 Patch 9 Veröffentlichungsdatum: 15. Juni 2021

Patch 9 für Azure DevOps Server 2019 Update 1.1 enthält Korrekturen für Folgendes.

• Problem mit dem Datenimport beheben. Der Datenimport hat für Kunden mit vielen veralteten Testfällen lange gedauert. Dies war auf Verweise zurückzuführen, die die Größe der tbl_testCaseReferences Tabelle erhöht haben. Mit diesem Patch wurden Verweise auf veraltete Testfälle entfernt, um den Datenimportprozess zu beschleunigen.

Azure DevOps Server 2019 Update 1.1 Patch 8 Veröffentlichungsdatum: 13. April 2021

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

• CVE-2021-27067 : Veröffentlichung von Informationen
• Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde | Details zur Testergebnisiteration für Azure DevOps Server 2019 können nicht registriert werden.

Um Korrekturen für diesen Patch zu implementieren, müssen Sie die unten aufgeführten Schritte für die allgemeine Patchinstallation und azureResourceGroupDeploymentV2-Aufgabeninstallationen ausführen.

Allgemeine Patchinstallation

Wenn Sie über Azure DevOps Server 2019 Update 1.1 verfügen, sollten Sie Azure DevOps Server 2019 Update 1.1 Patch 8 installieren.

Überprüfen der Installation

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

• Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 ist standardmäßig installiertc:\Program Files\Azure DevOps Server 2019. Nach der Installation Azure DevOps Server 2019.1.1 Patch 8 lautet die Version 17.153.31129.2.

Installation des AzureResourceGroupDeploymentV2-Tasks

Hinweis

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

Installieren

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

2. Laden Sie Node.js 14.15.1 und npm (im Node.js Download enthalten) nach Bedarf für Ihren Computer herunter, und installieren Sie sie.

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. 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 Update 1.1 Patch 7 Releasedatum: 12. Januar 2021

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

• Testausführungsdetails zeigen keine Testschrittdetails für Testdaten an, die mithilfe der OpsHub-Migration migriert wurden
• Ausnahme beim Initialisierer für "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"
• Nicht beibehaltene Builds werden nach der Migration zu Azure DevOps Server 2020 sofort gelöscht.
• Beheben der Datenanbieter-Ausnahme

Azure DevOps Server 2019 Update 1.1 Patch 6 Veröffentlichungsdatum: 8. Dezember 2020

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

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

Wichtig

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

Allgemeine Patchinstallation

Wenn Sie über Azure DevOps Server 2019 Update 1.1 verfügen, sollten Sie Azure DevOps Server 2019 Update 1.1 Patch 6 installieren.

Überprüfen der Installation

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

• Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 ist standardmäßig installiertc:\Program Files\Azure DevOps Server 2019. Nach der Installation Azure DevOps Server 2019.1.1 Patch 6 lautet die Version 17.153.30723.5.

AzurePowerShellV4-Taskinstallation

Hinweis

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

Voraussetzungen

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

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

Installieren

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Azure DevOps Server 2019 Update 1.1 Patch 5 Veröffentlichungsdatum: 8. September 2020

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

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

Azure DevOps Server Veröffentlichungsdatum von Update 1.1 Patch 4 2019: 14. Juli 2020

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

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

Azure DevOps Server 2019 Update 1.1 Patch 3 Veröffentlichungsdatum: 9. Juni 2020

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

• CVE-2020-1327: Stellen Sie sicher, dass der Azure DevOps-Server Benutzereingaben bereinigen muss.

Azure DevOps Server 2019 Update 1.1 Patch 2 Veröffentlichungsdatum: 14. April 2020

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

• SVN-Commits lösen keine Pipeline aus

• Hinzufügen von Unterstützung für SHA2 in SSH in Azure DevOps

Azure DevOps Server 2019 Update 1.1 Patch 1 Veröffentlichungsdatum: 10. März 2020

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

• CVE-2020-0700 : Sicherheitsrisiko durch Cross-Site Scripting

• CVE-2020-0758 : Sicherheitsrisiko durch Rechteerweiterungen

• CVE 2020-0815: Sicherheitsrisiko bei Rechteerweiterungen

---

Azure DevOps Server 2019 Update 1.1 RTW Veröffentlichungsdatum: 10. Dezember 2019

Azure DevOps Server 2019 Update 1.1 ist ein Rollup von Fehlerbehebungen und Sicherheitsupdates. Es enthält alle Fixes in den patches Azure DevOps Server 2019 Update 1, die zuvor veröffentlicht wurden. Sie können Azure DevOps Server 2019 Update 1.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2019 oder Team Foundation Server 2012 oder höher durchführen.

Hinweis

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

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

Azure Boards

• Beim Erstellen eines neuen Arbeitselements aus dem Produktbacklog wird das Feld Titel nicht mit dem Standardwert in der Prozessvorlage initialisiert.
• Langsamkeit und Timeouts bei verwendung von Azure Boards.
• Der Wert Revised By ist bei Arbeitselementlinks falsch.

Azure Pipelines

• In Pipelines-Benachrichtigungen können Felder wie Dauer in einigen Gebietsschemas NULL sein.
• Der Vorlagenpfad verweist möglicherweise nicht auf eine gültige JSON-Datei in einer Pipeline, die eine Azure-Ressourcengruppenbereitstellung enthält.
• Die Seite aufbewahrungseinstellungen auf Sammlungsebene wird auf den Projekteinstellungenseiten angezeigt.

Azure Test Plans

• Das Bearbeiten von Feldern in Test Plans ist langsam.
• In einem Testfall werden beim Öffnen von Boards (im Gegensatz zu Test Plans) die Details des freigegebenen Schritts nicht geöffnet.

Allgemein

• Sammlungen werden nicht in alphabetischer Reihenfolge sortiert.

Verwaltung

• Hohe Arbeitsspeicherauslastung.
• Server mit Lastenausgleichskonfigurationen mussten ihren öffentlichen Ursprung explizit dem Registrierungseintrag AllowedOrigins hinzufügen.
• Kunden, die auf SQL Azure installieren, wird das Dialogfeld "Testversion abschließen" nicht angezeigt.
• Beim Installieren von Erweiterungen wird der Fehler "Fehlender Beitrag (ms.vss-dashboards-web.widget-sdk-version-2)" angezeigt.
• Beim Einrichten der elastischen Suche tritt ein Fehler auf: "Benutzer ist nicht autorisiert".
• Indizierungs- und Abfragefehler in der elastischen Suche beim Upgrade von TFS 2018 Update 2 oder höher.
• Der Schritt "Warehouse erstellen" schlägt beim Konfigurieren von Azure DevOps Server fehl.

Dieses Release enthält das folgende Update:

• Unterstützung für SQL Server 2019.

---

Azure DevOps Server 2019 Update 1 Patch 1 Veröffentlichungsdatum: 10. September 2019

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

• CVE-2019-1306 : Sicherheitsrisiko durch Remotecodeausführung in Wiki

---

Azure DevOps Server 2019 Update 1 Veröffentlichungsdatum: 20. August 2019

Hinweis

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

---

RC2-Veröffentlichungsdatum: 23. Juli 2019

RC2 enthält mehrere Fehlerbehebungen seit RC1 und ist die letzte geplante Vorabversion.

---

RC1-Veröffentlichungsdatum: 2. Juli 2019

Zusammenfassung der Neuerungen in Azure DevOps Server 2019 Update 1

Azure DevOps Server 2019 Update 1 führt viele neue Features ein. Einige der Highlights sind unter anderem:

• Neuer Basic-Prozess
• Abfragen der Arbeit relativ zum Beginn des Tages, der Woche, des Monats oder jahres
• Akzeptieren und Ausführen von Problemen in GitHub während der Planung in Azure Boards
• Erneutes Ausführen eines abgelaufenen Builds für automatisch abgeschlossene Pull Requests
• Neue Mergetypen zum Abschließen von Pull Requests
• Auslösen von YAML-Pipelines mit Tags
• Task Assistent zum Bearbeiten von YAML-Dateien
• Web-Editor mit IntelliSense für YAML-Pipelines
• Verwalten von GitHub-Releases mithilfe von Pipelines
• Testergebnistrend (Erweitert) Widget
• Provenienzinformationen zu Paketen
• Unterstützung für Python-Pakete
• Upstreamquellen für Maven
• Einbetten Azure Boards Abfrageergebnisse in Wiki
• Permalinks für Wiki-Seiten
• Benachrichtigungen auf Wiki-Seiten
• Analytics-Erweiterung für die Verwendung von Analytics nicht mehr erforderlich

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

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

---

Allgemein

Dunkles Design

Das dunkle Design ist ein beliebtes Feature auf Azure DevOps Services und jetzt in Azure DevOps Server verfügbar. Sie können das dunkle Design aktivieren, indem Sie im Menü unter Ihrem Avatar oben rechts auf jeder Seite Design auswählen.

Boards

Neuer Basic-Prozess

In der Vergangenheit war Agile der Standardprozess für neue Projekte und bietet einen robusten und flexiblen Satz von Arbeitselementtypen und -zuständen, die für eine Vielzahl von Projektbereitstellungsmethoden geeignet sind. Einige Teams, die mit anderen Tools besser vertraut sind oder wachsen und ein leistungsfähigeres Toolset einführen möchten, möchten schnell mit der Terminologie beginnen, mit der sie besser vertraut sind.

Der neue Basic-Prozess bietet drei Arbeitselementtypen (Epics, Issues und Tasks), um Ihre Arbeit zu planen und nachzuverfolgen. Es wird empfohlen, Probleme zu verwenden, um Dinge wie User Storys, Bugs und Features nachzuverfolgen, während Epics verwendet wird, um Probleme in größeren Arbeitseinheiten zu gruppieren. Wenn Sie Ihre Arbeit voranbringen, verschieben Sie Elemente entlang eines einfachen Zustandsworkflows von "To Do", "Doing" und "Done".

Sehen Sie sich die Dokumentation zum Nachverfolgen von Problemen und Aufgaben an, um Ihnen den Einstieg in Ihr neues Projekt zu erleichtern.

Statuswertreihenfolge im Arbeitselementformular

Zuvor wurde der Zustandswert auf dem Arbeitselementformular alphabetisch sortiert. Mit diesem Update haben wir die Reihenfolge der Zustandswerte so geändert, dass sie der Workflowreihenfolge in den Prozesseinstellungen entsprechen. Sie können auch die Reihenfolge der Zustände in jeder Kategorie in den Statusanpassungseinstellungen ändern.

Featureaktivierung ist nicht mehr verfügbar

Kunden müssen den XML-Code für jedes Projekt manuell aktualisieren, um neue Features nach dem Upgrade ihrer Sammlung zu aktivieren.

Informationen zum Aktivieren bestimmter Features finden Sie in der Dokumentation .

Organisieren von Referenzmaterialien mit umfangreicheren Arbeitselementanlagen

Durch das Anfügen von Dateien an Arbeitselemente können Sie und Ihr Team Referenzmaterialien zentralisieren, sodass sie immer in der Nähe sind, wenn Sie sie benötigen. Es ist jetzt einfacher, eine neue Anlage hinzuzufügen, indem Sie die Datei einfach an eine beliebige Stelle im Arbeitselementformular ziehen und ablegen. Sie können die Anlagen weiterhin als Liste anzeigen oder zu einer Rasteransicht wechseln, um eine Miniaturansicht anzuzeigen. Doppelklicken Sie auf die Datei, um eine Vorschau zu öffnen, und durchlaufen Sie sie, um schnell die benötigten Informationen zu finden.

Freigeben des Boards Ihres Teams mithilfe eines Badges

Die README-Datei des Repositorys ist häufig die Heimat, an die sich Ihr Projektteam wendet, um Informationen darüber zu finden, wie Sie zu Ihrer Lösung beitragen und diese verwenden können. Wie bei einem Build- oder Bereitstellungs-status in Azure Pipelines können Sie ihrer INFODATEI einen Badge für das Board Ihres Teams in Azure Boards hinzufügen. Sie können den Badge so konfigurieren, dass nur die Spalten In Bearbeitung oder alle Spalten angezeigt werden, und sogar das Badge öffentlich sichtbar machen, wenn Ihr Projekt Open Source ist.

Wenn Ihre README-Datei auf Markdown basiert, können Sie einfach das Markdown-Beispiel von der Seite status Badgeeinstellungen kopieren und in Ihre Datei einfügen.

Abfragen der Arbeit relativ zum Beginn des Tages, der Woche, des Monats oder jahres

Während teams sich häufig auf die Arbeit im Kontext des nächsten Oder basierend auf Sprintiterationen konzentrieren, ist es oft interessant, die Arbeit durch die Linse des Kalenders zu betrachten, um über alle Arbeiten zu berichten, die im letzten Monat oder im ersten Quartal des Jahres stattgefunden haben. Jetzt können Sie den folgenden neuen Satz von @StartOf Makros zusammen mit einem beliebigen datumsbasierten Feld verwenden, um basierend auf dem Anfang des Tages, der Woche, des Monats oder des Jahres abzufragen:

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Jedes dieser Makros akzeptiert auch eine neue Modifiziererzeichenfolge, mit der Sie die Daten um verschiedene Datumseinheiten verschieben können. Sie können z. B. eine Abfrage schreiben, um alle im ersten Quartal dieses Jahres abgeschlossenen Arbeitselemente zu finden, indem Sie nach Zustandsänderungsdatum >= @StartOfYear und Zustandsänderungsdatum <= @StartOfYear("+3M") abfragen. Weitere Informationen finden Sie in der Dokumentation zu Abfragemakros .

Bearbeiten und Löschen von Diskussionskommentaren

Wir freuen uns, die Verfügbarkeit einer mit hohem Votum abgestimmten Entwicklercommunity-Funktion zum Bearbeiten und Löschen von Kommentaren in der Diskussion Ihres Arbeitselements in Azure Boards bekannt geben zu können. Um Ihren Kommentar zu bearbeiten, zeigen Sie einfach auf einen Beliebigen Kommentar, den Sie besitzen, und Es werden zwei neue Schaltflächen angezeigt. Wenn Sie auf das Stiftsymbol klicken, wechseln Sie in den Bearbeitungsmodus und können einfach Ihre Bearbeitungen vornehmen und die Schaltfläche "Aktualisieren" drücken, um Ihre Bearbeitungen zu speichern.

Wenn Sie auf das Überlaufmenü klicken, wird die Option zum Löschen Ihres Kommentars angezeigt. Sobald Sie darauf klicken, werden Sie erneut aufgefordert, zu bestätigen, dass Sie diesen Kommentar löschen möchten, und der Kommentar wird gelöscht.

Sie erhalten eine vollständige Ablaufverfolgung aller bearbeiteten und gelöschten Kommentare auf der Registerkarte Verlauf des Arbeitselementformulars. Sie werden auch sehen, dass wir die Benutzeroberfläche unserer Diskussionsoberfläche aktualisiert haben, damit sie sich moderner und interaktiver anfühlt. Wir haben Blasen um Kommentare hinzugefügt, um deutlicher zu machen, wo Kommentare beginnen und enden.

Exportieren von Abfrageergebnissen in eine CSV-Datei

Sie können Abfrageergebnisse jetzt direkt aus dem Web in eine CSV-Formatdatei exportieren.

Navigieren Sie direkt aus Erwähnungen in einem GitHub-Kommentar zu Azure Boards Arbeitselementen.

Wenn Sie nun ein Arbeitselement innerhalb des Kommentars eines Problems, Pull Requests oder Commits in GitHub mithilfe der AB#{work item ID} Syntax Erwähnung, werden diese Erwähnungen zu Links, auf die Sie klicken können, um direkt zu dem erwähnten Arbeitselement zu navigieren.

Dadurch wird kein formaler Link erstellt, der das Arbeitselement in Azure Boards für jede verwandte Unterhaltung durcheinander bringt, sondern Ihrem Team die Möglichkeit bietet, etwas mehr Informationen zu Arbeitselementen bereitzustellen, während code oder ein vom Kunden gemeldetes Problem besprochen wird. Weitere Informationen finden Sie in der Azure Boards GitHub-Integrationsdokumentation.

Akzeptieren und Ausführen von Problemen in GitHub während der Planung in Azure Boards

Jetzt können Sie Arbeitselemente in Azure Boards mit verwandten Problemen in GitHub verknüpfen. Mit dieser neuen Art der Verknüpfung sind jetzt mehrere andere Szenarien möglich. Wenn Ihr Team weiterhin Fehlerberichte von Benutzern akzeptieren möchte, z. B. als Probleme innerhalb von GitHub, aber die Arbeit des Teams insgesamt in Azure Boards verknüpfen und organisieren möchte, können Sie jetzt dies tun.

Die gleiche Erwähnung Syntax, die Ihr Team für Commits und Pull Requests verwendet, gilt weiterhin, und Sie können natürlich manuell in Azure Boards mit der Issue-URL verknüpfen. Weitere Informationen finden Sie in der GitHub-& Azure Boards-Dokumentation.

Schnelles Anzeigen der verknüpften GitHub-Aktivität über das Kanban-Board

Wenn Sie das Kanban-Board selbst oder als Team überprüfen, haben Sie häufig Fragen wie "Hat dieser Artikel noch mit der Entwicklung begonnen?" oder "Ist dieser Artikel noch überprüft?" Mit den neuen GitHub-Anmerkungen auf dem Kanban-Board können Sie jetzt schnell erkennen, wo sich ein Element befindet, und direkt zum GitHub-Commit, Pull Request oder Issue navigieren, um weitere Details zu erhalten. Weitere Informationen zu diesem und den anderen Anmerkungen zu Aufgaben und Tests finden Sie in der Dokumentation zum Anpassen von Karten .

Repos

Pull Requests entwerfen

Um zu verhindern, dass Pull Requests abgeschlossen werden, bevor sie bereit sind, und um die Erstellung von laufenden Arbeiten zu vereinfachen, die möglicherweise nicht alle beteiligten, unterstützen wir jetzt Pull Requests-Entwürfe.

Entwürfe von Pull Requests können erstellt werden, indem Sie beim Erstellen eines Pull Requests in der Dropdownliste erstellen die Option Als Entwurf erstellen auswählen.

Nachdem Sie einen Pull Request-Entwurf erstellt haben, wird neben dem Titel ein Badge angezeigt, der seine status angibt.

Entwürfe von Pull Requests enthalten standardmäßig keine Prüfer oder ausführende Builds, ermöglichen ihnen jedoch das manuelle Hinzufügen von Prüfern und Ausführen von Builds. Wenn Sie den Pull Request zu einem normalen Pull Request heraufstufen möchten, klicken Sie einfach auf der Detailseite des Pull Requests auf die Schaltfläche Veröffentlichen .

Erneutes Ausführen eines abgelaufenen Builds für automatisch abgeschlossene Pull Requests

Azure Repos werden jetzt automatisch abgelaufene Builds in die Warteschlange gestellt, die durch eine Pull Request-Richtlinie ausgelöst wurden. Dies gilt für Pull Requests, die alle anderen Richtlinien übergeben haben und auf autovervollständigen festgelegt sind.

Wenn Pull Requests zuvor Richtlinien wie erforderliche Prüfer enthielten, konnte der Genehmigungsprozess zu lange dauern, und ein zugeordneter Build konnte ablaufen, bevor ein Prüfer den Pull Request genehmigte. Wenn für den Pull Request die Automatische Vervollständigung festgelegt wurde, bleibt er blockiert, bis ein Benutzer den abgelaufenen Build manuell in die Warteschlange gestellt hat. Mit dieser Änderung wird der Build automatisch in die Warteschlange gestellt, sodass der Pull Request nach einem erfolgreichen Build automatisch abgeschlossen werden kann.

Hinweis

Diese Automatisierung führt nur bis zu fünf abgelaufene Builds pro Pull Request in die Warteschlange und versucht nur einmal, jeden Build erneut in die Warteschlange zu stellen.

Anzeigen der linken oder rechten Datei in einem Pull Request

Beim Anzeigen von Dateiänderungen in einem Pull Request können Sie heute entweder einen parallelen diff- oder Inlinemodus diff verwenden. Wir haben Feedback erhalten, dass viele von Ihnen nur die ursprüngliche Datei oder die geänderte Datei sehen möchten, ohne sie zu vergleichen. Daher haben wir eine neue Option hinzugefügt, mit der Sie entweder die linke Oder die rechte Datei einzeln anzeigen können.

Neue Mergetypen zum Abschließen von Pull Requests

Sie haben jetzt mehr Optionen beim Zusammenführen der Änderungen von einem Pull Request mit dem Zielbranch. Wir haben Unterstützung für zwei unserer am häufigsten angeforderten Features auf der Entwicklercommunity hinzugefügt: Fast-Forward-Merger und Semilineare Zusammenführung (auch als "Rebase and Merge" bezeichnet).

Diese neuen Optionen werden nun im Dialogfeld Pull Request abschließen angezeigt:

Auf der aktualisierten Richtlinienverwaltungsseite können Administratoren steuern, welche Mergestrategien für einen Branch oder Ordner von Branches zulässig sind.

Hinweis

Vorhandene Richtlinien werden weiterhin erzwungen. Wenn Ihr Branch beispielsweise derzeit über eine Richtlinie "squashen merge only" verfügt, müssen Sie diese Richtlinie bearbeiten, um die neuen Mergestrategien zu verwenden.

Es gibt einige Situationen, in denen eine Neubasierung während der Vervollständigung von Pull Requests nicht möglich ist:

• Wenn eine Richtlinie für den Zielbranch die Verwendung von Rebasestrategien untersagt, benötigen Sie die Berechtigung "Branchrichtlinien außer Kraft setzen".
• Wenn der Quellbranch des Pull Requests Richtlinien enthält, können Sie ihn nicht neu erstellen. Durch das erneuteBasieren wird der Quellbranch geändert, ohne den Richtliniengenehmigungsprozess zu durchlaufen.
• Wenn Sie die Mergekonflikterweiterung verwendet haben, um Mergekonflikte zu lösen. Konfliktlösungen, die auf eine Drei-Wege-Zusammenführung angewendet werden, sind selten erfolgreich (oder sogar gültig), wenn alle Commits in einem Pull Request einzeln neu zugeordnet werden.

In all diesen Fällen haben Sie weiterhin die Möglichkeit, Ihren Branch lokal zu speichern und auf den Server zu pushen, oder squashen Sie Ihre Änderungen beim Abschließen des Pull Requests zusammenführen.

Filtern nach Zielbranch in Pull Requests (PRs)

Pull Requests ermöglichen es Ihrem Team, Code zu überprüfen und Feedback zu Änderungen zu geben, bevor sie in den Standard-Branch zusammengeführt werden. Sie sind zu einem wichtigen Bestandteil der Workflows vieler Teams geworden, da Sie die vorgeschlagenen Änderungen schrittweise durchlaufen, Kommentare hinterlassen und abstimmen können, um Codeänderungen zu genehmigen oder abzulehnen.

Damit Sie Ihre Pull Requests leichter finden können, haben wir eine Filteroption hinzugefügt, mit der Sie mithilfe des Zielbranchs nach PRs suchen können.

Sie können auch die Zielbranchfilterung verwenden, um die Pull Requests-Ansicht auf der Registerkarte Mine anzupassen.

Hinzufügen von Syntaxhighlighting und Autovervollständigen durch Erweiterungen zulassen

Derzeit veröffentlichen wir Syntaxheraushebungen für eine Teilmenge von Sprachen, die vom Monaco-Editor unterstützt werden. Viele von Ihnen möchten jedoch Ihre eigene Syntaxmarkierung für Sprachen erstellen, die nicht unterstützt werden.

Mit diesem Update haben wir einen Erweiterbarkeitspunkt hinzugefügt, der es Erweiterungen ermöglicht, Dem Datei-Explorer und Pull Requests-Ansichten Syntax-Hervorhebung und Automatische Vervollständigung hinzuzufügen.

Ein Beispiel für eine Erweiterung, die dieses Feature veranschaulicht, finden Sie hier.

Darüber hinaus haben wir Unterstützung für die Hervorhebung der Kusto-Sprachsyntax hinzugefügt.

Erweiterungspunkt für die Repositoryerstellung

Wir haben einen Erweiterungspunkt hinzugefügt, mit dem Sie der Repositoryauswahl neue Elemente hinzufügen können. Mit diesem Erweiterungspunkt können Sie benutzerdefinierte Aktionen (Umleitungen, Popups usw.) zum Menü der Repositoryauswahl hinzufügen, wodurch Flows wie alternative Repositoryerstellungsszenarien aktiviert werden.

Verbesserte Codierungsunterstützung

Bisher wurde beim Bearbeiten und Speichern von Dateien im Web nur als UTF-8-Codierung gespeichert, und wir haben Sie nicht dazu aufgefordert, wenn sich die Dateicodierung geändert hat. Nun erhalten Sie eine Warnung, wenn Sie versuchen, eine Datei zu speichern, die nicht UTF-codiert ist (die nur UTF-Codierung unterstützt). Darüber hinaus wurde Unterstützung für die UTF-16- und UTF-32-Codierung über den Web-Pushes-Endpunkt hinzugefügt. Das bedeutet, dass wir den Codierungstyp beibehalten, sodass Sie ihn nicht als UTF-8 umschreiben müssen.

Der folgende Screenshot zeigt und ein Beispiel für das Dialogfeld, das angezeigt wird, wenn Sie Codierungsänderungen durch einen Webpush einführen.

Abrufen von Befehlsunterstützung in Azure Repos

Go ist eine Open Source Programmiersprache, die auch als Golang bezeichnet wird. In Go können Sie den Befehl get verwenden, um Pakete und Abhängigkeiten herunterzuladen und zu installieren. Mit diesem Update haben wir Unterstützung für go get innerhalb eines Azure DevOps-Repositorys hinzugefügt. Mit go get können Sie Pakete herunterladen, deren Abhängigkeiten durch die Importpfade benannt sind. Sie können das import Schlüsselwort verwenden, um den Importpfad anzugeben.

Pipelines

Web-Editor mit IntelliSense für YAML-Pipelines

Wenn Sie YAML zum Definieren Ihrer Pipelines verwenden, können Sie jetzt die neuen Editorfeatures nutzen, die mit diesem Release eingeführt wurden. Unabhängig davon, ob Sie eine neue YAML-Pipeline erstellen oder eine vorhandene YAML-Pipeline bearbeiten, können Sie die YAML-Datei im Pipeline-Web-Editor bearbeiten. Verwenden Sie STRG+Leerzeichen für die IntelliSense-Unterstützung, während Sie die YAML-Datei bearbeiten. Sie sehen die Syntaxfehler hervorgehoben und erhalten auch Hilfe bei der Korrektur dieser Fehler.

Aufgaben Assistent zum Bearbeiten von YAML-Dateien

Wir erhalten weiterhin viel Feedback, um die Bearbeitung von YAML-Dateien für Pipelines zu erleichtern, daher fügen wir dem YAML-Editor eine Aufgabe Assistent hinzu. Damit haben Sie die gleiche vertraute Erfahrung beim Hinzufügen einer neuen Aufgabe zu einer YAML-Datei wie im klassischen Editor. Diese neue Assistent unterstützt die meisten gängigen Aufgabeneingabetypen wie Auswahllisten und Dienstverbindungen. Um die neue Aufgabe Assistent zu verwenden, wählen Sie Bearbeiten für eine YAML-basierte Pipeline und dann die Assistent Aufgabe aus.

Auslösen von YAML-Pipelines mit Tags

YAML-Pipelines können ausgelöst werden, wenn Einem Commit Tags hinzugefügt werden. Dies ist nützlich für Teams, deren Workflows Tags enthalten. Für instance können Sie einen Prozess starten, wenn ein Commit als "letztes bekanntes Gut" markiert ist.

Sie können angeben, welche Tags eingeschlossen und ausgeschlossen werden sollen. Beispiel:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

Deklarieren von Containerressourcen inline

Zuvor mussten Sie Ihre Containerressourcen in YAML-Pipelines deklarieren und dann nach Namen darauf verweisen. Wir bieten jetzt eine Inlinesyntax für Fälle an, in denen Sie nicht mehrmals auf den Container verweisen.

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

Festlegen des automatischen Abbrechens einer vorhandenen Pipeline beim Aktualisieren von Pull Requests

Pipelines, die durch Pull Requests (PRs) ausgelöst werden, werden standardmäßig abgebrochen, wenn ein neuer Commit an denselben PR gepusht wird. Dies ist in den meisten Fällen wünschenswert, da Sie in der Regel keine Pipeline mehr mit veraltetem Code ausführen möchten. Wenn Sie dieses Verhalten nicht möchten, können Sie autoCancel: false ihrem PR-Trigger hinzufügen.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

Wählen Sie das Verzeichnis des ausgecheckten Codes in YAML-Pipelines aus.

Zuvor haben wir Repositorys im s Verzeichnis unter $(Agent.BuildDirectory) ausgecheckt. Jetzt können Sie das Verzeichnis auswählen, in dem Ihr Git-Repository für die Verwendung mit YAML-Pipelines ausgecheckt wird.

Verwenden Sie die path Schlüsselwort (keyword) eincheckout, und Sie haben die Kontrolle über die Ordnerstruktur. Im Folgenden finden Sie ein Beispiel für den YAML-Code, mit dem Sie ein Verzeichnis angeben können.

steps:
- checkout: self
  path: my-great-repo

In diesem Beispiel wird Ihr Code in das my-great-repo Verzeichnis im Arbeitsbereich des Agents ausgecheckt. Wenn Sie keinen Pfad angeben, wird Ihr Repository weiterhin in ein Verzeichnis namens sausgecheckt.

Neue Azure App Service Aufgaben, die für YAML optimiert sind

Wir unterstützen jetzt vier neue Aufgaben, die eine einfache und dennoch leistungsstarke Möglichkeit bieten, Azure-App Services für moderne Entwickler bereitzustellen. Diese Aufgaben verfügen über eine optimierte YAML-Syntax, die es einfach und intuitiv macht, Bereitstellungen in Azure AppServices zu erstellen, einschließlich WebApps, FunctionApps, WebApps for Containers und FunctionApp für Container auf Windows- und Linux-Plattformen.

Wir unterstützen auch eine neue Hilfsprogrammaufgabe für dateitransformation und Variablenersetzung für XML- und JSON-Formate.

Änderungen an Standardberechtigungen für neue Projekte

Bisher konnten Projektmitwirkende Pipelines nur erstellen, wenn ihnen explizit die Berechtigung "Builddefinition erstellen" erteilt wurde. Bei neuen Projekten können Ihre Teammitglieder problemlos Pipelines erstellen und aktualisieren. Diese Änderung verringert die Reibung für neue Kunden, die das Onboarding in Azure Pipelines durchführen. Sie können die Standardberechtigungen für die Gruppe Mitwirkende jederzeit aktualisieren und deren Zugriff einschränken.

Verwalten von GitHub-Releases mithilfe von Pipelines

GitHub-Releases sind eine hervorragende Möglichkeit, Software für Benutzer zu packen und bereitzustellen. Wir freuen uns, ihnen mitteilen zu können, dass Sie sie jetzt mithilfe des GitHub-Releasetasks in Azure Pipelines automatisieren können. Mit der Aufgabe können Sie ein neues Release erstellen, vorhandene Entwürfe/veröffentlichte Versionen ändern oder ältere Versionen verwerfen. Es unterstützt Features wie das Hochladen mehrerer Ressourcen, das Markieren eines Releases als Vorabversion, das Speichern eines Release als Entwurf und vieles mehr. Diese Aufgabe hilft Ihnen auch beim Erstellen von Versionshinweisen. Es kann auch automatisch die Änderungen (Commits und zugehörige Probleme) berechnen, die in diesem Release vorgenommen wurden, und sie den Versionshinweisen in einem benutzerfreundlichen Format hinzufügen.

Hier sehen Sie die einfache YAML für die Aufgabe:

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Ein GitHub-Beispielrelease, das mit dieser Aufgabe erstellt wurde:

Links zu bestimmten Zeilen in einem Buildprotokoll

Sie können jetzt einen Link zu bestimmten Zeilen im Buildprotokoll freigeben. Dies hilft Ihnen bei der Zusammenarbeit mit anderen Teammitgliedern bei der Diagnose von Buildfehlern. Wählen Sie einfach die Zeilen eines Protokolls aus der Ergebnisansicht aus, um ein Linksymbol zu erhalten.

Verbesserungen bei der Ressourcenautorisierung

Wir mussten Sicherheit für geschützte Ressourcen (z. B. Dienstverbindungen, Variablengruppen, Agentpools, sichere Dateien) bereitstellen, wenn in einer YAML-Datei darauf verwiesen wird. Gleichzeitig wollten wir Es Ihnen erleichtern, Pipelines einzurichten und zu verwenden, die diese Arten von Ressourcen für Nichtproduktionsszenarien verwenden. Zuvor haben wir eine Einstellung hinzugefügt, um eine Ressource als "autorisiert für die Verwendung in allen Pipelines" zu markieren.

Mit diesem Update erleichtern wir Es Ihnen, ein Problem mit der Ressourcenautorisierung zu beheben, auch wenn Sie eine Ressource nicht als solche gekennzeichnet haben. Wenn ein Build aufgrund eines Ressourcenautorisierungsfehlers fehlschlägt, sehen Sie in der neuen Benutzeroberfläche eine Option zum expliziten Autorisieren der Verwendung dieser Ressourcen in der Pipeline, und fahren Sie dann fort. Teammitglieder mit Berechtigungen zum Autorisieren von Ressourcen können diese Aktion direkt bei einem fehlerhaften Build ausführen.

Neue Erweiterungsbeitragspunkte auf der Registerkarte "Pipelines-Test"

Wir haben das Erweiterungsframework weiter leistungsfähiger, indem wir zwei neue Beitragspunkte auf der Registerkarte Testergebnisse in Pipelines hinzugefügt haben. Dadurch können Marketplace-Erweiterungen maßgeschneiderte Berichterstattungsfunktionen bereitstellen und weitere Interaktivität hinzufügen.

Die beiden Beitragspunkte sind:

1. Schaltfläche "Benutzerdefinierte Aktion" in der Symbolleiste

   Manchmal möchten Sie möglicherweise eine Aktion ausführen, z. B. das Aktualisieren der Daten einer API oder das Ausführen benutzerdefinierter Tools mithilfe von Metadaten aus Ihren Testergebnissen. Mit diesem Beitragspunkt können Sie Erweiterungen erstellen, die den unmittelbaren Kontext des ausgewählten Testergebnisses verwenden, um der Schaltfläche *Benutzerdefinierte Aktion- eine benutzerdefinierte Aktion hinzuzufügen.

   

2. Registerkarte "Benutzerdefinierte Details" im Detailbereich

   Möglicherweise verfügen Sie über eine Vielzahl von Testberichtsverbrauchsworkflows und möchten möglicherweise verschiedene Datenpunkte für fehlgeschlagene Tests zum Debuggen und zur Analyse anzeigen. Mithilfe dieses Beitragspunkts kann Ihr Team dem Detailbereich eine neue Registerkarte hinzufügen, die angezeigt wird, wenn Sie eine beliebige Testergebniszeile im Datenraster auswählen. Diese neue Registerkarte kann eine Ansicht mit statischem Inhalt oder dynamischen Daten anzeigen, die mithilfe interner oder externer APIs abgerufen werden.

Einmal ausführen des Agents

Wenn Sie Infrastruktur wie Azure Container Instances verwenden, um private Agents für elastische Datenbanken auszuführen, möchten Sie häufig, dass jeder Agent nur einen Auftrag akzeptiert, bevor er abläuft. Bisher war dies nicht einfach, da Sie den Agent beenden mussten (was möglicherweise zu einem Fehler führte) oder das Risiko akzeptieren mussten, dass ein Agent einen anderen Auftrag erhält, bevor Sie ihn herunterfahren konnten. Mit diesem Update haben wir der Agentkonfiguration das Flag --once hinzugefügt. Wenn Sie den Agent auf diese Weise konfigurieren, akzeptiert er nur einen Auftrag und wird dann selbst heruntergefahren.

Aktualisierung der Benutzeroberfläche des Agent-Pools

Die Verwaltungsseite für Agentpools in den Projekteinstellungen wurde mit einer neuen Benutzeroberfläche aktualisiert. Jetzt können Sie leicht alle Aufträge anzeigen, die in einem Pool ausgeführt werden. Darüber hinaus können Sie erfahren, warum ein Auftrag nicht ausgeführt wird.

Bereitstellen auf fehlerhaften Zielen in einer Bereitstellungsgruppe

Standardmäßig wird Azure Pipelines verwendet, um alle Aufträge erneut auszuführen, wenn Sie eine zuvor fehlgeschlagene Ausführung erneut bereitstellen. Jetzt können Sie dieses Verhalten überschreiben, indem Sie bei der Bereitstellung die Bereitstellungsoption konfigurieren. Wenn Sie in einer Bereitstellungsgruppe die Option Alle Aufträge und Auf fehlgeschlagene Ziele beschränken auswählen, führt die erneute Ausführung alle Aufträge aus und überspringt die Bereitstellungen für die Ziele, die bereits auf dem neuesten Stand sind.

Automatische erneute Bereitstellung bei Einem Fehler

Wenn eine Bereitstellung in einer Phase fehlschlägt, kann Azure Pipelines jetzt automatisch die letzte erfolgreiche Bereitstellung erneut bereitstellen. Sie können die Phase so konfigurieren, dass die letzte erfolgreiche Version automatisch bereitgestellt wird, indem Sie den Trigger für die automatische erneute Bereitstellung in den Bedingungen nach der Bereitstellung konfigurieren. Wir planen, der Konfiguration für die automatische erneute Bereitstellung in einem zukünftigen Sprint zusätzliche ausgelöste Ereignisse und Aktionen hinzuzufügen. Weitere Informationen finden Sie in der Dokumentation zu Bereitstellungsgruppen .

Grafana-Anmerkungsdienst-Hook

Wir unterstützen jetzt einen neuen Diensthook, mit dem Sie Grafana-Anmerkungen für Ereignisse vom Typ Bereitstellung abgeschlossen zu einer Grafana-Dashboard hinzufügen können. Auf diese Weise können Sie Bereitstellungen mit den Änderungen an Anwendungs- oder Infrastrukturmetriken korrelieren, die in einem Grafana-Dashboard visualisiert werden.

Abfragen von Azure Monitor-Warnungsaufgaben

Die vorherige Version des Tasks Azure Monitor abfragen unterstützte Abfragen von Warnungen nur in der klassischen Überwachungsumgebung. Mit dieser neuen Version der Aufgabe können Sie Warnungen auf der kürzlich von Azure Monitor eingeführten einheitlichen Überwachungsumgebung abfragen.

Inlineeingabe der Spezifikationsdatei im Task "Bereitstellen in Kubernetes"

Zuvor mussten Sie für die Kubernetes-Bereitstellungsaufgabe einen Dateipfad für die Konfiguration angeben. Jetzt können Sie die Konfiguration auch inline hinzufügen.

Docker CLI Installer-Task

Diese Aufgabe ermöglicht die Installation einer beliebigen Version der Docker CLI auf den Agents, wie vom Benutzer angegeben.

Wiederherstellen gelöschter Releasepipelines

Das Löschen nicht verwendeter Releasepipelines hilft dabei, die Liste der Releasepipeline sauber zu behalten, aber manchmal löschen Sie versehentlich etwas. Mit diesem Update ist es jetzt möglich, eine Releasepipeline wiederherzustellen, die innerhalb der letzten 30 Tage gelöscht wurde. Im linken Bereich der Seite Releases wurde eine neue Registerkarte hinzugefügt, die eine Liste der gelöschten Releasepipelines anzeigt. In dieser Ansicht können Sie eine gelöschte Releasepipeline wiederherstellen, indem Sie die Pipeline aus der Liste auswählen und auf die Schaltfläche Wiederherstellen klicken.

Benachrichtigungen bei Einem Fehler bei einer Anforderung zur Releaseerstellung

Sie können Benachrichtigungen so festlegen, dass E-Mails empfangen werden, wenn Änderungen an Ihren Builds, Der Codebasis und anderen Vorgängen auftreten. Beispielsweise können Sie eine Warnung so festlegen, dass sie benachrichtigt wird, wenn Ihnen ein Arbeitselement zugewiesen wird.

Mit diesem Update haben wir der Kategorie Release ein neues Benachrichtigungsabonnement hinzugefügt. Diese Benachrichtigung sendet Ihnen eine E-Mail, wenn eine Anforderung für eine Releaseerstellung fehlschlägt. Ein Beispielszenario, in dem dies nützlich sein kann, ist, wenn eine Anforderung zum Erstellen eines Release fehlschlägt, da keine Artefaktversion verfügbar ist. Informationen zum Verwalten Ihrer Benachrichtigungen finden Sie in der Dokumentation hier.

Planen von Releases für Quell- oder Pipelineänderungen

Wenn Sie zuvor über einen geplanten Releasetrigger verfügten, wurde ein Release auch dann ausgelöst, wenn keine Änderung im Upstream Artefakt oder in der Releasedefinition erkannt wurde. Dem Bereich Releasetrigger planen wurde eine Option hinzugefügt, um Releases nur dann zu planen, wenn sich die Artefaktversion oder die Releasedefinition geändert hat.

Beitragspunkt für Variablen im Dialogfeld "Release erstellen"

Zuvor mussten die variablen Werte, die während der Releaseerstellung benötigt wurden, vom Benutzer ohne Unterstützung oder Vorschläge eingegeben werden. Wir haben Beiträge zum Dialogfeld Neues Release erstellen hinzugefügt, um Erweiterungen zu unterstützen, die beim Auffüllen des Werts einer Variablen während der Releaseerstellung helfen.

Veröffentlichen in Azure Service Bus Sitzungswarteschlangen

Wir haben die Aufgabe zum Erstellen von Aufträgen ohne Agent um die Möglichkeit erweitert, Nachrichten in Sitzungswarteschlangen zu veröffentlichen. Diese Option wurde der Aufgabe In Azure Service Bus veröffentlichen hinzugefügt.

Neue Azure-Abonnementoption in Kubernetes-Dienstverbindung

Dienstverbindungen für Builds und Releases ermöglichen es Ihnen, eine Verbindung mit externen und Remotediensten herzustellen, um Aufgaben für einen Build oder eine Bereitstellung auszuführen. Sie können eine Dienstverbindung über die Admin Einstellungen Ihres Projekts definieren und verwalten.

Mit diesem Update wurde dem Kubernetes-Dienstverbindungsformular eine Authentifizierungsoption hinzugefügt. Jetzt können Sie Azure-Abonnement auswählen, um Ihre Verbindung zu authentifizieren. Dies erleichtert die Bereitstellung in bestimmten Namespaces, indem Kubernetes-Verbindungen mit Ihrem Azure-Abonnement und Clusternamen eingerichtet werden.

Für einen Cluster mit rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) werden ServiceAccount - und RoleBinding-Objekte im ausgewählten Namespace erstellt. Das RoleBinding-Objekt beschränkt die Vorgänge des erstellten Dienstkontos nur auf den ausgewählten Namespace. Für einen RBAC-deaktivierten Cluster verfügt das erstellte Dienstkonto über clusterweite Berechtigungen für alle Namespaces.

Azure-Containerregistrierung in Docker-Registrierungsdienstverbindung

Jetzt können Sie eine Docker-Registrierungsdienstverbindung über die Einstellungsseite Ihres Projekts erstellen. Um die Verbindung zu erstellen, wählen Sie eine Azure-Containerregistrierung in einem der Abonnements aus, die Ihrer Azure Active Directory -Identität (AAD) zugeordnet sind. Alle Aufgaben, die Dienstverbindungen mit Containerregistrierungen wie Docker@2 und KubernetesManifest@0 erfordern, unterstützen eine einzelne Möglichkeit zum Angeben einer Verbindung.

Suchen nach Ordnernamen in Releasedefinitionen

Sie können Ihre Releasedefinitionen organisieren, indem Sie sie in Ordnern speichern. Zuvor hatten Sie nicht die Möglichkeit, eine Suche nach Ordner durchzuführen. Es war schwierig, eine bestimmte Releasedefinition zu finden, wenn Sie viele Ordner erstellt hatten. Jetzt können Sie nach Dem Ordnernamen in der Releasedefinition suchen, sodass Sie die gesuchten Definitionen leichter finden können.

Duffle-Toolinstallationsaufgabe in der Build- und Releasepipeline

Duffle ist ein Befehlszeilentool, mit dem Sie Cloud Native Application Bundles (CNAB) installieren und verwalten können. Mit CNABs können Sie containernative Apps und deren Dienste bündeln, installieren und verwalten.

In diesem Update wurde eine neue Aufgabe für Build- und Releasepipelines hinzugefügt, mit der Sie eine bestimmte Version von Duffle-Binärdatei installieren können.

Kubernetes-Manifestaufgabe

Wir haben unseren Releasepipelines eine neue Aufgabe hinzugefügt, um die Bereitstellung in Kubernetes-Clustern mithilfe von Manifestdateien zu vereinfachen. Diese Aufgabe bietet die folgenden Vorteile im Vergleich zur Verwendung von kubectl-Binärdateien in Skripts:

• Artefaktersetzung: Die Bereitstellungsaktion verwendet als Eingabe eine Liste von Containerimages, die zusammen mit ihren Tags oder Digests angegeben werden können. Dies wird durch die Nicht-Vorlagenversion der Manifestdateien ersetzt, bevor Sie sie auf den Cluster anwenden, um sicherzustellen, dass die richtige Version des Images von den Knoten des Clusters abgerufen wird.

• Manifeststabilität: Rollout status wird für die bereitgestellten Kubernetes-Objekte überprüft, um Stabilitätsprüfungen zu integrieren, während die Aufgabe status als Erfolg/Fehler ausgeführt wird.

• Rückverfolgbarkeitsanmerkungen: Anmerkungen werden den bereitgestellten Kubernetes-Objekten hinzugefügt, um Informationen zur Rückverfolgbarkeit über den Ursprung von organization, Projekt, Pipeline und Ausführung zu überlagern.

• Bake-Manifest: Die Bake-Aktion der Aufgabe ermöglicht das Backen von Helm-Diagrammen in Kubernetes-Manifestdateien, sodass sie auf den Cluster angewendet werden können.

• Bereitstellungsstrategie: Die Auswahl der Canary-Strategie mit Bereitstellungsaktion führt zur Erstellung des gewünschten Prozentsatzes von Workloads mit den Suffixen -baseline und -canary , sodass diese während einer ManualIntervention Aufgabe verglichen werden können, bevor die Aktion "Heraufstufen/Ablehnen" der Aufgabe verwendet wird, um die zu behaltende Version zu finalisieren.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Upgrades auf Docker-Aufgabe

Wir haben die Docker-Aufgabe aktualisiert, um die Pipelineerstellung zu vereinfachen. Der Befehl buildAndPush kann jetzt verwendet werden, um mehrere Tags für ein bestimmtes Containerrepository zu erstellen und in einem einzigen Schritt an mehrere Containerregistrierungen zu pushen. Der Task kann Docker-Registrierungsdienstverbindungen für die Anmeldung bei Containerregistrierungen verwenden. Nachverfolgbarkeitsmetadaten zu Quellrepository, Commit und Build-Provenienz werden den mit dieser Aufgabe erstellten Images als Bezeichnungen hinzugefügt.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Installer für Kubectl-Tool

Wir haben eine neue Aufgabe hinzugefügt, mit der Sie eine bestimmte Version der Kubectl-Binärdatei auf den Agents installieren können. Die aktuellen Zeichenfolgen und semver-Versionszeichenfolgen wie "v1.14.0" werden als gültige Werte für die Kubectl-Versionsspezifikationseingabe akzeptiert.

Verbesserungen bei der ServiceNow-Integration

Eine wichtige Funktion für die teamübergreifende Zusammenarbeit besteht darin, es jedem Team zu ermöglichen, einen Dienst seiner Wahl zu nutzen und eine effektive End-to-End-Bereitstellung zu haben. Mit diesem Update haben wir die ServiceNow-Integration erweitert, um alle Arten von Änderungen (Normal, Standard und Notfall) zu unterstützen. Darüber hinaus können Sie jetzt das Gate angeben, das zum Erstellen einer neuen Änderungsanforderung mithilfe einer vorhandenen Vorlage verwendet wird, gemäß dem ITSM-Prozess, der in Ihrem organization folgt. Schließlich können Sie auch Releases basierend auf vorhandenen Änderungsanforderungen gaten. Dadurch können Sie CD einführen, ohne den von Ihren IT-Teams empfohlenen Prozess ändern zu müssen.

Unterstützung für Red Hat Enterprise Linux 6

Mit diesem Update wurde agent-Unterstützung für Red Hat Enterprise Linux 6 hinzugefügt. Sie können jetzt Agents für die Red Hat Enterprise Linux 6-Plattform für die Ausführung von Build- und Releaseaufträgen konfigurieren.

Unterstützung für Azure PowerShell Az-Modul

Azure PowerShell stellt eine Reihe von Cmdlets bereit, mit denen Sie Azure-Ressourcen über die Befehlszeile verwalten können. Im vergangenen Dezember wurde das Modul Azure PowerShell Az verfügbar und ist nun das modul für die Verwaltung Ihrer Azure-Ressourcen vorgesehen.

Zuvor haben wir keine Unterstützung für das modul Azure PowerShell Az in unseren gehosteten Agents bereitgestellt. Mit der neuen Azure PowerShell Taskversion 4.* in Build- und Releasepipelines haben wir Unterstützung für das neue Az-Modul für alle Plattformen hinzugefügt. Azure PowerShell Taskversion 3.* unterstützt weiterhin das AzureRM-Modul. Um jedoch mit den neuesten Azure-Diensten und -Features Schritt zu halten, empfiehlt es sich, so schnell wie möglich zur Azure PowerShell Aufgabenversion 4.* zu wechseln.

Das Az-Modul verfügt über einen Kompatibilitätsmodus, mit dem Sie vorhandene Skripts verwenden können, während Sie sie so aktualisieren, dass sie die neue Syntax verwenden. Verwenden Sie den Befehl, um die Kompatibilität für das Enable-AzureRmAlias Az-Modul zu aktivieren. Mit Aliasen können Sie die alten Cmdletnamen mit az module verwenden. Weitere Informationen zur Migration vom Azure RM-Modul zum modul Azure PowerShell Az finden Sie hier.

Hinweis

Sie müssen das Az-Modul auf Ihrem Agent-Computer installieren, wenn Sie private Agents verwenden.

Weitere Informationen zum Modul Azure PowerShell Az finden Sie in der Dokumentation hier.

Unterstützung der Azure Active Directory-Authentifizierung (AD) für Azure SQL Aufgabe

Die Azure SQL-Aufgabe wurde erweitert, um das Herstellen einer Verbindung mit einer Datenbank mithilfe von Azure AD (Integrated & Password) und einer Verbindungszeichenfolge zusätzlich zur vorhandenen Unterstützung für die SQL Server-Authentifizierung zu unterstützen.

Veröffentlichen von Buildartefakten mit langen Dateipfaden

Bisher gab es eine Einschränkung, die das Hochladen von Buildartefakten mit Pfaden mit mehr als 233 Zeichen verhinderte. Dies kann verhindern, dass Sie Code Coverage-Ergebnisse von Linux- und macOS-Builds mit Dateipfaden hochladen, die länger als das Limit sind. Das Limit wurde aktualisiert, um lange Pfade zu unterstützen.

Überspringen von Continuous Integration (CI) für einen Commit

Sie können Azure Pipelines jetzt anweisen, einen Commit zu ignorieren und die Ausführung einer Pipeline zu überspringen, die der Commit normalerweise auslösen würde. Fügen Sie [skip ci] einfach in die Commitnachricht des HEAD Commits ein, und Azure Pipelines überspringt CI. Sie können auch eine der unten aufgeführten Variationen verwenden. Dies wird für Commits für Azure Repos Git und GitHub Enterprise Server unterstützt.

• [skip ci] oder [ci skip]
• skip-checks: true oder skip-checks:true
• [skip azurepipelines] oder [azurepipelines skip]
• [skip azpipelines] oder [azpipelines skip]
• [skip azp] oder [azp skip]
• ***NO_CI***

Test Plans

Testergebnistrend (Erweitert) Widget

Das Widget Test results trend (Advanced) bietet nahezu echtzeitbasierte Einblicke in Ihre Testdaten für mehrere Builds und Releases. Das Widget Testergebnistrend (Erweitert) zeigt einen Trend Ihrer Testergebnisse für Ihre Pipelines oder pipelineübergreifend an. Sie können es verwenden, um die tägliche Anzahl der Tests, die Bestandensrate und die Testdauer nachzuverfolgen. Die Überwachung der Testqualität im Lauf der Zeit und die Verbesserung der Testsicherheit ist der Schlüssel für die Aufrechterhaltung einer fehlerfreien DevOps-Pipeline.

Das Widget Test results trend (Advanced) hilft Ihnen, Ausreißer in Ihren Testergebnissen zu ermitteln und Fragen wie: Dauert die Ausführung von Tests länger als üblich? Welche Testdatei oder Pipeline wirkt sich auf meine Gesamtdurchlaufrate aus? Was sind meine Tests mit langer Ausführungszeit?

Um diese Fragen zu beantworten, bietet das Widget die folgenden Features:

• Zeigt einen Trend der Bestandensrate und die Anzahl der Testergebnisse oder die Testdauer an.
• Zeigt Testergebnisse basierend auf mehreren Buildpipelines oder Releasepipelines an
• Verwendet kombinierte Diagrammoptionen, um zwei Metriken für denselben Trend anzuzeigen
• Filtert die Testanzahl im Zeitverlauf nach Testergebnis
• Filtert alle Testergebnisse nach Branch oder Test
• Stapelt Ihre Metriken nach Testattributen wie Priorität oder Umgebung
• Gruppierung Ihrer Daten in Testdateien, Besitzern oder Pipelines

Das Widget ist hochgradig konfigurierbar, sodass Sie es für eine Vielzahl von Szenarien verwenden können.

Freigeben von Testlaufergebnissen über die URL

Sie können automatisierte Tests so konfigurieren, dass sie als Teil eines Builds oder Release ausgeführt werden. Die veröffentlichten Testergebnisse können auf der Registerkarte Tests in der Build- oder Releasezusammenfassung angezeigt werden. Mit diesem Update wurde ein Feature zum Kopieren von Ergebnis-URL hinzugefügt, mit dem Sie einzelne Testlaufergebnisse für andere Personen in Ihrem Team freigeben können.

Die Freigabeebenen umfassen:

• Ausführungsebene
• Ergebnisebene
• Einzelne Registerkarte im Testlauf ausgewählt
• Die Freigabe ist auch mit allen konfigurierten Erweiterungsregisterkarten kompatibel.

Wenn Sie die URL freigeben, werden den Zuschauern die Testlaufergebnisse in der Vollbildansicht angezeigt.

Artifacts

NuGet-Pakete mit SemVer 2.0.0-Versionsnummern

Bisher hat Azure Artifacts keine NuGet-Pakete mit SemVer 2.0.0-Versionsnummern unterstützt (im Allgemeinen Versionsnummern, die den Buildmetadatenteil der Version enthalten, was durch einen +gekennzeichnet wird). Jetzt können Sie Pakete aus nuget.org speichern, die Buildmetadaten enthalten, und Ihre eigenen Pakete mit Buildmetadaten pushen. Gemäß der SemVer-Spezifikation und NuGet.org Richtlinie können Buildmetadaten nicht zum Bestellen von Paketen verwendet werden. Sie können also nicht sowohl als 1.0.0+build2 auch 1.0.0+build1 in Azure Artifacts (oder nuget.org) veröffentlichen, da diese Versionen als gleichwertig betrachtet werden und daher den Unveränderlichkeitseinschränkungen unterliegen.

Provenienzinformationen zu Paketen

Mit diesem Update haben wir es etwas einfacher gemacht, die Herkunft Ihrer Pakete zu verstehen: wer oder was sie veröffentlicht hat und aus welchem Quellcodecommitten sie stammen. Diese Informationen werden automatisch für alle Pakete aufgefüllt, die mit den Aufgaben NuGet, npm, Maven und Twine Authenticate (für Python) in Azure Pipelines veröffentlicht werden.

Statistiken zur Paketnutzung

Bisher bot Azure Artifacts keine Möglichkeit, die Nutzung oder Beliebtheit von Paketen zu messen. Mit diesem Update haben wir sowohl der Paketliste als auch den Paketdetails eine Anzahl von Downloads und Benutzern hinzugefügt. Sie können die Statistiken auf der rechten Seite einer Seite anzeigen.

Unterstützung für Python-Pakete

Azure Artifacts kann jetzt Python-Pakete hosten: Sowohl pakete, die Sie selbst erstellen, als auch Upstream Pakete, die aus der öffentlichen PyPI gespeichert werden. Weitere Informationen finden Sie im Blogbeitrag zur Ankündigung und in der Dokumentation.

Jetzt können Sie alle NuGet-, npm-, Maven- und Python-Pakete im selben Feed hosten.

Upstreamquellen für Maven

Upstreamquellen sind jetzt für Maven-Feeds verfügbar. Dies umfasst das primäre Maven Central-Repository und Azure Artifacts-Feeds. Um einem vorhandenen Feed Maven-Upstreams hinzuzufügen, besuchen Sie Feedeinstellungen, wählen Sie den Pivot Upstreamquellen und dann Upstream Quelle hinzufügen aus.

Proxyunterstützung für Aufgaben im Zusammenhang mit Artefakten

Bisher boten viele Artefakt-bezogene Buildtasks keine vollständige Unterstützung für die Proxyinfrastruktur von Azure Pipelines, was zu Herausforderungen bei der Verwendung der Aufgaben von lokalen Agents führte. Mit diesem Update haben wir den folgenden Aufgaben Unterstützung für Proxys hinzugefügt:

• Npm@1 ("npm" im Designer)
• NuGetCommand@2 ("NuGet" im Designer): Nur Wiederherstellungs- und Pushbefehle
• DotNetCoreCLI@2 (.NET Core im Designer): Nur Wiederherstellungs- und NuGet-Pushbefehle
• NpmAuthenticate@0, PipAuthenticate@0 und TwineAuthenticate@0 ("[Typ] Authentifizieren" im Designer): Diese Aufgaben unterstützen Proxys beim Abrufen von Authentifizierungstoken, aber es ist weiterhin erforderlich, alle nachfolgenden Aufgaben/Skripts/Tools für die Verwendung des Proxys zu konfigurieren. Anders ausgedrückt: Diese Aufgaben konfigurieren nicht den Proxy für das zugrunde liegende Tool (npm, pip, twine).
• NuGetToolInstaller@0, NodeTool@0, DotNetCoreInstaller@0 ("[type] Installer" im Designer)

Alle Artefakt-Pakettypen, die in Releases unterstützt werden

Bisher wurden nur NuGet-Pakete im Artefakttyp Azure Artifacts in Pipelines-Releases unterstützt. Mit diesem Update werden alle Azure Artifacts-Pakettypen – Maven, npm und Python – unterstützt.

In Releases unterstützte Artefaktesichten

Bisher konnte der Artefakttyp Azure Artifacts nur ausgelöst werden, wenn neue Paketversionen im Feed veröffentlicht wurden. Jetzt haben wir auch Unterstützung für Ansichten hinzugefügt, sodass Sie Releases auslösen können, wenn Pakete, die bereits im Feed enthalten sind, zu einer Ansicht heraufgestuft werden.

Aufbewahrungsrichtlinien können kürzlich heruntergeladene Pakete überspringen.

Bisher haben Azure Artifacts-Feeds grundlegende Aufbewahrungsrichtlinien bereitgestellt, die mit dem Löschen alter Paketversionen beginnen würden, wenn eine "maximale Anzahl von Versionen pro Paket" erreicht wurde. Mit diesem Update haben wir die Möglichkeit hinzugefügt, kürzlich heruntergeladene Pakete bei dieser sauber zu überspringen. Um dies zu aktivieren, bearbeiten Sie Ihren Feed, und aktivieren Sie das Kontrollkästchen Zuletzt heruntergeladene Pakete überspringen .

Delegieren, wer Feeds verwalten kann

In Azure Artifacts konnten Projektsammlungsadministratoren (PROJECT Collection Administrators , PCAs) seit jeher alle Feeds auf einem Azure DevOps-Server verwalten. Mit diesem Update können PCAs diese Möglichkeit auch anderen Benutzern und Gruppen geben, wodurch die Möglichkeit zur Verwaltung von Feeds delegiert wird.

Wiki

Markdownvorlagen für Formeln und Videos

Es ist nicht mehr erforderlich, sich die Markdownsyntax zum Hinzufügen von Formeln, Videos und YAML-Tags beim Bearbeiten eines Wikis zu merken. Sie können jetzt in der Symbolleiste auf das Kontextmenü klicken und die Option Ihrer Wahl auswählen.

Einbetten Azure Boards Abfrageergebnisse in Wiki

Sie können jetzt Azure Boards Abfrageergebnisse in eine Wiki-Seite in Form einer Tabelle einbetten. Die folgende Abbildung zeigt ein Beispiel einer Wiki-Seite mit einer Liste aller veröffentlichten Features und aller aktiven Fehler im aktuellen Sprint, die in das Wiki eingebettet sind. Der auf der Seite angezeigte Inhalt verwendet eine vorhandene Arbeitselementabfrage. Mit diesem neuen Feature können Sie dynamische Inhalte erstellen und müssen sich keine Gedanken über die manuelle Aktualisierung der Wiki-Seite machen.

Die Abfrageergebnisse können in zwei Schritten hinzugefügt werden:

1. Klicken Sie auf der Bearbeitungssymbolleiste auf die Schaltfläche "Abfrageergebnisse".

2. Wählen Sie die erforderliche Abfrage aus, und klicken Sie auf die Schaltfläche "Einfügen".

Die Ergebnisse der Abfrage können nun in Form einer Tabelle angezeigt werden, nachdem Sie die Seite gespeichert haben.

Schriftart mit nur einem Leerzeichen für den Wiki-Markdown-Editor

Mit der Einführung von Schriftarten mit monospaced für den Wiki-Markdown-Editor ist die Lesbarkeit keine Herausforderung mehr. Die Markdownquelle sieht sauber und einfach zu lesen aus. Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert.

Permalinks für Wiki-Seiten

Bisher sind freigegebene Wiki-Seitenlinks unterbrochen, wenn die verknüpfte Seite umbenannt oder verschoben wurde. Wir haben jetzt permanente Links eingeführt, indem wir der URL eine Seiten-IDs hinzufügen. Dadurch wird sichergestellt, dass von Ihnen freigegebene Links intakt bleiben, wenn sich das Wiki im Laufe der Zeit ändert.

Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert.

Anzeigen status von Arbeitselementen auf Wiki-Seiten

In diesem Update haben wir die Erwähnungen von Arbeitselementen in Wiki-Seiten verbessert, indem wir der Seite die status des Arbeitselements zusammen mit der ID und dem Titel hinzugefügt haben.

Arbeitselementverweise in Pull Request-Kommentaren und Boards-Diskussionen zeigen auch die status an.

@mention Benutzer und Gruppen

Sie können jetzt @mention Benutzer und Gruppen auf einer Wiki-Seite verwenden. Dadurch werden Dokumente wie die Kontaktseite eines Teams, Leitfäden und Wissensdokumente umfangreicher. Die folgende Abbildung zeigt ein Beispiel für eine Sprint-Retrospektive mit Aufgaben und der verantwortlichen Person.

@Erwähnung Benutzer und Gruppen <." />

Darüber hinaus können Sie auch einen Benutzer oder eine Gruppe aus der automatischen Erfassung auswählen, indem Sie auf der Wiki-Bearbeitungsseite "@" eingeben. Die erwähnte Person wird auch per Post benachrichtigt.

@Erwähnung beginnen." />

Schließlich können Sie auch auf den @mentioned Benutzer klicken, um die Profilinformationen Karte anzuzeigen. Dieses Feature wurde basierend auf diesem Featurevorschlag priorisiert.

Benachrichtigungen auf Wiki-Seiten

Bis jetzt wusstest du nicht, wann der Inhalt einer Wiki-Seite geändert wurde. Jetzt können Sie Wiki-Seiten folgen, um per E-Mail benachrichtigt zu werden, wenn die Seite bearbeitet, gelöscht oder umbenannt wird. Um an einem Wiki vorgenommene Änderungen nachzuverfolgen, wählen Sie auf der Wiki-Seite die Schaltfläche Folgen aus.

Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert. Weitere Informationen finden Sie in unserer Dokumentation hier.

Unterstützung für HTML-Tags

Jetzt können Sie umfangreichere Inhalte im Wiki mithilfe von HTML-Tags erstellen. Sehen Sie sich unten an, was Sie mit HTML-Tags tun können.

1. Sie können jetzt reduzierbare Abschnitte innerhalb Ihrer Wiki-Seiten erstellen, indem Sie die Details - und Zusammenfassungstags verwenden. Sie können das open-Attribut hinzufügen, um die Details standardmäßig zu erweitern.

   

   Weitere Informationen zum Detailtag finden Sie in der Dokumentation.

   Dies wurde basierend auf diesem Vorschlagsticket priorisiert.

   Hinweis

   Dieses Tag wird in Edge- und Internet-Explorer Browsern nicht unterstützt.

Verbesserte Tabellenerstellung und -bearbeitung

Bisher war das Erstellen und Bearbeiten von Tabellen in einem Wiki schwierig. Wir haben Änderungen vorgenommen, um Ihnen das Hinzufügen und Verwalten von Tabellen in Ihrem Wiki zu erleichtern.

1. Erstellen einer Tabelle aus einem Raster

   Sie müssen sich die Syntax der Markdowntabelle nicht mehr merken. Jetzt können Sie ganz einfach eine Markdowntabelle erstellen, indem Sie aus einem 15 x 15-Raster auswählen. Wählen Sie einfach die erforderliche Anzahl von Spalten und Zeilen aus, um eine Tabelle mit einem einzigen Klick einzufügen.

   

   Dieses Feature wurde basierend auf den folgenden Vorschlagstickets priorisiert:

   • Tabellenansicht für Wiki
   • Einfaches Einfügen von Tabellen in Wiki

2. Bessere Lesbarkeit von Tabellen

   Sie können jetzt den Zeilenumbruch für Ihren Editor umschalten, um die Lesbarkeit Ihrer Tabellen zu verbessern. Durch das Deaktivieren des Wortumbruchs wird eine Bildlaufleiste hinzugefügt, mit der Sie den Inhalt großer Tabellen einfacher anzeigen können.

   

3. Automatisches Formatieren von Markdowntabellen

   Sie müssen keine Leerzeichen mehr hinzufügen, um Ihre Markdownspalten auszurichten. Mit der Schaltfläche Tabellen formatieren werden Ihre Markdowntabellen automatisch formatiert, indem den Zellen Leerzeichen hinzugefügt werden, um die Spalten auszurichten. Wenn Sie über große Tabellen verfügen, verwenden Sie sie mit dem Deaktivieren des Zeilenumbruchs , um die Lesbarkeit der Tabellen zu vereinfachen.

   

   Sie können auch die Tastenkombination STRG+UMSCHALT+F verwenden, um Ihre Tabellen zu formatieren.

Berichterstellung

Analytics-Erweiterung für die Verwendung von Analytics nicht mehr erforderlich

Analytics wird immer mehr zu einem integralen Bestandteil der Azure DevOps-Erfahrung. Es ist eine wichtige Funktion für Kunden, um sie bei datengesteuerten Entscheidungen zu unterstützen.

Für Update 1 freuen wir uns, ihnen mitteilen zu können, dass Kunden die Analytics-Erweiterung nicht mehr benötigen, um Analytics zu verwenden. Kunden können analytics jetzt unter Den Projektsammlungseinstellungen aktivieren. Es handelt sich um einen einfachen Prozess, der direkt im Produkt liegt.

So können Kunden Analytics aktivieren:

1. Navigieren Sie zu Projektsammlungseinstellungen:

2. Klicken Sie auf Analytics aktivieren.

Das war’s! Analysegestützte Erfahrungen werden für die Sammlung aktiviert.

Für neue Sammlungen, die in Update 1 und Azure DevOps Server 2019-Sammlungen mit installierter Analytics-Erweiterung erstellt wurden und aktualisiert wurden, ist Analytics standardmäßig aktiviert.

Weitere Informationen zu Analytics und den damit ermöglichten Funktionen:

• Erfahren Sie mehr über das Aktivieren von Analytics.
• Lesen Sie die Dokumentation zur Analyseübersicht.
• Informieren Sie sich über die wichtigsten Features: Analysewidgets, Testbericht mit den häufigsten Fehlern, Power BI-Integration und OData-Endpunkt.
• Sehen Sie sich dieses Channel 9-Video zu Azure DevOps Analytics an.

---

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen, es über Entwicklercommunity nachverfolgen und Sich zu Stack Overflow beraten lassen.

---

Seitenanfang