Versionshinweise zu Azure DevOpsServer 2020 Update 1

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

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

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

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

---

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

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

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

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

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

• Es wurde ein Problem 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:

• Es wurde ein Fehler 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 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 Sicherheitsvererbung vor der Bereitstellungsgenehmigung in Pipelinephasen 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.

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

Hinweis

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

Patches installieren

Wichtig

Wir haben Updates für den Azure Pipelines-Agent mit Patch 8 veröffentlicht, der am 12. September 2023 veröffentlicht wurde. Wenn Sie die Agent-Updates nicht wie in den Versionshinweisen für Patch 8 beschrieben installiert haben, wird empfohlen, 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 die Projektsammlung aus, um sie zu installieren und sich mit tfx-cli anzumelden.

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED034D2E5

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 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 Agent-Updates nicht wie in den Versionshinweisen für Patch 8 beschrieben installiert haben, wird empfohlen, 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.

• Es wurde ein Fehler 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: Azure DevOps Server Sicherheitsanfälligkeit bezüglich Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server

Wichtig

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

Hinweis

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

Patches installieren

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

Aktualisieren des Azure Pipelines-Agents

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

Hinweis

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

Konfigurieren von TFX

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

Aktualisieren von Aufgaben mithilfe von TFX

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 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: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Aktualisieren Sie den SSH-Dienst, um SHA2-256 und SHA2-512 zu unterstützen. Wenn Sie SSH-Konfigurationsdateien für die Verwendung von RSA hart codiert haben, sollten Sie auf SHA2 aktualisieren oder den Eintrag entfernen.
• Problem behoben, bei dem relative Links in Markdowndateien nicht funktionieren.
• Ein Fehler mit der Kommentarnavigation auf einer Commitseite wurde behoben.
• Es wurde ein Fehler behoben, bei dem die Identität des Analysebesitzers als inaktive Identität angezeigt wurde.
• Endlosschleifenfehler bei 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: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• CVE-2023-21569: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Es wurde ein Fehler behoben, der das Pushen von Paketen beim Upgrade von 2018 oder früher beeinträchtigt hat.
• Es wurde ein Fehler behoben, bei dem das Trennen oder Anfügen der Sammlung den folgenden Fehler meldete: "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: Sicherheitsrisiko Azure DevOps Server Remotecodeausführung
• Problem mit der Barrierefreiheit von Regalen über die Web-Benutzeroberfläche behoben
• Kunden müssen den tfsjobagent-Dienst neu starten und Azure DevOps Server Anwendungspools nach dem Aktualisieren der SMTP-bezogenen Einstellung in der Azure DevOps Server Verwaltungskonsole 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, sodass die Datenbank vergrößert wurde. Mit diesem Fix wurde 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 der Identitätsauswahl des Sicherheitsdialogs angezeigt werden.
• Beheben Sie ein Problem mit dem Filter "Angefordert nach Mitglied der Gruppe" in den Web-Hook-Einstellungen.
• Fehler bei Gated-Check-In-Builds behoben, wenn die Organisationseinstellungen für die Pipeline den Auftragsautorisierungsbereich als Auftragsautorisierungsbereich auf das aktuelle Projekt für Pipelines ohne Release beschränken konfiguriert hatten.
• Beheben Des Abrufens des Zugriffstokens aus Azure beim Herstellen einer Dienstverbindung hinter einem authentifizierten Proxy.

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 eines Arbeitselements 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.

• In 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 wird für Azure DevOps Server 2020 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:

• 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 Folgendes übernimmt:

  • Erstellen von Leases für die neuesten 3 Builds, die beim Ausführen von Server 2020 generiert wurden
  • Für YAML-Pipelines und klassische Pipelines ohne Aufbewahrungsrichtlinien pro Pipeline werden Builds gemäß 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 werden nicht auf das Minimum angerechnet, um weiterhin festzulegen.

• Changeset- und Shelvesetkommentarlinks wurden nicht ordnungsgemäß umgeleitet. Wenn Kommentare zu Dateien in Changesets oder Shelvesets hinzugefügt wurden, wurden diese Kommentare nicht an die richtige Stelle in der Dateiansicht weitergeleitet.

• Buildwarteschlange kann nicht über die Schaltfläche "Weiter ausführen" überspringen. Zuvor war 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 Releasedatum: 26. Januar 2022

Wir haben einen Patch für Azure DevOps Server 2020.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.
• Die Kopfzeile wurde auf der Seite Projektzusammenfassung nicht angezeigt. Der Header wurde einige Millisekunden lang angezeigt und ist 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.

• 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.
• Erhöhen Sie die Grenzwerte für die Zeichenlänge der Maven-Paketversion.
• 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 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.

• Bisher konnten Azure DevOps Server nur Verbindungen mit GitHub Enterprise Server herstellen. Mit diesem Patch können Projektadministratoren Verbindungen zwischen Azure DevOps Server und Repositorys auf GitHub.com erstellen. Sie finden diese Einstellung auf der Seite GitHub-Verbindungen unter Projekteinstellungen.
• Beheben Sie das Problem mit dem Testplanwidget. Im Testausführungsbericht wurde ein falscher Benutzer für die Ergebnisse angezeigt.
• Beheben Sie das Problem, dass die Zusammenfassungsseite "Projektübersicht" nicht geladen wurde.
• Beheben Sie das Problem mit E-Mails, die nicht zur Bestätigung des Produktupgrades gesendet wurden.

Azure DevOps Server 2020.1.1 Patch 1 Releasedatum: 14. September 2021

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

• Fehler beim Herunterladen/Hochladen von Artefakten beheben.
• Beheben Sie das Problem mit inkonsistenten Testergebnisdaten.

Azure DevOps Server 2020 Update 1.1 Veröffentlichungsdatum: 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 oder ein Upgrade von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder höher direkt installieren.

Hinweis

Das Datenmigrationstool wird für Azure DevOps Server 2020 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

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

Azure Repos

• Es wurden die Kontrollkästchen für die Vererbung eingeschränkter Mergetypen behoben, um die Änderung von Limit merge-Typen nach dem Festlegen von Cross-Reposity-Richtlinien zu aktivieren.

Azure Pipelines

• Beim Ändern der Einstellung für Agent Update wurden die Einstellungen nicht an andere Anwendungsebenen in der Umgebung weitergegeben.

Allgemein

• Die Rechtschreibung im Serverkonfigurations-Assistenten wurde behoben.
• Die Größe des Erweiterungspakets wurde erhöht, sodass Sie die Größe in der Registrierung ändern können.

Azure Test Plans

• Wenn Sie von der Verlaufs- zur Zusammenfassungsseite zurückschlagen, können Sie nicht zu Testergebnissen navigieren.

---

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.

• Fehler bei der Builddefinitionsbenutzeroberfläche behoben.
• Browserverlauf wurde geändert, um Dateien anstelle des Stammrepositorys 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 behaupten SameSite=None.

• Beheben Sie das Problem mit dem Benachrichtigungs-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 der Azure DevOps Server 2020.1 RC2, die zuvor veröffentlicht wurde. Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.1 oder ein Upgrade von Azure DevOps Server 2020, 2019 oder Team Foundation Server 2015 oder höher direkt installieren.

Hinweis

Das Datenmigrationstool wird für Azure DevOps Server 2020 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.

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 der Azure DevOps Server 2020.1 RC1, die zuvor veröffentlicht wurden.

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

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 bietet viele neue Features. Einige der Highlights sind unter anderem:

• Regeln für Zustandsübergangseinschränkung in Boards
• Projektbeteiligte können jetzt Arbeitselemente spaltenübergreifend verschieben.
• Verbessern der Releasesicherheit durch Einschränken des Umfangs von Zugriffstoken
• Erweiterte Pull Request-Benutzeroberfläche
• Multirepository-Trigger in Pipelines

Sie können auch zu einzelnen Abschnitten wechseln, 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 gehostetem XML und dem geerbten Prozessmodell. Mit dieser neuen Arbeitselementtypregel können Sie das Verschieben von Arbeitselementen von einem Zustand in einen anderen einschränken. Sie können z. B. den Wechsel von Neu auf Behoben einschränken. Stattdessen müssen sie von Neu –> Aktiv –> Aufgelöst wechseln.

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

Kopieren eines Arbeitselements in das Kopieren untergeordneter Elemente

Eines der am häufigsten angeforderten Features für Azure Boards ist die Möglichkeit, ein Arbeitselement zu kopieren, das auch die untergeordneten Arbeitselemente kopiert. Dem Dialogfeld "Kopieren von Arbeitselementen" wurde eine neue Option "Untergeordnete Arbeitselemente einschließen" hinzugefügt. Bei Auswahl dieser Option wird das Arbeitselement kopiert und alle untergeordneten Arbeitselemente (bis zu 100) kopiert.

Verbesserte Regeln für aktivierte und aufgelöste Felder

Bisher waren die Regeln für Aktiviert von, Aktiviertes Datum, Aufgelöst von und Aufgelöstes Datum ein Geheimnis. Sie werden nur für Systemarbeitselementtypen festgelegt und sind spezifisch für den Zustandswert "Active" und "Resolved". Wir haben die Logik so geändert, dass diese Regeln nicht mehr für einen bestimmten Zustand gelten. Stattdessen werden sie durch die Kategorie (Zustandskategorie) ausgelöst, in der sich der Zustand befindet. Angenommen, Sie haben in der Kategorie Aufgelöst den benutzerdefinierten Status "Tests erforderlich". Wenn sich das Arbeitselement von "Aktiv" in "Bedarfstests" ändert, werden die Regeln Für aufgelöstesund aufgelöstes Datum ausgelöst.

Dadurch können Kunden benutzerdefinierte Zustandswerte erstellen und weiterhin die Felder Aktiviert von, Aktiviertes Datum, Aufgelöst von und Aufgelöstes Datum generieren, ohne benutzerdefinierte Regeln verwenden zu müssen.

Projektbeteiligte können Arbeitselemente spaltenübergreifend verschieben

Stakeholder konnten den Status von Arbeitselementen seit jeher ändern. Wenn sie jedoch zum Kanban-Board wechseln, können sie die Arbeitselemente nicht von einer Spalte in eine andere verschieben. Stattdessen müssten die Beteiligten jedes Arbeitselement einzeln öffnen und den Zustandswert aktualisieren. Dies ist seit langem ein Schmerzpunkt für Kunden, und wir freuen uns, ihnen mitteilen zu können, dass Sie jetzt Arbeitselemente über die Tafelspalten verschieben können.

Systemarbeitselementtypen in Backlogs und Boards

Jetzt können Sie der backlog-Ebene Ihrer Wahl einen Systemarbeitselementtyp hinzufügen. In der Vergangenheit waren diese Arbeitselementtypen nur über Abfragen verfügbar.

Prozess	Arbeitselementtyp
Agilität	Problem
Scrum	Impediment
CMMI	Change Request
	Problem
	Überprüfung
	Risiko

Das Hinzufügen eines Systemarbeitselementtyps zu einer Backlogebene ist einfach. Wechseln Sie einfach zu Ihrem benutzerdefinierten Prozess, und klicken Sie auf die Registerkarte Backlog-Ebenen. Wählen Sie die gewünschte Backlogebene aus (Beispiel: Anforderungsbacklog), und wählen Sie die Option Bearbeiten aus. Fügen Sie dann den Arbeitselementtyp hinzu.

Azure Boards GitHub-App-Repositorylimit angehoben

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

Anpassen des Arbeitselementzustands beim Zusammenführen von Pull Request

Nicht alle Workflows sind gleich. Einige Kunden möchten ihre zugehörigen Arbeitselemente schließen, wenn ein Pull Request abgeschlossen ist. Andere möchten die Arbeitselemente 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 Arbeitselemente auf den gewünschten Zustand festlegen können, wenn der Pull Request zusammengeführt und abgeschlossen wird. Dazu scannen wir die Pull Request-Beschreibung und suchen nach dem Zustandswert gefolgt von #Erwähnung der Arbeitselemente. In diesem Beispiel legen wir zwei Benutzerabschnitte auf Aufgelöst fest und schließen zwei Aufgaben.

Verknüpfen Ihres Arbeitselements mit Builds in einem anderen Projekt

Sie können Ihre Buildabhängigkeiten jetzt einfach projektübergreifend nachverfolgen, indem Sie Ihr Arbeitselement einfach mit einem Build verknüpfen, im Build gefunden oder in Build integriert.

Bearbeiten einer Beschreibung (Hilfetext) in Systemfeldern

Sie konnten die Beschreibung von benutzerdefinierten Feldern immer bearbeiten. Für Systemfelder wie Priorität, Schweregrad und Aktivität konnte die Beschreibung jedoch nicht bearbeitet werden. Dies war eine Featurelücke zwischen dem gehosteten XML-Code und dem Geerbten, die einige Kunden daran hinderte, zum geerbten Modell zu migrieren. Sie können nun die Beschreibung für Systemfelder bearbeiten. Der bearbeitete Wert wirkt sich nur auf dieses Feld im Prozess und für diesen Arbeitselementtyp aus. Dadurch haben Sie die Flexibilität, unterschiedliche Beschreibungen für dasselbe Feld für verschiedene Arbeitselementtypen zu haben.

Anpassen des Arbeitselementzustands beim Zusammenführen von Pull Request

Pull Requests beziehen sich häufig auf mehrere Arbeitselemente. Wenn Sie einen Pull Request erstellen oder aktualisieren, sollten Sie einige davon schließen, einige auflösen und den Rest offen halten. Sie können nun Kommentare wie die in der folgenden Abbildung gezeigten verwenden, um dies zu erreichen. Weitere Informationen finden Sie in der Dokumentation.

Übergeordnetes Feld im Taskboard

Aufgrund der beliebten Anforderung können Sie jetzt das Feld Übergeordnetes Element sowohl der untergeordneten als auch der übergeordneten Karte im Taskboard hinzufügen.

Entfernen der Regel "Zugewiesen an" für den Fehlerarbeitselementtyp

Es gibt mehrere ausgeblendete Systemregeln für alle verschiedenen Arbeitselementtypen in Agile, Scrum und CMMI. Diese Regeln gibt es seit über einem Jahrzehnt und funktionierten in der Regel ohne Beschwerden. Es gibt jedoch einige Regeln, die ihre Begrüßung ausgedessen haben. Insbesondere eine Regel hat für neue und bestehende Kunden viel Schmerz verursacht, und wir haben entschieden, dass es an der Zeit war, sie zu entfernen. Diese Regel ist für den Fehlerarbeitselementtyp im Agile-Prozess vorhanden.

"Legen Sie den zugewiesenen Wert auf Erstellt von fest, wenn der Zustand in Aufgelöst geändert wird"

Wir haben viel Feedback zu dieser Regel erhalten. Als Reaktion darauf haben wir diese Regel aus dem Fehlerarbeitselementtyp im Agile-Prozess entfernt. Diese Änderung wirkt sich auf jedes Projekt aus, das einen geerbten Agile-Prozess oder einen angepassten geerbten Agile-Prozess verwendet. Für Kunden, die diese aktuelle Regel mögen und davon abhängig sind, lesen Sie bitte unseren Blogbeitrag zu den Schritten, die Sie ausführen können, um die Regel mithilfe benutzerdefinierter Regeln erneut hinzuzufügen.

Entfernte Elemente auf der Seite "Arbeitselemente"

Auf der Seite Arbeitselemente können Sie unter anderem schnell nach Elementen suchen, die Sie erstellt oder Ihnen zugewiesen haben. Es bietet mehrere personalisierte Pivots und Filter. Eine der häufigsten Beschwerden für den Pivot "Mir zugewiesen" ist, dass entfernte Arbeitselemente angezeigt werden (also Arbeitselemente im Zustand Entfernt). Und wir stimmen zu! Entfernte Elemente sind Arbeit, die nicht mehr von Wert ist und daher aus dem Backlog entfernt wurde, daher ist es nicht hilfreich, sie in diese Ansicht einzuarbeiten.

Sie können jetzt alle Entfernten Elemente aus dem Pivot Mir zugewiesen auf der Seite Arbeitselemente ausblenden.

Repos

Standardeinstellung für den Branchnamen

Azure Repos bietet jetzt einen anpassbaren Standardbranch Namen für Git. In den Repositoryeinstellungen können Sie einen beliebigen legalen Branchnamen auswählen, der beim Initialisieren eines Repositorys verwendet werden soll. Azure Repos hat immer das Ändern des Standardbranch Namens für ein vorhandenes Repository unterstützt. Weitere Informationen finden Sie unter Verwalten von Branches .

 

Hinweis: Wenn Sie dieses Feature nicht aktivieren, werden Ihre Repositorys mit dem Standardnamen Azure Repos initialisiert. Im Moment ist dieser Standardwert master. Um das Engagement von Microsoft für eine inklusive Sprache und kundenspezifische Anforderungen zu erfüllen, werden wir gemeinsam mit Branchenkollegen diese Standardeinstellung in Standard ändern. Diese Änderung wird im Laufe dieses Sommers erfolgen. Wenn Sie master weiterhin verwenden möchten, sollten Sie dieses Feature jetzt aktivieren und auf master festlegen.

Einstellung auf Organisationsebene für Standardbranch

Es gibt jetzt eine Einstellung auf Sammlungsebene für Ihren bevorzugten anfänglichen Branchnamen für neue Repositorys. Wenn ein Projekt keinen ursprünglichen Branchnamen 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 Standard.

Hinzufügen eines neuen Authentifizierungsbereichs für beitragende PR-Kommentare

In dieser Version wird ein neuer OAuth-Bereich zum Lesen/Schreiben von Pull Request-Kommentaren hinzugefügt. Wenn Sie über einen Bot oder eine Automatisierung verfügen, die nur mit Kommentaren interagieren muss, können Sie ihm einen PAT nur mit diesem Bereich erteilen. Dieser Prozess reduziert den Explosionsradius, wenn die Automatisierung einen Fehler aufweist oder das Token kompromittiert wurde.

Verbesserungen der Pull Request-Benutzeroberfläche

Die neue Pull Request-Benutzeroberfläche wurde wie folgt verbessert:

• Machen Sie die optionalen Überprüfungen sichtbarer

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

• Strg-Klicks auf Menüelemente

Registerkartenmenüs für einen PR unterstützten keine STRG-TASTE. Benutzer öffnen häufig neue Browserregisterkarten, wenn sie einen Pull Request überprüfen. Dies wurde behoben.

• Speicherort der Anmerkung [+]

Die Strukturliste der Dateien in einem PR zeigt eine Anmerkung [+] an, um Autoren und Prüfern beim Identifizieren neuer Dateien zu helfen. Da sich die Anmerkung hinter den Auslassungspunkten befand, war sie für längere Dateinamen oft nicht sichtbar.

• PR-Updates-Dropdown zur Wiederherstellung von Zeitinformationen

Die Dropdownliste zum Auswählen von Dateien aktualisieren und vergleichen in einem PR hat ein wichtiges Element in der Vorschauumgebung verloren. Es wurde nicht angezeigt, wann dieses Update durchgeführt wurde. Dies wurde behoben.

• **Verbessertes Kommentarfilterlayout **

Beim Filtern von Kommentaren auf der Zusammenfassungsseite eines Pull Requests befand sich die Dropdownliste auf der rechten Seite, aber der Text war linksbündig. 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 besser verstehen, wie sich dieser Commit von seinem eigenen übergeordneten Commit unterscheidet. Dies ist häufig erforderlich, wenn Sie alle Änderungen in einem Release verstehen möchten. Wir haben einen(n) übergeordneten(n) Karte zu einem Commit hinzugefügt, damit Sie dies erreichen können.

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

Ordner und Dateien mit langen Namen wurden aufgrund fehlender horizontaler Abstände in der Dateistruktur abgeschnitten. Wir haben zusätzlichen Platz in der Struktur wiederhergestellt, indem wir den Einzug der Struktur so geändert haben, dass er dem Stammknoten entspricht, und indem wir die Schaltfläche mit den Auslassungspunkten auf der Seite ausblenden, außer beim Zeigen.

Abbildung der neuen Dateistruktur:

Abbildung der Dateistruktur beim Bewegen des Mauszeigers auf ein Verzeichnis:

• Beibehalten der Bildlaufposition beim Ändern der Größe diff Bereichs auf der Registerkarte "PR-Dateien"

Wenn Sie die Größe des parallelen diff Bereichs auf der Registerkarte PR-Dateien ändern, geht der Bildlaufspeicherort des Benutzers verloren. Dieses Problem wurde behoben. Der Bildlaufspeicherort des Benutzers wird nun in einer diff Bereichsgröße geändert.

• Suchen nach einem Commit auf einem mobilen Gerät

Beim Anzeigen der Seite Commits auf einem mobilen Gerät fehlt das Suchfeld in der neuen Benutzeroberfläche. Daher ist es schwierig für Sie, einen Commit durch seinen Hash zu finden und ihn zu öffnen. Dies wurde jetzt behoben.

• Verbesserte Speicherplatznutzung für neue PR-Datei diff mobile Ansicht

Wir haben diese Seite aktualisiert, um den Speicherplatz besser zu nutzen, sodass Benutzer mehr von der Datei in mobilen Ansichten sehen können, anstatt 40 % des Bildschirms von einer Kopfzeile belegt zu werden.

• Erweiterte Bilder in der PR-Zusammenfassungsansicht

In einem PR bearbeitete Bilder wurden in der PR-Zusammenfassungsansicht nicht angezeigt, aber in der PR-Dateiansicht ordnungsgemäß angezeigt. Dieses Problem wurde behoben.

• Erweiterte Brancherfahrung beim Erstellen eines neuen PR

Vor diesem Update war diese Erfahrung nicht ideal, da die Änderungen mit dem Standardbranch des Repositorys anstelle der Vergleichsbranch verglichen wurden.

Pipelines

Zusätzliche Agentplattform: ARM64

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

Tagfilterunterstützung für Pipelineressourcen

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    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 (Continuous Integration) zu bestimmen, die ausgeführt werden soll, wenn die CD-Pipelineausführung (Continuous Deployment) nicht von einer anderen Quelle/Ressource oder einem Trigger für eine geplante Ausführung ausgelöst wird.

Wenn Sie für instance einen geplanten Trigger für Ihre CD-Pipeline festgelegt haben, den Sie nur ausführen möchten, wenn Ihre CI über das Produktionstag verfügt, stellen die Tags im Abschnitt triggers sicher, dass die CD-Pipeline nur ausgelöst wird, wenn die Taggingbedingung durch das CI-Vervollständigungsereignis erfüllt wird.

Steuern, welche Aufgaben in Pipelines zulässig sind

Sie können jetzt Marketplace-Aufgaben deaktivieren. Einige von Ihnen können Marketplace-Erweiterungen zulassen, aber nicht die Pipelines-Aufgaben, die sie mitbringen. Um noch mehr Kontrolle zu erhalten, ermöglichen wir Es Ihnen auch, alle Im-Box-Aufgaben unabhängig zu deaktivieren (mit Ausnahme des Auscheckens, was eine besondere Aktion ist). Wenn beide Einstellungen aktiviert sind, können nur Aufgaben in einer Pipeline ausgeführt werden, die mithilfe von tfx hochgeladen werden. Besuchen Sie https://dev.azure.com/<your_org>/_settings/pipelinessettings den Abschnitt "Aufgabeneinschränkungen", um zu beginnen.

Exklusive Bereitstellungssperrrichtlinie

Mit diesem Update können Sie sicherstellen, dass nur eine einzelne Ausführung gleichzeitig in einer Umgebung bereitgestellt wird. Wenn Sie die Option "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 letzte Ausführung fortgesetzt. Alle Zwischenausführungen werden abgebrochen.

Stufenfilter 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 Ihre 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 wurden, wird automatisch eine neue Ausführung für Ihre CD-Pipeline ausgelöst.

Generische webhookbasierte 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 diesem Release führen wir die Unterstützung von Webhooktriggern in YAML-Pipelines ein, um die Integration der Pipelineautomatisierung mit jedem externen Dienst zu ermöglichen. Sie können alle externen Ereignisse über die Webhooks (Github, Github Enterprise, Nexus, Aritfactory usw.) abonnieren und Ihre Pipelines auslösen.

Hier sind die Schritte zum Konfigurieren der Webhooktrigger:

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

   • Anforderungs-URL: "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Geheimnis: Dies ist optional. Wenn Sie Ihre JSON-Nutzlast schützen müssen, geben Sie den Wert Secret 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 Anforderungsprüfung enthält. Im Fall von GitHub lautet der Anforderungsheader beispielsweise "X-Hub-Signature".
   • Geheimnis : Das Geheimnis wird verwendet, um den Nutzlasthash zu analysieren, der für die Überprüfung der eingehenden Anforderung verwendet wird (dies ist optional). Wenn Sie beim Erstellen Ihres Webhooks ein Geheimnis verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.

   

3. Ein neuer Ressourcentyp namens webhooks wird in YAML-Pipelines eingeführt. Um ein Webhookereignis zu abonnieren, müssen Sie eine Webhookressource in Ihrer Pipeline definieren und auf die Eingehende Webhookdienstverbindung verweisen. Sie können auch zusätzliche Filter für die Webhookressource 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 nutzen.

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 Webhookereignis von der eingehenden Webhookdienstverbindung empfangen wird, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhookereignis abonniert haben.

Unterstützung und Nachverfolgbarkeit bei YAML-Ressourcentriggerproblemen

Es kann verwirrend sein, wenn Pipelinetrigger nicht wie erwartet ausgeführt werden können. Um dies besser zu verstehen, haben wir auf der Pipelinedefinitionsseite ein neues Menüelement namens "Probleme auslösen" hinzugefügt, in dem Informationen darüber 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 die 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.

   

Trigger für mehrere Repositorys

Sie können mehrere Repositorys in einer YAML-Datei angeben und eine Pipeline auslösen, indem Sie die Repositorys aktualisieren. Dieses Feature ist für instance 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 Multirepository-Trigger nur für Git-Repositorys in Azure Repos. Sie funktionieren nicht für GitHub- oder BitBucket-Repositoryressourcen.

Hier sehen Sie ein Beispiel, das zeigt, wie Mehrere Repositoryressourcen in einer Pipeline definiert und trigger für alle konfiguriert werden.

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 Updates für folgendes vorhanden sind:

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

Weitere Informationen finden Sie unter Mehrere Repositorys in Ihrer Pipeline.

Agent-Protokolluploads verbessert

Wenn ein Agent die Kommunikation mit dem Azure Pipelines-Server beendet, wird der ausgeführte Auftrag abgebrochen. Wenn Sie sich die Protokolle der Streamingkonsole angeschaut haben, haben Sie möglicherweise einige Hinweise darauf erhalten, was der Agent direkt vor der Reaktion aufgehört hat. Wenn Sie dies nicht getan haben oder die Seite aktualisiert haben, sind diese Konsolenprotokolle nicht mehr vorhanden. Wenn der Agent in diesem Release nicht mehr reagiert, bevor er seine vollständigen Protokolle sendet, behalten wir die Konsolenprotokolle als nächstbeste Sache bei. Konsolenprotokolle sind auf 1.000 Zeichen pro Zeile beschränkt und können gelegentlich unvollständig sein, aber sie sind viel hilfreicher als nichts anzuzeigen! Die Untersuchung dieser Protokolle kann Ihnen helfen, Probleme mit Ihren eigenen Pipelines zu beheben, und es wird unseren Supporttechnikern sicherlich helfen, wenn sie bei der Problembehandlung helfen.

Optional schreibgeschütztes Einbinden von 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 haben standardmäßig Lese-/Schreibzugriff. Um die Sicherheit zu erhöhen, können Sie die Volumes schreibgeschützt einbinden, indem Sie Ihre Containerspezifikation in YAML ändern. Jeder Schlüssel unter mountReadOnly kann auf true schreibgeschützt festgelegt werden (der Standardwert ist false).

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

Präzise Steuerung des Containerstarts/-stopps

Im Allgemeinen wird empfohlen, Azure Pipelines die Verwaltung des Lebenszyklus Ihrer Auftrags- und Dienstcontainer zu gestatten. In einigen ungewöhnlichen Szenarien können Sie sie jedoch selbst starten und beenden. Mit diesem Release haben wir diese Funktion in die Docker-Aufgabe integriert.

Hier sehen Sie eine Beispielpipeline, die die neue Funktion verwendet:

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 schließen wir die Liste der Container in eine Pipelinevariable ein, Agent.ContainerMapping. Sie können dies verwenden, wenn Sie z. B. die Liste der Container in einem Skript überprüfen möchten. Es enthält ein stringified JSON-Objekt, das den Ressourcennamen ("Builder" aus dem obigen Beispiel) der Container-ID zuzuordnen, die der Agent verwaltet.

Entzippen von Aufgabenbündeln für jeden Schritt

Wenn der Agent einen Auftrag ausführt, lädt er zunächst alle Aufgabenbündel herunter, die für die Schritte des Auftrags erforderlich sind. Normalerweise entpackt er die Aufgaben für die Leistung einmal pro Auftrag, auch wenn die Aufgabe in mehreren Schritten verwendet wird. Wenn Sie Bedenken haben, dass nicht vertrauenswürdiger Code den entzippten Inhalt ändert, können Sie ein wenig an Leistung eintauschen, indem Sie den Agent die Aufgabe bei jeder Verwendung entzippen lassen. Um diesen Modus zu aktivieren, übergeben Sie --alwaysextracttask beim Konfigurieren des Agents.

Verbessern der Releasesicherheit durch Einschränken des Umfangs von Zugriffstoken

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

Jeder Auftrag, der in Releases ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und Von Ihren Skripts verwendet, um azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Artefakte herunterzuladen, Protokolle hochzuladen, Ergebnisse zu testen oder REST-Aufrufe in Azure DevOps durchzuführen. Für jeden Auftrag wird ein neues Zugriffstoken generiert, das nach Abschluss des Auftrags abläuft.

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

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

VERBESSERUNGEN der YAML-Vorschau-API

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 to https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview , um den endgültigen YAML-Text abzurufen. Diese neue API verwendet dieselben Parameter wie warteschlangenbasierte Ausführung, erfordert aber nicht mehr die Berechtigung "Warteschlangenbuilds".

Ausführen dieses Auftrags als Nächstes

Hatten Sie jemals einen Bugfix, den Sie in dieser Minute bereitstellen mussten, aber hinter CI- und PR-Aufträgen warten mussten? Mit diesem Release können Sie jetzt die Priorität eines Auftrags in der Warteschlange erhöhen. Benutzern mit der Berechtigung "Verwalten" für den Pool – in der Regel Pooladministratoren – wird auf der Auftragsdetailseite 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. (Sie benötigen natürlich weiterhin verfügbare Parallelität und einen geeigneten Agent.)

Im YAML-Block resources zulässige Vorlagenausdrücke

Zuvor waren Kompilierzeitausdrücke (${{ }}) im resources Abschnitt einer YaML-Datei von Azure Pipelines nicht zulässig. Mit diesem Release haben wir diese Einschränkung für Container aufgehoben. Dadurch können Sie Laufzeitparameterinhalte in Ihren Ressourcen verwenden, z. B. zur Auswahl eines Containers zur Warteschlangenzeit. Wir planen, diesen Support im Laufe der Zeit auf andere Ressourcen auszudehnen.

Kontrolle über automatisierte Aufgabenupdates aus dem Marketplace

Wenn Sie eine YAML-Pipeline schreiben, geben Sie normalerweise nur die Hauptversionsnummer der eingeschlossenen Aufgaben an. Dadurch können Ihre Pipelines automatisch die neuesten Features und Fehlerbehebungen übernehmen. Gelegentlich müssen Sie möglicherweise ein Rollback zu einer früheren Point Release einer Aufgabe durchführen, und mit diesem Update haben wir 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 es nur als temporäre Problemumgehung zu verwenden, wenn Sie feststellen, dass eine neuere Aufgabe Ihre Pipelines unterbricht. Außerdem wird dadurch keine ältere Version einer Aufgabe aus dem Marketplace installiert. Es muss bereits in Ihrer Sammlung vorhanden sein, andernfalls schlägt Ihre Pipeline 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 Knoten 6 nicht mehr unterstützt wird, migrieren wir die Aufgaben, um mit Knoten 10 zu arbeiten. Für dieses Update haben wir fast 50 % der Im Lieferumfang ausgeführten Aufgaben zu Knoten 10 migriert. Der Agent kann jetzt sowohl Node 6- als auch Node 10-Tasks ausführen. In einem zukünftigen Update werden wir Knoten 6 vollständig aus dem Agent entfernen. Um die Entfernung von Knoten 6 aus dem Agent vorzubereiten, bitten wir Sie, Ihre internen Erweiterungen und benutzerdefinierten Aufgaben so zu aktualisieren, dass sie auch Knoten 10 bald verwenden. Wenn Sie Knoten 10 für Ihre Aufgabe verwenden möchten, aktualisieren NodeNode10Sie task.jsonexecutionunter von in .

Verbessern der YAML-Konvertierung im klassischen Build-Designer

Mit dieser Version wird ein neues Feature "Export to YAML" für Designerbuildpipelines eingeführt. Speichern Sie Ihre Pipelinedefinition, und suchen Sie dann im ... Menü nach "Nach 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 Webbenutzeroberfläche über den Build wusste, was manchmal dazu führte, dass falsche YAML generiert wurde. Die neue Exportfunktion berücksichtigt genau die Verarbeitung der Pipeline und generiert YAML mit voller Genauigkeit für die Designerpipeline.

Neue Webplattformkonvertierung – Repositoryeinstellungen

Wir haben die beiden Repository-Einstellungsseiten in eine einzelne Benutzeroberfläche konvertiert, die auf eine neue Webplattform aktualisiert wurde. Dieses Upgrade macht nicht nur das Erlebnis schneller und moderner, sondern diese Seiten bieten auch einen einzigen Einstiegspunkt für alle Richtlinien von der Projekt- bis zur Branchebene.

Mit dieser neuen Benutzeroberfläche ist die Navigation für Projekte mit einer beträchtlichen 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 Branchs anzeigen, für die die Richtlinie festgelegt ist. Klicken Sie nun auf den Branch, 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 übergeordnete Richtlinie festgelegt wurde, indem Sie auf den Bereichsnamen klicken.

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

Integration der ServiceNow-Änderungsverwaltung in YAML-Pipelines

Die Azure Pipelines-App für ServiceNow unterstützt Sie bei der Integration von Azure Pipelines und ServiceNow Change Management. Mit diesem Update führen wir unseren Weg, Azure Pipelines auf den in ServiceNow verwalteten Änderungsverwaltungsprozess aufmerksam zu machen, bis hin zu YAML-Pipelines.

Wenn Sie die Überprüfung "ServiceNow Change Management" für eine Ressource konfigurieren, können Sie nun anhalten, bis 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 den UpdateServiceNowChangeRequest Task auch in einem Serverauftrag hinzufügen, um die Änderungsanforderung mit Bereitstellungs-status, Notizen usw. zu aktualisieren.

Artifacts

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

Wir bieten Kunden die Möglichkeit, 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 Organisationsfeeds über die Benutzeroberfläche erstellen, indem Sie zu Artefakte –> Feed erstellen wechseln und einen Feedtyp im Bereich auswählen.

Wir empfehlen zwar die Verwendung projektbezogener Feeds in Übereinstimmung mit den restlichen Azure DevOps-Angeboten, 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 der Dokumentation zu Feeds.

Update Package Version REST API jetzt für Maven-Pakete verfügbar

Sie können jetzt die Azure Artifacts-REST-API "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	Typ	Beschreibung
views	JsonPatchOperation	Die Ansicht, der die Paketversion hinzugefügt wird

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

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