Versionshinweise zu Azure DevOpsServer 2020 Update 1

| 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 2020 Update 1.2 Patch 14 Veröffentlichungsdatum: 12. November 2024

Datei	SHA-256 Hash
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Wir haben Patch 14 für Azure DevOps Server 2020 Update 1.2 veröffentlicht, um ein Upgrade auf eine anfällige Abhängigkeit einzuschließen.

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

Datei	SHA-256 Hash
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Wir haben Patch 13 für Azure DevOps Server 2020 Update 1.2 veröffentlicht, das Korrekturen für Folgendes enthält:

• Ein Problem wurde behoben, bei dem der Proxyserver nach der Installation von Patch 12 nicht mehr funktionierte.

Azure DevOps Server 2020 Update 1.2 Patch 12 Veröffentlichungsdatum: 13. Februar 2024

Datei	SHA-256 Hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Wir haben Patch 12 für Azure DevOps Server 2020 Update 1.2 veröffentlicht, das Korrekturen für Folgendes enthält:

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

Azure DevOps Server 2020 Update 1.2 Patch 11 Veröffentlichungsdatum: 12. Dezember 2023

Datei	SHA-256 Hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Wir haben Patch 11 für Azure DevOps Server 2020 Update 1.2 veröffentlicht, das Korrekturen für Folgendes enthält:

• Es wurde ein Fehler behoben, bei dem die Vererbung der Sicherheitsvererbung vor der Bereitstellung in Pipelinesphasen nicht funktionierte.

Azure DevOps Server 2020 Update 1.2 Patch 10 Veröffentlichungsdatum: 14. November 2023

Wir haben einen Patch für Azure DevOps Server 2020 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.

Hinweis

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

Patches installieren

Wichtig

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

Konfigurieren von TFX

1. Führen Sie die Schritte in der Dokumentation zum Hochladen von Aufgaben in Projektsammlungen aus, um die Installation und Anmeldung mit TFX-CLI durchzuführen.

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256 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 2020 Update 1.2 Patch 9 Veröffentlichungsdatum: 10. Oktober 2023

Wichtig

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

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

• Ein Fehler wurde behoben, bei dem die Identität "Analysebesitzer" auf Patchupgradecomputern als Inaktive Identität angezeigt wird.

Azure DevOps Server 2020 Update 1.2 Patch 8 Veröffentlichungsdatum: 12. September 2023

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

• CVE-2023-33136; Sicherheitsrisiko bei der Azure DevOps Server-Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server zur Erhöhung von Berechtigungen.

Wichtig

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

Hinweis

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

Patches installieren

1. Herunterladen und Installieren von Azure DevOps Server 2020 Update 1.2 Patch 8.

Aktualisieren des Azure Pipelines-Agents

1. Laden Sie den Agent hier herunter: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. Führen Sie die in der Dokumentation zu selbst gehosteten Windows-Agents beschriebenen Schritte aus, um den Agent bereitzustellen.  

Hinweis

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

Konfigurieren von TFX

1. Führen Sie die Schritte in der Dokumentation zum Hochladen von Aufgaben in Projektsammlungen aus, um die Installation und Anmeldung mit TFX-CLI durchzuführen.

Aktualisieren von Aufgaben mithilfe von TFX

1. 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 2020 Update 1.2 Patch 7 Veröffentlichungsdatum: 8. August 2023

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

• CVE-2023-36869: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• Aktualisieren Sie den SSH-Dienst, um SHA2-256 und SHA2-512 zu unterstützen. Wenn Sie SSH-Konfigurationsdateien hartcodiert haben, um RSA zu verwenden, sollten Sie auf SHA2 aktualisieren oder den Eintrag entfernen.
• Es wurde ein Problem behoben, bei dem relative Links nicht in Markdowndateien funktionieren.
• Ein Fehler mit der Kommentarnavigation auf einer Commit-Seite wurde behoben.
• Ein Fehler wurde behoben, bei dem die Identität des Analysebesitzers als inaktive Identität angezeigt wurde.
• Es wurde ein Endlosschleifenfehler auf CronScheduleJobExtension behoben.

Azure DevOps Server 2020 Update 1.2 Patch 6 Veröffentlichungsdatum: 13. Juni 2023

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

• CVE-2023-21565: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• CVE-2023-21569: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• Es wurde ein Fehler behoben, der beim Upgrade von 2018 oder früheren Pushpaketen problemete.
• Ein Fehler wurde behoben, bei dem beim Trennen oder Anfügen der Auflistung der folgende Fehler gemeldet wurde: "TF246018: Der Datenbankvorgang hat das Timeoutlimit überschritten und wurde abgebrochen.

Azure DevOps Server 2020 Update 1.2 Patch 5 Veröffentlichungsdatum: 14. Februar 2023

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

• CVE-2023-21553: Sicherheitsanfälligkeit in Azure DevOps Server bezüglich Remotecodeausführung
• Problem mit der Barrierefreiheit von Regalen über die Web-UI behoben
• Kunden müssen den Tfsjobagent-Dienst und den Azure DevOps Server-Anwendungspool nach dem Aktualisieren der SMTP-bezogenen Einstellung in der Azure DevOps Server Management Console neu starten.

Azure DevOps Server 2020 Update 1.2 Patch 4 Veröffentlichungsdatum: 13. Dezember 2022

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

• Die Anzeige von Sonderzeichen im IdentityPicker wurde behoben.

• Testdaten wurden nicht gelöscht, wodurch die Datenbank vergrößert wurde. Mit diesem Fix haben wir die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.

Azure DevOps Server 2020 Update 1.2 Patch 3 Veröffentlichungsdatum: 18. Oktober 2022

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

• Beheben Sie das Problem mit neu hinzugefügten AD-Identitäten, die nicht in den Identitätsauswahlen des Sicherheitsdialogfelds angezeigt werden.
• Behebung eines Problems mit dem Vom Gruppenfilter angeforderten Mitglied in den Web-Hook-Einstellungen.
• Beheben Sie den Fehler bei Gated-Check-In-Builds, wenn die Organisationseinstellungen für die Pipeline den Auftragsautorisierungsbereich auf das aktuelle Projekt für Nicht-Release-Pipelines konfiguriert haben.
• Behebung des Abrufens von Zugriffstoken aus Azure beim Einrichten der Dienstverbindung hinter authentifizierten Proxys.

Azure DevOps Server 2020 Update 1.2 Patch 2 Veröffentlichungsdatum: 9. August 2022

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

• Beheben Sie den Identitätswertfehler beim Zuweisen einer Arbeitsaufgabe zu einer Identität, die in verschiedenen Domänen angezeigt wird.

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

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

• Bei Testausführungs-APIs war das zurückgegebene Fortsetzungstoken größer als der angegebene Wert "maxLastUpdatedDate".

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

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

Hinweis

Das Datenmigrationstool ist ungefähr drei Wochen nach dieser Version für Azure DevOps Server 2020 Update 1.2 verfügbar. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Diese Version enthält Korrekturen für Folgendes:

• Azure DevOps Server 2020.1.2 deaktiviert das neue Aufbewahrungsmodell (eingeführt in Azure DevOps Server 2020), um den Verlust von Pipelineausführungen (Builds) zu verhindern. Dies bedeutet, dass das System:

  • Erstellen von Leases für die neuesten 3 Builds, die beim Ausführen von Server 2020 generiert werden
  • Für YAML-Pipelines und klassische Pipelines ohne Aufbewahrungsrichtlinien pro Pipeline werden Builds entsprechend den maximalen Aufbewahrungseinstellungen auf Sammlungsebene beibehalten.
  • Bei klassischen Pipelines mit benutzerdefinierten Aufbewahrungsrichtlinien pro Pipeline werden Builds gemäß der pipelinespezifischen Aufbewahrungsrichtlinie beibehalten.
  • Die Builds mit Leases zählen nicht auf das Minimum, um die Einstellung beizubehalten.

• Changeset- und Regalsatzkommentarlinks wurden nicht ordnungsgemäß umgeleitet. Wenn Kommentare zu Dateien in Änderungenets oder Regalsätzen hinzugefügt wurden, wurden diese Kommentare nicht an die richtige Stelle in der Dateiansicht umgeleitet.

• Die Buildwarteschlange kann nicht über die Schaltfläche "Weiter ausführen" übersprungen werden. Zuvor wurde die Schaltfläche "Weiter ausführen" nur für Projektsammlungsadministratoren aktiviert.

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

Azure DevOps Server 2020.1.1 Patch 4 Veröffentlichungsdatum: 26. Januar 2022

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

• E-Mail-Benachrichtigungen wurden nicht gesendet, wenn sie das @mention Steuerelement in einer Arbeitsaufgabe verwenden.
• 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.
• Die Kopfzeile wurde auf der Projektzusammenfassungsseite nicht angezeigt. Die Kopfzeile wurde für einige Millisekunden angezeigt und dann verschwunden.
• Verbesserung der Active Directory-Benutzersynchronisierung.
• Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.

Installationsschritte

1. Aktualisieren Sie den Server mit Patch 4.
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 4.
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: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Veröffentlichungsdatum: 15. Dezember 2021

Patch 3 für Azure DevOps Server 2020.1.1 enthält Korrekturen für Folgendes.

• Beheben des Arbeitsaufgabenmakros für Abfragen mit "Enthält Wörter". Zuvor haben Abfragen falsche Ergebnisse für Werte zurückgegeben, die einen Zeilenumbruch enthielten.
• Erhöhen Sie die Grenzwerte für die Länge des Maven-Paketversionszeichens.
• Lokalisierungsproblem für benutzerdefinierte Arbeitsaufgabenlayoutzustände.
• Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
• Problem mit NOTSAMEAS-Regelauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

Azure DevOps Server 2020.1.1 Patch 2 Veröffentlichungsdatum: 26. Oktober 2021

Patch 2 für Azure DevOps Server 2020.1.1 enthält Korrekturen für Folgendes.

• Zuvor konnte Azure DevOps Server nur Verbindungen mit GitHub Enterprise Server erstellen. Mit diesem Patch können Projektadministratoren Verbindungen zwischen Azure DevOps Server und Repositorys auf GitHub.com erstellen. Diese Einstellung finden Sie auf der GitHub-Verbindungsseite unter "Project-Einstellungen".
• Beheben sie das Problem mit dem Testplan-Widget. Im Testausführungsbericht wurde ein falscher Benutzer zu Ergebnissen angezeigt.
• Behebung eines Problems mit der Zusammenfassungsseite "Projektübersicht" beim Laden.
• Behebung eines Problems mit E-Mails, die nicht gesendet werden, um das Produktupgrade zu bestätigen.

Azure DevOps Server 2020.1.1 Patch 1 Veröffentlichungsdatum: 14. September 2021

Patch 1 für Azure DevOps Server 2020.1.1 enthält Fixes für Folgendes.

• Fehler beim Herunterladen/Hochladen von Artefakten beheben.
• Behebung eines Problems mit inkonsistenten Testergebnissen.

Veröffentlichungsdatum von Azure DevOps Server 2020 Update 1.1: 17. August 2021

Azure DevOps Server 2020 Update 1.1 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020 Update 1.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder höher durchführen.

Hinweis

Das Datenmigrationstool ist ungefähr drei Wochen nach dieser Version für Azure DevOps Server 2020 Update 1.1 verfügbar. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

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

Azure Boards

• Der Link "Arbeitsaufgabe anzeigen" in den Benachrichtigungs-E-Mails verwendet nicht die öffentliche URL.

Azure Repos

• Es wurden die Kontrollkästchen für die Vererbung von beschränkten Zusammenführungstypen behoben, um nach dem Festlegen von Richtlinien für cross-reposity Limit-Zusammenführungstypen zu aktivieren.

Azure Pipelines

• Wenn Sie die Einstellung für die Agentaktualisierung ändern, wurden die Einstellungen nicht an andere Anwendungsebenen in der Umgebung weitergegeben.

Allgemein

• Die Rechtschreibung im Serverkonfigurations-Assistenten wurde behoben.
• Erhöhte Größe des Erweiterungspakets und ermöglichen es Ihnen, die Größe in der Registrierung zu ändern.

Azure Test Plans

• Sie können nicht zurück zu Testergebnissen navigieren, sobald Sie vom Verlauf zur Zusammenfassungsseite zurückkehren.

---

Azure DevOps Server 2020.1 Patch 2 Veröffentlichungsdatum: 10. August 2021

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

• Beheben des Fehlers der Builddefinitions-UI.
• Der Browserverlauf wurde geändert, um Dateien anstelle des Stamm-Repositorys anzuzeigen.

Azure DevOps Server 2020.1 Patch 1 Veröffentlichungsdatum: 15. Juni 2021

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

• Sichere Cookies, die in Autorisierungsflüssen verwendet werden, die bestätigen SameSite=None.

• Beheben sie das Problem mit dem Notifications SDK. Zuvor wurden Benachrichtigungsabonnements, die den Bereichspfadfilter verwenden, nicht ordnungsgemäß analysiert.

Azure DevOps Server 2020.1 RTW-Veröffentlichungsdatum: 25. Mai 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerbehebungen. Es enthält alle Features in azure DevOps Server 2020.1 RC2, die zuvor veröffentlicht wurden. Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2020, 2019 oder Team Foundation Server 2015 oder höher durchführen.

Hinweis

Das Datenmigrationstool ist ungefähr drei Wochen nach dieser Version für Azure DevOps Server 2020 Update 1 verfügbar. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Azure DevOps Server 2020.1 RC2 Veröffentlichungsdatum: 13. April 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features in azure DevOps Server 2020.1 RC1, die zuvor veröffentlicht wurden.

Veröffentlichungsdatum von Azure DevOps Server 2020.1 RC1: 23. März 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 führt viele neue Features ein. Einige der Highlights sind unter anderem:

• Regeln für Zustandsübergangseinschränkung in Boards
• Projektbeteiligte können jetzt Arbeitsaufgaben über Boardspalten verschieben
• Verbessern der Releasesicherheit durch Einschränken des Geltungsbereichs von Zugriffstoken
• Erweiterte Pullanforderungserfahrung
• Multi-Repo-Trigger in Pipelines

Sie können auch zu einzelnen Abschnitten springen, um alle neuen Features für jeden Dienst anzuzeigen:

• Boards
• Repos
• Pipelines
• Artefakte

---

Boards

Regeln für Zustandsübergangseinschränkung

Wir schließen weiterhin die Featureparitätslücke zwischen gehosteter XML und dem geerbten Prozessmodell. Mit dieser regel für arbeitsaufgabentyp können Sie einschränken, dass Arbeitsaufgaben von einem Zustand in einen anderen verschoben werden. Sie können z. B. verhindern, dass Fehler von "Neu" zu "Gelöst" wechseln. Stattdessen müssen sie von "Neu" –> "Aktiv" –> "Gelöst" wechseln.

Sie können auch eine Regel erstellen, um Statusübergänge nach Gruppenmitgliedschaft einzuschränken. Beispielsweise können nur Benutzer in der Gruppe "Genehmigende Personen" Benutzergeschichten aus "Neu –> Genehmigt" verschieben.

Kopieren einer Arbeitsaufgabe zum Kopieren untergeordneter Elemente

Eine der wichtigsten angeforderten Features für Azure Boards ist die Möglichkeit, eine Arbeitsaufgabe zu kopieren, die auch die untergeordneten Arbeitsaufgaben kopiert. Wir haben dem Dialogfeld "Arbeitsaufgabe kopieren" eine neue Option "Untergeordnete Arbeitsaufgaben einschließen" hinzugefügt. Wenn diese Option ausgewählt ist, wird die Arbeitsaufgabe kopiert und alle untergeordneten Arbeitsaufgaben (bis zu 100) kopiert.

Verbesserte Regeln für aktivierte und aufgelöste Felder

Bisher waren die Regeln für "Aktiviert von", "Aktiviert am", "Gelöst am" und "Gelöst am" ein Geheimnis. Sie werden nur für Systemaufgabentypen festgelegt und sind spezifisch für den Statuswert "Aktiv" und "Aufgelöst". Wir haben die Logik so geändert, dass diese Regeln nicht mehr für einen bestimmten Zustand gelten. Stattdessen werden sie durch die Kategorie (Statuskategorie) ausgelöst, in der sich der Zustand befindet. Angenommen, Sie haben in der Kategorie "Aufgelöst" den benutzerdefinierten Status "Anforderungen testen". Wenn sich die Arbeitsaufgabe von "Aktiv" in "Bedarfstests" ändert, werden die Regeln "Gelöst nach" und "Gelöst am" ausgelöst.

Auf diese Weise können Kunden benutzerdefinierte Statuswerte erstellen und weiterhin die Felder "Aktiviert nach", "Aktiviert am", "Aufgelöst von" und "Aufgelöstes Datum" generieren, ohne benutzerdefinierte Regeln verwenden zu müssen.

Projektbeteiligte können Arbeitsaufgaben über Boardspalten verschieben

Die Projektbeteiligten konnten den Status der Arbeitsaufgaben immer ändern. Wenn sie jedoch zum Kanban-Board wechseln, können sie die Arbeitsaufgaben nicht von einer Spalte in eine andere verschieben. Stattdessen müssten die Projektbeteiligten jede Arbeitsaufgabe einzeln öffnen und den Statuswert aktualisieren. Dies ist seit langem ein Schmerzpunkt für Kunden, und wir freuen uns, ihnen mitzuteilen, dass Sie jetzt Arbeitsaufgaben über Boardspalten verschieben können.

System-Arbeitselementtypen in Backlogs und Boards

Jetzt können Sie einen Systemarbeitselementtyp zur Backlog-Ebene der Wahl hinzufügen. In der Vergangenheit waren diese Arbeitsaufgabentypen nur in Abfragen verfügbar.

Prozess	Arbeitselementtyp
Agilität	Problem
Scrum	Impediment
CMMI	Änderungsanforderung
	Problem
	Überprüfung
	Risiko

Das Hinzufügen eines Systemarbeitselementtyps zu einer Backlog-Ebene ist einfach. Wechseln Sie einfach zu Ihrem benutzerdefinierten Prozess, und klicken Sie auf die Registerkarte "Backlog Levels". Wählen Sie Die Backlog-Ebene der Wahl aus (Beispiel: Anforderungsrückstand), und wählen Sie die Bearbeitungsoption aus. Fügen Sie dann den Arbeitsaufgabentyp hinzu.

Azure Boards GitHub-App-Repositorylimit erhöht

Das Repositorylimit für die Azure Boards-Anwendung im GitHub-Marketplace wurde von 100 auf 250 erhöht.

Anpassen des Arbeitselementstatus beim Mergen von Pull Requests

Nicht alle Workflows sind identisch. Einige Kunden möchten ihre zugehörigen Arbeitsaufgaben schließen, wenn eine Pullanforderung abgeschlossen ist. Andere Möchten die Arbeitsaufgaben auf einen anderen Zustand festlegen, der vor dem Schließen überprüft werden soll. Wir sollten beides zulassen.

Wir verfügen über ein neues Feature, mit dem Sie die Arbeitsaufgaben auf den gewünschten Zustand festlegen können, wenn die Pullanforderung zusammengeführt und abgeschlossen wird. Dazu scannen wir die Beschreibung der Pullanforderung und suchen nach dem Statuswert, gefolgt von der #mention der Arbeitsaufgabe(n). In diesem Beispiel legen wir zwei Benutzerabschnitte auf "Aufgelöst" und "Schließen von zwei Aufgaben" fest.

Arbeitselemente mit Builds aus einem anderen Projekt verknüpfen

Sie können ihre Buildabhängigkeiten jetzt ganz einfach über das gesamte Projekt hinweg nachverfolgen, indem Sie Ihre Arbeitsaufgabe mit einem Build, dem Build oder dem integrierten Build verknüpfen.

Beschreibungen (Hilfetexte) für Systemfelder bearbeiten

Sie konnten die Beschreibung von benutzerdefinierten Feldern immer bearbeiten. Für Systemfelder wie Priorität, Schweregrad und Aktivität war die Beschreibung jedoch nicht bearbeitbar. Dies war eine Featurelücke zwischen der gehosteten XML und geerbt, die verhinderte, dass einige Kunden zum geerbten Modell migrieren. Sie können nun die Beschreibung in Systemfeldern bearbeiten. Der bearbeitete Wert wirkt sich nur auf dieses Feld im Prozess und für diesen Arbeitsaufgabentyp aus. Dies bietet Ihnen die Flexibilität, unterschiedliche Beschreibungen für dasselbe Feld für verschiedene Arbeitsaufgabentypen zu haben.

Anpassen des Arbeitselementstatus beim Mergen von Pull Requests

Pullanforderungen beziehen sich häufig auf mehrere Arbeitsaufgaben. Wenn Sie eine Pullanforderung erstellen oder aktualisieren, möchten Sie möglicherweise einige davon schließen, einige davon auflösen und den Rest geöffnet lassen. Sie können jetzt Kommentare wie die in der abbildung unten gezeigten Kommentare verwenden, um dies zu erreichen. Weitere Informationen finden Sie in der Dokumentation.

Übergeordnetes Feld auf dem Task Board

Aufgrund der beliebten Anforderung können Sie jetzt das Feld "Übergeordnetes Element" sowohl den untergeordneten als auch den übergeordneten Karten im Task Board hinzufügen.

Entfernen der Regel "Zugewiesen an" für den Arbeitsaufgabentyp "Fehler"

Es gibt mehrere ausgeblendete Systemregeln für alle verschiedenen Arbeitsaufgabentypen in Agile, Scrum und CMMI. Diese Regeln sind seit über einem Jahrzehnt vorhanden und haben in der Regel ohne Beanstandungen in Ordnung gearbeitet. Es gibt jedoch eine Reihe von Regeln, die ihre Willkommensseite auslaufen. Eine Regel hat insbesondere für neue und bestehende Kunden viel Schmerz verursacht, und wir haben beschlossen, sie zu entfernen. Diese Regel ist im Agile-Prozess für den Arbeitsaufgabentyp "Fehler" vorhanden.

"Set the Assigned value to Created By when state is changed to Resolved"

Wir haben viele Ihr Feedback zu dieser Regel erhalten. Als Reaktion darauf haben wir diese Regel aus dem Arbeitsaufgabentyp "Fehler" im Agile-Prozess entfernt. Diese Änderung wirkt sich auf jedes Projekt aus, indem ein geerbter Agile- oder ein angepasster geerbter Agile-Prozess verwendet wird. Für Kunden, die diese aktuelle Regel mögen und davon abhängen, lesen Sie bitte unseren Blogbeitrag zu den Schritten, die Sie ausführen können, um die Regel mithilfe von benutzerdefinierten Regeln erneut hinzuzufügen.

Von der Seite „Arbeitselemente“ entfernte Elemente

Die Seite "Arbeitsaufgaben" ist ein großartiger Ort, um elemente, die Sie erstellt haben oder ihnen zugewiesen sind, unter anderem schnell zu finden. Sie stellt mehrere personalisierte Pivots und Filter bereit. Eine der wichtigsten Beschwerden für den Pivot "Zugewiesen an mich" besteht darin, dass entfernte Arbeitsaufgaben angezeigt werden (d. a. Arbeitsaufgaben im Status "Entfernt"). Und wir stimmen zu! Entfernte Elemente sind nicht mehr wertlos und wurden daher aus dem Backlog entfernt, sodass es in dieser Ansicht nicht hilfreich ist.

Jetzt können Sie alle entfernten Elemente aus dem Pivot "Zugewiesen für mich" auf der Seite "Arbeitselemente" ausblenden.

Repos

Standardeinstellung für Verzweigungsnamen

Azure Repos bietet jetzt einen anpassbaren Standardbranch Namen für Git. In Repositoryeinstellungen können Sie einen beliebigen Legal Branch-Namen auswählen, der verwendet werden soll, wenn ein Repository initialisiert wird. Azure Repos hat immer das Ändern des Standardbranch Namens für ein vorhandenes Repository unterstützt.

Weitere Informationen finden Sie unter Verwalten von Verzweigungen und Ändern des Standardbranch.

Einstellung auf Organisationsebene für Standardbranch

Es gibt jetzt eine Einstellung auf Sammlungsebene für Den bevorzugten ursprünglichen Branchnamen für neue Repositorys. Wenn ein Projekt keinen ursprünglichen Verzweigungsnamen ausgewählt hat, wird diese Einstellung auf Organisationsebene verwendet. Wenn Sie den ursprünglichen Branchnamen nicht in den Organisationseinstellungen oder den Projekteinstellungen angegeben haben, verwenden neue Repositorys einen von Azure DevOps definierten Standardwert.

Neuer Authentifizierungsbereich für das Hinzufügen von PR-Kommentaren

Diese Version fügt einen neuen OAuth-Bereich zum Lesen/Schreiben von Pullanforderungskommentaren hinzu. Wenn Sie über einen Bot oder eine Automatisierung verfügen, der nur mit Kommentaren interagieren muss, können Sie ihm nur einen PAT mit diesem Bereich geben. Dieser Prozess reduziert den Strahlradius, wenn die Automatisierung einen Fehler aufweist oder wenn das Token kompromittiert wurde.

Verbesserungen bei der Pullanforderung

Die neue Pull-Anforderungsumgebung wurde mit den folgenden Verbesserungen verbessert:

• Aktivieren der optionalen Überprüfungen

Kunden verwenden optionale Prüfungen, um die Aufmerksamkeit eines Entwicklers auf potenzielle Probleme zu lenken. In der vorherigen Erfahrung war es offensichtlich, wenn diese Prüfungen fehlschlagen. Dies ist jedoch nicht der Fall in der Vorschauumgebung. Ein großes grünes Häkchen für die erforderlichen Kontrollen maskiert die Fehler in optionalen Prüfungen. Benutzer konnten nur feststellen, dass optionale Überprüfungen fehlgeschlagen sind, indem sie das Gremium öffnen. Entwickler tun das nicht oft, wenn kein Hinweis auf ein Problem vorliegt. In dieser Bereitstellung haben wir den Status optionaler Überprüfungen in der Zusammenfassung sichtbarer gemacht.

• Strg-Klicks auf Menüelemente

Registerkartenmenüs in einer PR haben strg-klick nicht unterstützt. Benutzer öffnen häufig neue Browserregisterkarten, während sie eine Pull-Anforderung überprüfen. Dies wurde behoben.

• Position der [+] Anmerkung

Die Strukturauflistung von Dateien in einer PR zeigt eine Anmerkung [+] an, mit der Autoren und Bearbeiter neue Dateien identifizieren können. Da die Anmerkung hinter den Auslassungspunkten lag, war sie für längere Dateinamen oft nicht sichtbar.

• Dropdown für PR-Updates erhalten Zeitangaben wieder

Die Dropdownliste zum Auswählen von Aktualisierungen und Vergleichen von Dateien in einer PR hat ein wichtiges Element in der Vorschauumgebung verloren. Es wurde nicht angezeigt, wann diese Aktualisierung vorgenommen wurde. Dies wurde behoben.

• **Verbessertes Kommentarfilterlayout **

Beim Filtern von Kommentaren auf der Zusammenfassungsseite einer Pullanforderung befand sich die Dropdownliste auf der rechten Seite, der Text wurde jedoch linksbündig ausgerichtet. Dies wurde behoben.

• Navigation zu übergeordneten Commits

Auf der Seite "Commits" können Sie die in einem bestimmten Commit vorgenommenen Änderungen mit dem übergeordneten Commit vergleichen. Möglicherweise möchten Sie jedoch zum übergeordneten Commit navigieren und weiter verstehen, wie sich dieser Commit von seinem eigenen Übergeordneten unterscheidet. Dies ist häufig erforderlich, wenn Sie alle Änderungen in einer Version verstehen möchten. Wir haben eine Übergeordnete(n) Karte zu einem Commit hinzugefügt, um Dies zu erreichen.

• Mehr Platz für Ordner und Dateien mit langen Namen auf der Registerkarte „PR-Dateien“

Ordner und Dateien mit langen Namen wurden aufgrund eines fehlenden horizontalen Abstands in der Dateistruktur abgeschnitten. Wir haben zusätzlichen Platz in der Struktur wiederhergestellt, indem wir den Einzug der Struktur so ändern, dass er dem Stammknoten entspricht, und indem wir die Schaltfläche mit den Auslassungszeichen auf der Seite ausblenden, außer beim Daraufzeigen.

Abbildung der neuen Dateistruktur:

Abbildung der Dateistruktur beim Daraufzeigen über ein Verzeichnis:

• Beibehalten der Scrollposition beim Ändern der Größe des Diff-Bereichs auf der Registerkarte „PR-Dateien“

Wenn Sie die Größe des Seiten-für-Seiten-Diff-Bereichs auf der Registerkarte "PR-Dateien" ändern, geht der Bildlaufspeicherort des Benutzers verloren. Dieses Problem wurde behoben; Die Bildlaufposition des Benutzers wird jetzt in einem Diff-Bereich beibehalten, deren Größe geändert wird.

• Suchen von Commits auf einem mobilen Gerät

Wenn Sie die Commits-Seite auf einem mobilen Gerät anzeigen, fehlt das Suchfeld in der neuen Oberfläche. Daher ist es schwierig, einen Commit durch seinen Hash zu finden und es zu öffnen. Dies wurde jetzt behoben.

• Verbesserte Nutzung von Speicherplatz bei der neuen Diff-Ansicht für PR-Dateien auf mobilen Geräten

Wir haben diese Seite aktualisiert, um den Platz besser zu nutzen, damit Benutzer mehr Der Datei in mobilen Ansichten sehen können, anstatt 40 % des Bildschirms von einer Kopfzeile aufgenommen zu haben.

• Erweiterte Bilder in der Pr-Zusammenfassungsansicht

Bilder, die in einer PR bearbeitet wurden, wurden nicht in der PR-Zusammenfassungsansicht angezeigt, aber in der Ansicht der PR-Dateien richtig angezeigt. Dieses Problem wurde behoben.

• Optimierte Nutzung von Branches beim Erstellen eines neuen PR

Vor diesem Update war diese Erfahrung nicht ideal, da sie die Änderungen mit dem Standardbranch des Repositorys anstelle der Vergleichsbranch vergleichen würde.

Pipelines

Zusätzliche Agent-Plattform: ARM64

Wir haben Linux/ARM64 zur Liste der unterstützten Plattformen für den Azure Pipelines-Agent hinzugefügt. Obwohl die Codeänderungen minimal waren, mussten viele Hintergrundarbeiten zuerst abgeschlossen werden, und wir freuen uns, ihre Veröffentlichung anzukündigen!

Unterstützung für Tagfilter für Pipeline-Ressourcen

Wir haben jetzt "Tags" in YAML-Pipelines hinzugefügt. Sie können Tags verwenden, um die CI-Pipeline so festzulegen, dass sie ausgeführt wird oder wann sie automatisch ausgelöst wird.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Der obige Codeausschnitt zeigt, dass Tags verwendet werden können, um die Standardversion der CI-Pipeline (fortlaufende Integration) zu ermitteln, die ausgeführt werden soll, wenn die Pipelineausführung der CD (fortlaufende Bereitstellung) nicht von einer anderen Quelle/Ressource oder einem geplanten Ausführungsauslöser ausgelöst wird.

Wenn beispielsweise ein geplanter Trigger für Ihre CD-Pipeline festgelegt ist, die nur ausgeführt werden soll, wenn Ihr CI über das Produktionstag verfügt, stellen die Tags im Triggerabschnitt sicher, dass die CD-Pipeline nur ausgelöst wird, wenn die Taggingbedingung vom CI-Abschlussereignis erfüllt ist.

Steuern zulässiger Aufgaben in Pipelines

Jetzt können Sie Marketplace-Aufgaben deaktivieren. Einige von Ihnen können Marketplace-Erweiterungen zulassen, aber nicht die Pipelines-Aufgaben, die sie mitbringen. Um noch mehr Kontrolle zu haben, können Sie auch unabhängig alle Aufgaben im Feld deaktivieren (mit Ausnahme des Auscheckens, was eine spezielle Aktion ist). Wenn beide Einstellungen aktiviert sind, wären die einzigen Aufgaben, die in einer Pipeline ausgeführt werden dürfen, die mit tfx hochgeladen wurden. Besuchen Sie https://dev.azure.com/<your_org>/_settings/pipelinessettings den Abschnitt mit dem Namen "Aufgabeneinschränkungen", um zu beginnen.

Exklusive Bereitstellungssperresrichtlinie

Mit diesem Update können Sie sicherstellen, dass jeweils nur eine einzelne Ausführung in einer Umgebung bereitgestellt wird. Wenn Sie die "Exklusive Sperre" für eine Umgebung auswählen, wird nur eine Ausführung fortgesetzt. Nachfolgende Ausführungen, die in dieser Umgebung bereitgestellt werden sollen, werden angehalten. Sobald die Ausführung mit der exklusiven Sperre abgeschlossen ist, wird die neueste Ausführung fortgesetzt. Alle Zwischenläufe werden abgebrochen.

Phasenfilter für Pipelineressourcentrigger

Wir haben Unterstützung für "Phasen" als Filter für Pipelineressourcen in YAML hinzugefügt. Mit diesem Filter müssen Sie nicht warten, bis die gesamte CI-Pipeline abgeschlossen ist, um die CD-Pipeline auszulösen. Sie können ihre CD-Pipeline jetzt nach Abschluss einer bestimmten Phase in Ihrer CI-Pipeline auslösen.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Wenn die im Triggerfilter bereitgestellten Phasen in Ihrer CI-Pipeline erfolgreich abgeschlossen werden, wird automatisch eine neue Ausführung für Ihre CD-Pipeline ausgelöst.

Generische Webhook-basierte Trigger für YAML-Pipelines

Heute verfügen wir über verschiedene Ressourcen (z. B. Pipelines, Container, Build und Pakete), über die Sie Artefakte nutzen und automatisierte Trigger aktivieren können. Bisher konnten Sie Ihren Bereitstellungsprozess jedoch nicht basierend auf anderen externen Ereignissen oder Diensten automatisieren. In dieser Version führen wir die Unterstützung von Webhook-Triggern in YAML-Pipelines ein, um die Integration der Pipelineautomatisierung mit jedem externen Dienst zu ermöglichen. Sie können externe Ereignisse über ihre Webhooks (Github, Github Enterprise, Nexus, Aritfactory usw.) abonnieren und Ihre Pipelines auslösen.

Hier sind die Schritte zum Konfigurieren der Webhook-Trigger:

1. Richten Sie einen Webhook für Ihren externen Dienst ein. Beim Erstellen ihres Webhooks müssen Sie die folgenden Informationen angeben:

   • Anforderungs-URL - "ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"https://dev.azure.com/<
   • Geheim – Dies ist optional. Wenn Sie Ihre JSON-Nutzlast sichern müssen, geben Sie den Geheimwert an.

2. Erstellen Sie eine neue Dienstverbindung vom Typ „Eingehender Webhook“. Dies ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie drei wichtige Informationen definieren können:

   • Webhookname: Der Name des Webhooks sollte dem in Ihrem externen Dienst erstellten Webhook entsprechen.
   • HTTP-Header – Der Name des HTTP-Headers in der Anforderung, der den Nutzlasthashwert für die Anforderungsüberprüfung enthält. Im Fall von GitHub lautet der Anforderungsheader beispielsweise "X-Hub-Signature"
   • Geheimer Schlüssel – Der geheime Schlüssel wird verwendet, um den Nutzlasthash zu analysieren, der zur Überprüfung der eingehenden Anforderung verwendet wird (dies ist optional). Wenn Sie beim Erstellen Ihres Webhooks einen geheimen Schlüssel verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.

   

3. Ein neuer Ressourcentyp namens webhooks wird in YAML-Pipelines eingeführt. Zum Abonnieren eines Webhook-Ereignisses müssen Sie eine Webhook-Ressource in Ihrer Pipeline definieren und auf die Eingehende Webhook-Dienstverbindung verweisen. Sie können auch zusätzliche Filter für die Webhook-Ressource basierend auf den JSON-Nutzlastdaten definieren, um die Trigger für jede Pipeline weiter anzupassen, und Sie können die Nutzlastdaten in Form von Variablen in Ihren Aufträgen verwenden.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Wenn ein Webhook-Ereignis von der Eingehenden Webhook-Dienstverbindung empfangen wird, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhook-Ereignis abonniert haben.

Unterstützung und Nachverfolgbarkeit bei YAML-Ressourcentriggerproblemen

Es kann verwirrend sein, wenn Pipelinetrigger nicht ausgeführt werden, wie sie erwartet werden. Um dies besser zu verstehen, haben wir ein neues Menüelement auf der Pipelinedefinitionsseite namens "Trigger Issues" hinzugefügt, bei dem Informationen dazu angezeigt werden, warum Trigger nicht ausgeführt werden.

Ressourcentrigger können aus zwei Gründen nicht ausgeführt werden.

1. Wenn die Quelle der bereitgestellten Dienstverbindung ungültig ist oder syntaxfehler im Trigger vorhanden sind, wird der Trigger überhaupt nicht konfiguriert. Diese werden als Fehler angezeigt.

2. Wenn Triggerbedingungen nicht übereinstimmen, wird der Trigger nicht ausgeführt. Wenn dies geschieht, wird eine Warnung angezeigt, damit Sie verstehen können, warum die Bedingungen nicht übereinstimmen.

   

Multi-Repo-Trigger

Sie können mehrere Repositorys in einer YAML-Datei angeben und dazu führen, dass eine Pipeline durch Aktualisierungen an einem der Repositorys ausgelöst wird. Dieses Feature ist z. B. in den folgenden Szenarien nützlich:

• Sie nutzen ein Tool oder eine Bibliothek aus einem anderen Repository. Sie möchten Tests für Ihre Anwendung ausführen, sobald das Tool oder die Bibliothek aktualisiert wird.
• Sie bewahren Ihre YAML-Datei in einem Repository auf, das vom Anwendungscode getrennt ist. Sie möchten die Pipeline immer dann auslösen, wenn ein Update in das Anwendungsrepository gepusht wird.

Mit diesem Update funktionieren Multi-Repository-Trigger nur für Git-Repositorys in Azure Repos. Sie funktionieren nicht für GitHub- oder BitBucket-Repositoryressourcen.

Hier ist ein Beispiel, das zeigt, wie Sie mehrere Repositoryressourcen in einer Pipeline definieren und trigger für alle konfigurieren.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Die Pipeline in diesem Beispiel wird ausgelöst, wenn Aktualisierungen vorhanden sind:

• main Verzweigung im self Repository, das die YAML-Datei enthält
• main oder release Verzweigungen im tools Repository

Weitere Informationen finden Sie unter "Mehrere Repositorys in Ihrer Pipeline".

Verbesserte Uploads von Agent-Protokollen

Wenn ein Agent die Kommunikation mit dem Azure Pipelines-Server beendet, wird der Auftrag, der ausgeführt wurde, abgebrochen. Wenn Sie sich die Streamingkonsolenprotokolle ansehen, haben Sie möglicherweise einige Hinweise darauf erhalten, was der Agent gerade war, bevor er nicht mehr reagierte. Wenn Sie die Seite aber nicht aktualisiert haben, wurden diese Konsolenprotokolle nicht mehr angezeigt. Wenn der Agent nicht mehr reagiert, bevor er die vollständigen Protokolle sendet, werden die Konsolenprotokolle als nächstes beibehalten. Konsolenprotokolle sind auf 1000 Zeichen pro Zeile beschränkt und können gelegentlich unvollständig sein, aber sie sind viel hilfreicher, als nichts anzuzeigen! Das Untersuchen dieser Protokolle kann Ihnen bei der Problembehandlung ihrer eigenen Pipelines helfen, und es hilft unseren Supporttechnikern, wenn sie bei der Problembehandlung helfen.

Optionales Einbinden schreibgeschützter Containervolumes

Wenn Sie einen Containerauftrag in Azure Pipelines ausführen, werden mehrere Volumes, die den Arbeitsbereich, aufgaben und andere Materialien enthalten, als Volumes zugeordnet. Diese Volumes verwenden standardmäßig Lese-/Schreibzugriff. Um die Sicherheit zu erhöhen, können Sie die Volumes schreibgeschützt bereitstellen, indem Sie ihre Containerspezifikation in YAML ändern. Jeder Schlüssel unter mountReadOnly kann für schreibgeschützt festgelegt true werden (der Standardwert ist false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Präzise Kontrolle über das Starten und Beenden von Containern

Im Allgemeinen wird empfohlen, Azure Pipelines das Verwalten des Lebenszyklus Ihrer Auftrags- und Dienstcontainer zu ermöglichen. In einigen ungewöhnlichen Szenarien können Sie jedoch anfangen und sie selbst beenden. Mit dieser Version haben wir diese Funktion in die Docker-Aufgabe integriert.

Hier ist eine Beispielpipeline mit der neuen Funktion:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Außerdem fügen wir die Liste der Container in eine Pipelinevariable ein. Agent.ContainerMapping Sie können dies verwenden, wenn Sie beispielsweise die Liste der Container in einem Skript prüfen möchten. Es enthält eine zeichenfolgenbasierte JSON-Objektzuordnung des Ressourcennamens ("Generator" aus dem obigen Beispiel) zu der Container-ID, die der Agent verwaltet.

Entpacken von Taskbundles für die einzelnen Schritte

Wenn der Agent einen Auftrag ausführt, lädt er zunächst alle Aufgabenbundle herunter, die von den Schritten des Auftrags benötigt werden. Normalerweise entpackt sie die Vorgänge einmal pro Auftrag, auch wenn der Vorgang in mehreren Schritten verwendet wird. Wenn Sie Bedenken haben, dass nicht vertrauenswürdiger Code den entzippten Inhalt ändert, können Sie ein wenig Leistung abwenden, indem Sie die Aufgabe für jede Verwendung entzippen. Um diesen Modus zu aktivieren, übergeben Sie beim --alwaysextracttask Konfigurieren des Agents.

Verbessern der Releasesicherheit durch Einschränken des Geltungsbereichs von Zugriffstoken

Basierend auf unserer Initiative zur Verbesserung der Sicherheitseinstellungen für Azure Pipelines unterstützen wir jetzt das Einschränken des Umfangs von Zugriffstoken für Versionen.

Jeder Auftrag, der in Versionen ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und von Ihren Skripts verwendet, um in Azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken zum Abrufen von Quellcode, Herunterladen von Artefakten, Hochladen von Protokollen, Testergebnissen oder zum Durchführen von REST-Aufrufen in Azure DevOps. Ein neues Zugriffstoken wird für jeden Auftrag generiert und läuft nach Abschluss des Auftrags ab.

Mit diesem Update bauen wir auf der Verbesserung der Pipelinesicherheit auf, indem wir den Umfang von Zugriffstoken einschränken und dasselbe auf klassische Versionen erweitern.

Dieses Feature ist standardmäßig für neue Projekte und Sammlungen aktiviert. Für vorhandene Sammlungen müssen Sie sie in den Einstellungen für Die Pipelineseinstellungen > der Sammlung > aktivieren. > Beschränken Sie den Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelinen. Hiererhalten Sie weitere Informationen.

Verbesserungen an der YAML-API (Vorschauversion)

Sie können jetzt eine Vorschau des vollständigen YAML einer Pipeline anzeigen, ohne sie auszuführen. Darüber hinaus haben wir eine dedizierte neue URL für die Vorschaufunktion erstellt. Jetzt können Sie POST senden, um https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview den endgültigen YAML-Text abzurufen. Diese neue API verwendet dieselben Parameter wie das Warteschlangen einer Ausführung, erfordert aber nicht mehr die Berechtigung "Warteschlangenbuilds".

Diesen Auftrag als Nächstes ausführen

Haben Sie jemals ein Bugfix gehabt, das Sie für die Bereitstellung in dieser Minute benötigt haben, aber hinter CI- und PR-Aufträgen warten mussten? Mit dieser Version können Sie jetzt die Priorität eines in die Warteschlange eingereihten Auftrags stoßen. Benutzer mit der Berechtigung "Verwalten" im Pool – in der Regel Pooladministratoren – werden auf der Seite mit den Auftragsdetails eine neue Schaltfläche "Weiter ausführen" angezeigt. Wenn Sie auf die Schaltfläche klicken, wird der Auftrag so schnell wie möglich ausgeführt. (Natürlich benötigen Sie immer noch Parallelität und einen geeigneten Agenten.)

Vorlagenausdrücke, die im YAML-Block resources zulässig sind

Zuvor waren Kompilierungszeitausdrücke (${{ }}) im resources Abschnitt einer YaML-Datei von Azure Pipelines nicht zulässig. Mit dieser Version haben wir diese Einschränkung für Container aufgehoben. Auf diese Weise können Sie Laufzeitparameterinhalte innerhalb Ihrer Ressourcen verwenden, z. B. um einen Container zur Warteschlangenzeit zu wählen. Wir planen, diese Unterstützung im Laufe der Zeit auf andere Ressourcen zu erweitern.

Automatisierte Taskupdates über Marketplace steuern

Wenn Sie eine YAML-Pipeline schreiben, geben Sie normalerweise nur die Hauptversionsnummer der enthaltenen Vorgänge an. Auf diese Weise können Ihre Pipelines automatisch die neuesten Featureerweiterungen und Fehlerbehebungen übernehmen. Gelegentlich müssen Sie ein Rollback auf eine vorherige Point Release einer Aufgabe durchführen, und mit diesem Update haben wir ihnen die Möglichkeit hinzugefügt, dies zu tun. Sie können jetzt eine vollständige Major.minor.patch-Taskversion in Ihren YAML-Pipelines angeben.

Es wird nicht empfohlen, dies regelmäßig zu tun und nur als temporäre Problemumgehung zu verwenden, wenn Sie feststellen, dass eine neuere Aufgabe Ihre Pipelines umbricht. Außerdem wird dadurch keine ältere Version einer Aufgabe aus dem Marketplace installiert. Sie muss bereits in Ihrer Sammlung vorhanden sein, oder Ihre Pipeline schlägt fehl.

Beispiel:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Node 10-Unterstützung in Agent und Aufgaben

Da Node 6 nicht mehr unterstützt wird, migrieren wir die Aufgaben für die Arbeit mit Node 10. Für dieses Update haben wir fast 50 % der Box-Aufgaben zu Node 10 migriert. Der Agent kann jetzt sowohl Node 6- als auch Node 10-Aufgaben ausführen. In einem zukünftigen Update werden wir Node 6 vollständig aus dem Agent entfernen. Um die Entfernung von Node 6 aus dem Agent vorzubereiten, fordern wir, dass Sie Ihre internen Erweiterungen und benutzerdefinierten Aufgaben aktualisieren, um Node 10 bald auch zu verwenden. Um Node 10 für Ihre Aufgabe zu verwenden, aktualisieren Sie in Ihrem task.jsonUnterbereich executionvon Node Node10

Verbesserte YAML-Konvertierung im klassischen Build-Designer

Mit dieser Version stellen wir ein neues Feature "Export in YAML" für Designerbuildpipelinen vor. Speichern Sie Ihre Pipelinedefinition, und suchen Sie dann im Menü nach "In YAML exportieren" ... .

Die neue Exportfunktion ersetzt die Funktion "Als YAML anzeigen", die zuvor im klassischen Build-Designer gefunden wurde. Diese Funktion war unvollständig, da sie nur überprüfen konnte, was die Web-UI über den Build wusste, was manchmal dazu führte, dass falsche YAML generiert wurde. Die neue Exportfunktion berücksichtigt genau, wie die Pipeline verarbeitet wird, und generiert YAML mit voller Genauigkeit für die Designerpipeline.

Neue Webplattformkonvertierung – Repositoryeinstellungen

Wir haben die beiden Repository-Einstellungsseiten in eine einzige Oberfläche konvertiert, die auf eine neue Webplattform aktualisiert wurde. Durch dieses Upgrade wird die Benutzererfahrung nicht nur schneller und moderner, sondern auch auf diesen Seiten ein einziger Einstiegspunkt für alle Richtlinien von der Projektebene bis zur Verzweigungsebene bereitgestellt.

Mit dieser neuen Oberfläche ist die Navigation für Projekte mit einer erheblichen Anzahl von Repositorys aufgrund schnellerer Ladezeiten und eines hinzugefügten Suchfilters einfacher geworden. Sie können auch Richtlinien auf Projektebene und die Liste der repositoryübergreifenden Richtlinien auf der Registerkarte "Richtlinien" anzeigen.

Wenn Sie in ein Repository klicken, können Sie Richtlinien und Berechtigungen anzeigen, die auf Repositoryebene festgelegt sind. Auf der Registerkarte "Richtlinien" können Sie eine Liste aller Verzweigung anzeigen, für die die Richtlinie festgelegt ist. Klicken Sie nun auf die Verzweigung, um die Richtlinien anzuzeigen, ohne die Seite "Repositoryeinstellungen" zu verlassen.

Wenn Richtlinien nun von einem höheren Bereich geerbt werden als mit dem, mit dem Sie arbeiten, zeigen wir Ihnen, wo die Richtlinie neben jeder einzelnen Richtlinie geerbt wurde. Sie können auch zu der Seite navigieren, auf der die Richtlinie auf höherer Ebene festgelegt wurde, indem Sie auf den Bereichsnamen klicken.

Die Richtlinienseite selbst wurde auch auf die neue Webplattform mit reduzierbaren Abschnitten aktualisiert! Um die Erfahrung der Suche nach einer bestimmten Buildüberprüfungs-, Statusüberprüfungs- oder automatischen Prüferrichtlinie zu verbessern, haben wir Suchfilter für jeden Abschnitt hinzugefügt.

Change Management-Integration mit YAML-Pipelines über ServiceNow

Die Azure Pipelines-App für ServiceNow hilft Ihnen bei der Integration von Azure Pipelines und ServiceNow Change Management. Mit diesem Update unternehmen wir unseren Weg, Azure Pipelines über den in ServiceNow verwalteten Änderungsmanagementprozess weiter zu YAML-Pipelines zu machen.

Indem Sie die Überprüfung "ServiceNow Change Management" für eine Ressource konfigurieren, können Sie jetzt anhalten, dass die Änderung genehmigt wird, bevor Sie den Build für diese Ressource bereitstellen. Sie können automatisch eine neue Änderung für eine Phase erstellen oder auf eine vorhandene Änderungsanforderung warten.

Sie können die UpdateServiceNowChangeRequest Aufgabe auch in einem Serverauftrag hinzufügen, um die Änderungsanforderung mit Dem Bereitstellungsstatus, Notizen usw. zu aktualisieren.

Artifacts

Möglichkeit zum Erstellen von organisationsbezogenen Feeds über die Benutzeroberfläche

Wir bringen die Möglichkeit für Kunden zurück, sammlungsbezogene Feeds über die Webbenutzeroberfläche sowohl für lokale als auch für gehostete Dienste zu erstellen und zu verwalten.

Sie können jetzt organisationsbezogene Feeds über die Benutzeroberfläche erstellen, indem Sie zu Artefakte> – Feed erstellen und einen Feedtyp im Bereich auswählen.

Es wird zwar empfohlen, die Verwendung von projektbezogenen Feeds in Übereinstimmung mit den restlichen Azure DevOps-Angeboten zu verwenden, Sie können aber auch wieder sammlungsbezogene Feeds über die Benutzeroberfläche und verschiedene REST-APIs erstellen, verwalten und verwenden. Weitere Informationen finden Sie in unserer Feeds-Dokumentation.

REST-API für Updatepaketversionen jetzt für Maven-Pakete verfügbar

Sie können jetzt die REST-API für Azure Artifacts "Update Package Version" verwenden, um Maven-Paketversionen zu aktualisieren. Zuvor konnten Sie die REST-API verwenden, um Paketversionen für NuGet-, Maven-, npm- und Universelle Pakete, aber nicht für Maven-Pakete zu aktualisieren.

Verwenden Sie zum Aktualisieren von Maven-Paketen den BEFEHL HTTP PATCH wie folgt.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Sie können Folgendes festlegen:

URI-Parameter

Name	In	Erforderlich	Typ	Beschreibung
artifactId	path	TRUE	Zeichenfolge	Artefakt-ID des Pakets
feed	path	TRUE	Zeichenfolge	Name oder ID des Feeds
groupId	path	TRUE	Zeichenfolge	Gruppen-ID des Pakets
collection	path	TRUE	Zeichenfolge	Der Name der Azure DevOps-Sammlung
version	path	TRUE	Zeichenfolge	Version des Pakets
project	path		Zeichenfolge	Projekt-ID oder Projektname
api-version	Abfrage	TRUE	Zeichenfolge	Version der zu verwendenden API. Dies sollte auf "5.1-preview.1" festgelegt werden, um diese Version der API zu verwenden.

Anforderungstext

Name	Art	Beschreibung
views	JsonPatchOperation	Die Ansicht, zu der die Paketversion hinzugefügt wird

Weitere Informationen finden Sie in der REST-API-Dokumentation , sobald sie aktualisiert wird.

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