Versionshinweise zu Azure DevOps Server 2020

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

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

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

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

---

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

Azure DevOps Server 2020 wird ein neues Aufbewahrungsmodell für die Pipelineausführung (Build) eingeführt, das auf Projektebeneneinstellungen basiert.

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

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

Azure DevOps Server Veröffentlichungsdatum von Update 0.2 Patch 6 2020: 14. November 2023

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

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

Hinweis

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

Patches installieren

Wichtig

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

Konfigurieren von TFX

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

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Veröffentlichungsdatum: 10. Oktober 2023

Wichtig

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

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

• Ein Fehler wurde behoben, bei dem die Identität "Analysis Owner" auf Patchupgradecomputern als inaktive Identität angezeigt wird.

Azure DevOps Server Veröffentlichungsdatum von Update 0.2 Patch 4 2020: 12. September 2023

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

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

Wichtig

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

Hinweis

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

Patches installieren

1. Laden Sie Azure DevOps Server 2020 Update 0.2 Patch 4 herunter, und installieren Sie es.

Aktualisieren des Azure Pipelines-Agents

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

Hinweis

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

Konfigurieren von TFX

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

Aktualisieren von Aufgaben mithilfe von TFX

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

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

Pipelineanforderungen

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

• Auf klassisch:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server Veröffentlichungsdatum von Update 0.2 Patch 3 2020: 8. August 2023

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

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

Azure DevOps Server 2020 Update 0.2 Patch 2 Veröffentlichungsdatum: 13. Juni 2023

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

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

Azure DevOps Server 2020 Update 0.2 Patch 1 Veröffentlichungsdatum: 18. Oktober 2022

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

• Beheben Sie das Problem, dass neu hinzugefügte AD-Identitäten nicht in der Identitätsauswahl des Sicherheitsdialogs angezeigt werden.
• Behebung eines Problems mit dem Filter "Angefordert nach Mitglied der Gruppe" in den Webhookeinstellungen.
• Behebung eines Fehlers bei Gated-Check-In-Builds, wenn für die Organisationseinstellungen für die Pipeline ein Auftragsautorisierungsbereich konfiguriert war, der als Auftragsautorisierungsbereich auf das aktuelle Projekt für Pipelines ohne Release beschränken konfiguriert war.

Azure DevOps Server Veröffentlichungsdatum 2020.0.2: 17. Mai 2022

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

Hinweis

Das Datenmigrationstool wird etwa drei Wochen nach dieser Version für Azure DevOps Server 2020.0.2 verfügbar sein. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Dieses Release enthält Fehlerbehebungen für Folgendes:

• Buildwarteschlange kann mithilfe der Schaltfläche "Weiter ausführen" nicht übersprungen werden. Bisher 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 Veröffentlichungsdatum von Patch 9 2020.0.1: 26. Januar 2022

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

• Email Benachrichtigungen wurden nicht gesendet, wenn das @mention Steuerelement in einem Arbeitselement verwendet wurde.
• Beheben Sie TF400813 Fehler beim Wechseln von Konten. Dieser Fehler ist beim Upgrade von TFS 2018 auf Azure DevOps Server 2020.0.1 aufgetreten.
• Beheben Sie das Problem, dass die Zusammenfassungsseite "Projektübersicht" nicht geladen wurde.
• 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 9.
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 9..
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: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 Patch 8 Releasedatum: 15. Dezember 2021

Patch 8 für Azure DevOps Server 2020.0.1 enthält Korrekturen für Folgendes.

• Lokalisierungsproblem bei Layoutzuständen für benutzerdefinierte Arbeitselemente.
• Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
• Problem mit abgeschnittenen Konsolenprotokollen, wenn mehrere identische Links in einer Zeile vorhanden sind.
• Problem mit der NOTSAMEAS-Regelauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

Azure DevOps Server 2020.0.1 Patch 7 Releasedatum: 26. Oktober 2021

Patch 7 für Azure DevOps Server 2020.0.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.0.1 Patch 6 Releasedatum: 14. September 2021

Patch 6 für Azure DevOps Server 2020.0.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.0.1 Patch 5 Veröffentlichungsdatum: 10. August 2021

Patch 5 für Azure DevOps Server 2020.0.1 enthält Korrekturen für Folgendes.

• Fehler bei der Builddefinitionsbenutzeroberfläche behoben.
• Browserverlauf wurde geändert, um Dateien anstelle des Stammrepositorys anzuzeigen.
• Beheben sie das Problem mit E-Mail-Übermittlungsaufträgen für einige Arbeitselementtypen.

Azure DevOps Server 2020.0.1 Patch 4 Releasedatum: 15. Juni 2021

Patch 4 für Azure DevOps Server 2020.0.1 enthält Korrekturen für Folgendes.

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

Azure DevOps Server 2020.0.1 Patch 3 Veröffentlichungsdatum: 11. Mai 2021

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

• Inkonsistente Testergebnisdaten bei Verwendung von Microsoft.TeamFoundation.TestManagement.Client.

Wenn Sie über Azure DevOps Server 2020.0.1 verfügen, sollten Sie Azure DevOps Server 2020.0.1 Patch 3 installieren.

Überprüfen der Installation

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

• Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 ist standardmäßig installiertc:\Program Files\Azure DevOps Server 2020. Nach der Installation von Azure DevOps Server 2020.0.1 Patch 3 lautet die Version 18.170.31228.1.

Azure DevOps Server 2020.0.1 Patch 2 Veröffentlichungsdatum: 13. April 2021

Hinweis

Wenn Sie über Azure DevOps Server 2020 verfügen, sollten Sie zuerst auf Azure DevOps Server 2020.0.1 aktualisieren. Installieren Sie nach 2020.0.1 Azure DevOps Server 2020.0.1 Patch 2.

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

• CVE-2021-27067 : Veröffentlichung von Informationen
• CVE-2021-28459: Rechteerweiterung

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

Allgemeine Patchinstallation

Wenn Sie über Azure DevOps Server 2020.0.1 verfügen, sollten Sie Azure DevOps Server 2020.0.1 Patch 2 installieren.

Überprüfen der Installation

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

• Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 ist standardmäßig installiertc:\Program Files\Azure DevOps Server 2020. Nach der Installation Azure DevOps Server 2020.0.1 Patch 2 lautet die Version 18.170.31123.3.

Installation des AzureResourceGroupDeploymentV2-Tasks

Hinweis

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

Installieren

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

AzureResourceManagerTemplateDeploymentV3-Taskinstallation

Hinweis

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

Installieren

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Azure DevOps Server 2020.0.1 Patch 1 Veröffentlichungsdatum: 9. Februar 2021

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

• Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht
• Fügen Sie Fixes ein, die mit Azure DevOps Server 2020 Patch 2 veröffentlicht wurden.

Azure DevOps Server Veröffentlichungsdatum von Patch 3 2020: 9. Februar 2021

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

• Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht

Azure DevOps Server Veröffentlichungsdatum 2020.0.1: 19. Januar 2021

Azure DevOps Server 2020.0.1 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.0.1 direkt installieren oder ein Upgrade von einer vorhandenen Installation durchführen. Unterstützte Versionen für das Upgrade sind Azure DevOps Server 2020, Azure DevOps Server 2019 und Team Foundation Server 2012 oder höher.

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

• Beheben Sie ein Upgradeproblem aus Azure DevOps Server 2019, bei dem der Git-Proxy nach dem Upgrade möglicherweise nicht mehr funktioniert.
• Behebung der System.OutOfMemoryException-Ausnahme für Nicht-ENU-Sammlungen vor Team Foundation Server 2017 beim Upgrade auf Azure DevOps Server 2020. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
• Wartungsfehler aufgrund fehlender Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
• Fehler mit ungültigem Spaltennamen in Analytics beim Upgrade auf Azure DevOps Server 2020 behoben. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
• Gespeicherte XSS beim Anzeigen von Testfallschritten in Testfallergebnissen.
• Fehler beim Upgradeschritt beim Migrieren von Punktergebnisdaten zu TCM.

Azure DevOps Server Veröffentlichungsdatum von Patch 2020: 12. Januar 2021

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

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

Azure DevOps Server 2020 Patch 1 Datum: 8. Dezember 2020

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

• CVE-2020-17145 : Sicherheitsrisiko durch Spoofing in Azure DevOps Server und Team Foundation Services

Azure DevOps Server Veröffentlichungsdatum 2020: 6. Oktober 2020

Azure DevOps Server 2020 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features der zuvor veröffentlichten Azure DevOps Server 2020 RC2.

Hinweis

Azure DevOps 2020 Server hat ein Problem mit der Installation einer der Assemblys, die vom Git Virtual File System (GVFS) verwendet werden.

Wenn Sie ein Upgrade von Azure DevOps 2019 (beliebiger Version) oder einem Azure DevOps 2020-Release candidate durchführen und im selben Verzeichnis wie das vorherige Release installieren, wird die Assembly Microsoft.TeamFoundation.Git.dll nicht installiert. Sie können überprüfen, ob das Problem aufgetreten ist, indem Sie in <Install Dir>\Version Control Proxy\Web Services\binden Ordnern , <Install Dir>\Application Tier\TFSJobAgent und <Install Dir>\Tools nach suchenMicrosoft.TeamFoundation.Git.dll. Wenn die Datei fehlt, können Sie eine Reparatur ausführen, um die fehlenden Dateien wiederherzustellen.

Navigieren Sie zum Ausführen einer Reparatur auf dem Azure DevOps Server Computer/VM zuSettings -> Apps & Features, und führen Sie eine Reparatur auf Azure DevOps 2020 Server aus. Nach Abschluss der Reparatur können Sie den Computer/die VM neu starten.

Veröffentlichungsdatum Azure DevOps Server 2020 RC2: 11. August 2020

Azure DevOps Server 2020 RC2 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features des zuvor veröffentlichten Azure DevOps Server 2020 RC1.

Veröffentlichungsdatum der Azure DevOps Server RC1 2020: 10. Juli 2020

Wir haben Azure DevOps Server 2020 RC1 erneut veröffentlicht, um dieses Entwicklercommunity Feedbackticket zu beheben.

Zuvor konnten Sie nach dem Upgrade von Azure DevOps Server 2019 Update 1.1 auf Azure DevOps Server 2020 RC1 keine Dateien in den Repositorys, Pipelines und wiki der Webbenutzeroberfläche anzeigen. Es wurde eine Fehlermeldung angezeigt, die darauf hinweist, dass innerhalb dieses Bereichs der Seite ein unerwarteter Fehler aufgetreten ist. Sie können versuchen, diese Komponente neu zu laden oder die gesamte Seite zu aktualisieren. Mit dieser Version haben wir dieses Problem behoben. Weitere Informationen finden Sie im Blogbeitrag.

Azure DevOps Server Veröffentlichungsdatum 2020 RC1: 30. Juni 2020

Zusammenfassung der Neuerungen in Azure DevOps Server 2020

Azure DevOps Server 2020 werden viele neue Features eingeführt. Einige der Highlights sind unter anderem:

• Mehrstufige Pipelines
• Continuous deployment in YAML
• Nachverfolgen des Fortschritts übergeordneter Elemente mithilfe des Backlogs "Rollup on Boards"
• Hinzufügen des Filters "Übergeordnetes Arbeitselement" zum Taskboard und Sprintbacklog
• Neue Web-Benutzeroberfläche für Azure Repos Landing Pages
• Cross-Repo Branch-Richtlinienverwaltung
• Seite "Neuer Testplan"
• Umfangreiche Bearbeitung für Code-Wiki-Seiten
• Berichte zu Pipelinefehlern und -dauer

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

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

---

Allgemein

Allgemeine Verfügbarkeit der Azure DevOps-CLI

Im Februar haben wir die Azure DevOps-Erweiterung für die Azure CLI eingeführt. Mit der Erweiterung können Sie über die Befehlszeile mit Azure DevOps interagieren. Wir haben Ihr Feedback gesammelt, das uns geholfen hat, die Erweiterung zu verbessern und weitere Befehle hinzuzufügen. Wir freuen uns nun mitteilen zu können, dass die Erweiterung allgemein verfügbar ist.

Weitere Informationen zur Azure DevOps-CLI finden Sie in der Dokumentation hier.

Verwenden des Veröffentlichungsprofils zum Bereitstellen von Azure WebApps für Windows über das Bereitstellungscenter

Jetzt können Sie die profilbasierte Veröffentlichungsauthentifizierung verwenden, um Ihre Azure WebApps für Windows über das Bereitstellungscenter bereitzustellen. Wenn Sie über die Berechtigung zum Bereitstellen in einer Azure WebApp für Windows mit dem zugehörigen Veröffentlichungsprofil verfügen, können Sie die Pipeline mithilfe dieses Profils in den Deployment Center-Workflows einrichten.

Boards

Hinzufügen des Filters "Übergeordnetes Arbeitselement" zum Taskboard und Sprintbacklog

Wir haben sowohl dem Sprintboard als auch dem Sprintbacklog einen neuen Filter hinzugefügt. Dadurch können Sie Backlogelemente auf Anforderungsebene (erste Spalte links) nach ihrem übergeordneten Element filtern. Im folgenden Screenshot haben wir beispielsweise die Ansicht so gefiltert, dass nur User Storys angezeigt werden, bei denen das übergeordnete Element "Mein großes Feature" ist.

Verbessern der Fehlerbehandlungserfahrung – Erforderliche Felder für Fehler/Aufgabe

Wenn Sie aus dem Kanban-Board ein Arbeitselement von einer Spalte in eine andere verschoben haben, in der die Zustandsänderung Feldregeln ausgelöst hat, zeigt die Karte in der Vergangenheit nur eine rote Fehlermeldung an, die Sie zwingt, das Arbeitselement zu öffnen, um die Grundursache zu verstehen. In Sprint 170 haben wir die Benutzeroberfläche verbessert, sodass Sie jetzt auf die rote Fehlermeldung klicken können, um die Details des Fehlers anzuzeigen, ohne das Arbeitselement selbst öffnen zu müssen.

Arbeitselement live neu laden

Früher, wenn ein Arbeitselement aktualisiert und ein zweites Teammitglied Änderungen an demselben Arbeitselement vorgenommen hat, hat der zweite Benutzer seine Änderungen verloren. Solange Sie beide unterschiedliche Felder bearbeiten, werden Liveupdates der Änderungen am Arbeitselement angezeigt.

Verwalten von Iterations- und Bereichspfaden über die Befehlszeile

Sie können nun Iterations- und Bereichspfade über die Befehlszeile verwalten, indem Sie die az boards iteration Befehle und az boards area verwenden. Beispielsweise können Sie Iterations- und Bereichspfade interaktiv über die CLI einrichten und verwalten oder das gesamte Setup mithilfe eines Skripts automatisieren. Weitere Informationen zu den Befehlen und der Syntax finden Sie in der Dokumentation hier.

Option "Übergeordnete Arbeitsaufgabe Spalte als Spalte"

Sie haben jetzt die Möglichkeit, das übergeordnete Element jedes Arbeitselements in Ihrem Produkt- oder Sprintbacklog anzuzeigen. Um dieses Feature zu aktivieren, wechseln Sie zu Spaltenoptionen für den gewünschten Backlog, und fügen Sie dann die Spalte Übergeordnetes Element hinzu.

Ändern des von einem Projekt verwendeten Prozesses

Ihre Tools sollten sich wie Ihr Team ändern. Sie können Jetzt Ihre Projekte von jeder vordefinierten Prozessvorlage zu einem anderen sofort einsatzbereiten Prozess wechseln. Beispielsweise können Sie Ihr Projekt von Agile zu Scrum oder Basic in Agile ändern. Die vollständige schrittweise Dokumentation finden Sie hier.

Ausblenden von benutzerdefinierten Feldern im Layout

Sie können nun benutzerdefinierte Felder im Formularlayout ausblenden, wenn Sie Ihren Prozess anpassen. Das Feld ist weiterhin über Abfragen und REST-APIs verfügbar. Dies ist nützlich für die Nachverfolgung zusätzlicher Felder, wenn Sie in andere Systeme integrieren.

Erhalten Sie Einblicke in die Integrität Ihres Teams mit drei neuen Azure Boards Berichten

Sie können nicht korrigieren, was nicht angezeigt wird. Daher möchten Sie den Zustand und die Integrität ihrer Arbeitsprozesse genau im Auge behalten. Mit diesen Berichten erleichtern wir Ihnen das Nachverfolgen wichtiger Metriken mit minimalem Aufwand in Azure Boards.

Die drei neuen interaktiven Berichte sind Burndown, Kumulatives Flussdiagramm (CFD) und Velocity. Die Berichte werden auf der neuen Registerkarte "Analyse" angezeigt.

Metriken wie Sprint-Burndown, Arbeitsfluss und Teamgeschwindigkeit geben Ihnen einblick in den Fortschritt Ihres Teams und helfen Ihnen bei der Beantwortung von Fragen wie:

• Wie viel Arbeit bleibt in diesem Sprint? Sind wir auf dem richtigen Weg, es abzuschließen?
• Welcher Entwicklungsschritt dauert am längsten? Können wir etwas dagegen tun?
• Wie viel Arbeit sollten wir basierend auf vorherigen Iterationen für den nächsten Sprint planen?

Hinweis

Die zuvor in den Headern angezeigten Diagramme wurden durch diese erweiterten Berichte ersetzt.

Die neuen Berichte sind vollständig interaktiv und ermöglichen es Ihnen, sie an Ihre Bedürfnisse anzupassen. Sie finden die neuen Berichte auf der Registerkarte Analytics in jedem Hub.

• Das Burndowndiagramm finden Sie unter dem Sprints-Hub .

  

• Auf die CFD- und Velocity-Berichte kann über die Registerkarte Analyse unter Boards und Backlogs zugegriffen werden, indem Sie auf die entsprechenden Karte klicken.

  

Mit den neuen Berichten haben Sie mehr Kontrolle und Informationen zu Ihrem Team. Hier einige Beispiele:

• Die Berichte Sprint Burndown und Velocity können so festgelegt werden, dass sie die Anzahl der Arbeitselemente oder die Summe der verbleibenden Arbeit verwenden.
• Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne sich auf die Projekttermine zu auswirken. Wenn Ihr Team also normalerweise den ersten Tag jeder Sprintplanung verbringt, können Sie jetzt das Diagramm anpassen, um dies widerzuspiegeln.
• Das Burndown-Diagramm verfügt jetzt über ein Wasserzeichen, das Wochenenden anzeigt.
• Mit dem CFD-Bericht können Sie Boardspalten wie Design entfernen, um den Fokus auf den Ablauf zu erhalten, den die Teams steuern.

Hier sehen Sie ein Beispiel für den CFD-Bericht, der den Flow für die letzten 30 Tage des Stories-Backlogs anzeigt.

Das Geschwindigkeitsdiagramm kann jetzt für alle Backlogebenen nachverfolgt werden. Beispielsweise können Sie jetzt sowohl Features als auch Epics hinzufügen, während vor dem vorherigen Diagramm nur Anforderungen unterstützt wurden. Hier sehen Sie ein Beispiel für einen Geschwindigkeitsbericht für die letzten 6 Iterationen des Features-Backlogs.

Anpassen von Taskboardspalten

Wir freuen uns, ihnen mitteilen zu können, dass wir eine Option hinzugefügt haben, mit der Sie die Spalten auf dem Taskboard anpassen können. Sie können jetzt die Spalten hinzufügen, entfernen, umbenennen und neu anordnen.

Um die Spalten auf Ihrem Taskboard zu konfigurieren, wechseln Sie zu Spaltenoptionen.

Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert.

Umschalten, um abgeschlossene untergeordnete Arbeitselemente im Backlog anzuzeigen oder auszublenden

Häufig möchten Sie beim Verfeinern des Backlogs nur Elemente anzeigen, die noch nicht abgeschlossen wurden. Jetzt können Sie abgeschlossene untergeordnete Elemente im Backlog anzeigen oder ausblenden.

Wenn der Umschalter aktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand angezeigt. Wenn die Umschaltfläche deaktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand aus dem Backlog ausgeblendet.

Die neuesten Tags, die beim Markieren eines Arbeitselements angezeigt werden

Beim Taggen eines Arbeitselements zeigt die Option automatisch vervollständigt jetzt bis zu fünf Ihrer zuletzt verwendeten Tags an. Dies erleichtert das Hinzufügen der richtigen Informationen zu Ihren Arbeitselementen.

Schreibgeschützte und erforderliche Regeln für die Gruppenmitgliedschaft

Mit Arbeitselementregeln können Sie bestimmte Aktionen für Arbeitselementfelder festlegen, um deren Verhalten zu automatisieren. Sie können eine Regel erstellen, um ein Feld basierend auf der Gruppenmitgliedschaft auf schreibgeschützt oder erforderlich festzulegen. Beispielsweise können Sie Produktbesitzern die Möglichkeit geben, die Priorität Ihrer Features festzulegen, während sie für alle anderen schreibgeschützt werden.

Anpassen von Systemauswahllistenwerten

Sie können jetzt die Werte für jede Systemauswahlliste (mit Ausnahme des Felds Grund) anpassen, z. B. Schweregrad, Aktivität, Priorität usw. Die Auswahllistenanpassungen sind so definiert, dass Sie unterschiedliche Werte für dasselbe Feld für jeden Arbeitselementtyp verwalten können.

Neuer URL-Parameter für Arbeitselemente

Teilen Sie Links zu Arbeitselementen mit dem Kontext Ihres Boards oder Backlogs mit unserem neuen Arbeitselement-URL-Parameter. Sie können jetzt ein Arbeitselementdialogfeld auf Ihrem Board, Backlog oder Sprint öffnen, indem Sie den Parameter ?workitem=[ID] an die URL anfügen.

Jeder, mit dem Sie den Link teilen, wird dann mit demselben Kontext landen, den Sie beim Teilen des Links hatten!

Personen, Arbeitselemente und PRs in Textfeldern erwähnen

Während wir Ihr Feedback gehört haben, haben wir erfahren, dass Sie Personen, Arbeitselemente und PRs im Arbeitsbereichsbeschreibungsbereich (und anderen HTML-Feldern) für das Arbeitselement und nicht nur in Kommentaren Erwähnung möchten. Manchmal arbeiten Sie mit jemandem an einem Arbeitselement zusammen oder möchten einen PR in Ihrer Arbeitselementbeschreibung hervorheben, hatten aber keine Möglichkeit, diese Informationen hinzuzufügen. Jetzt können Sie Personen, Arbeitselemente und PRs in allen langen Textfeldern des Arbeitselements Erwähnung.

Hier sehen Sie ein Beispiel.

• Um Personenerwähnungen zu verwenden, geben Sie das @ Zeichen und den Namen der Person ein, die Sie Erwähnung möchten. @mentions in Arbeitselementfeldern werden E-Mail-Benachrichtigungen wie für Kommentare generiert.
• Um Arbeitselementerwähnungen zu verwenden, geben Sie das # Zeichen gefolgt von der Arbeitselement-ID oder dem Titel ein. #mentions erstellt eine Verknüpfung zwischen den beiden Arbeitselementen.
• Um PR-Erwähnungen zu verwenden, fügen Sie eine ! gefolgt von Ihrer PR-ID oder Ihrem Namen hinzu.

Reaktionen auf Diskussionskommentare

Eines unserer Standard Ziele ist es, die Arbeitselemente für Teams kollaborativer zu gestalten. Kürzlich haben wir eine Umfrage auf Twitter durchgeführt, um herauszufinden, welche Zusammenarbeitsfunktionen Sie in Diskussionen über das Arbeitselement wünschen. Reaktionen auf Kommentare haben die Umfrage gewonnen, also fügen wir sie hinzu! Hier sind die Ergebnisse der Twitter-Umfrage.

Sie können Reaktionen zu jedem Kommentar hinzufügen, und es gibt zwei Möglichkeiten, Ihre Reaktionen hinzuzufügen: das Smileysymbol in der oberen rechten Ecke eines Kommentars sowie am unteren Rand eines Kommentars neben vorhandenen Reaktionen. Sie können alle sechs Reaktionen hinzufügen, wenn Sie möchten, oder nur eine oder zwei. Um Ihre Reaktion zu entfernen, klicken Sie auf die Reaktion am unteren Rand Ihres Kommentars, und sie wird entfernt. Im Folgenden sehen Sie die Erfahrungen beim Hinzufügen einer Reaktion und wie die Reaktionen auf einen Kommentar aussehen.

Anheften Azure Boards Berichte an die Dashboard

Im Sprint 155-Update haben wir aktualisierte Versionen der CFD- und Velocity-Berichte aufgenommen. Diese Berichte sind auf der Registerkarte Analyse unter Boards und Backlogs verfügbar. Jetzt können Sie die Berichte direkt an Ihr Dashboard anheften. Um die Berichte anzuheften, zeigen Sie auf den Bericht, und wählen Sie die Auslassungspunkte "..." und In Dashboard kopieren.

Nachverfolgen des Fortschritts übergeordneter Elemente mithilfe des Backlogs für rollup on Boards

Rollupspalten zeigen Statusleisten und/oder Gesamtsummen numerischer Felder oder untergeordneter Elemente innerhalb einer Hierarchie an. Nachfolgerelemente entsprechen allen untergeordneten Elementen innerhalb der Hierarchie. Einem Produkt- oder Portfoliobacklog können mindestens eine Rollupspalte hinzugefügt werden.

Im folgenden Screenshot sehen Sie z. B. die Spalte Fortschritt nach allen Arbeitselementen, in der Statusleisten für Vorgängerarbeitselemente basierend auf dem Prozentsatz der geschlossenen Nachfolgerelemente angezeigt werden. Untergeordnete Elemente für Epics enthalten alle untergeordneten Features und ihre untergeordneten oder untergeordneten Arbeitselemente. Untergeordnete Elemente für Features umfassen alle untergeordneten Benutzergeschichten und ihre untergeordneten Arbeitselemente.

Taskboard-Liveupdates

Ihr Taskboard wird jetzt automatisch aktualisiert, wenn Änderungen auftreten! Wenn andere Teammitglieder Karten auf dem Taskboard verschieben oder neu anordnen, wird Ihr Board automatisch mit diesen Änderungen aktualisiert. Sie müssen nicht mehr F5 drücken, um die neuesten Änderungen anzuzeigen.

Unterstützung für benutzerdefinierte Felder in Rollupspalten

Ein Rollup kann jetzt für jedes Feld durchgeführt werden, einschließlich benutzerdefinierter Felder. Wenn Sie eine Rollupspalte hinzufügen, können Sie dennoch eine Rollupspalte aus der Schnellliste auswählen. Wenn Sie jedoch ein Rollup für numerische Felder ausführen möchten, die nicht Teil der out-of-the-box-Prozessvorlage sind, können Sie Ihre eigene wie folgt konfigurieren:

1. Klicken Sie in Ihrem Backlog auf "Spaltenoptionen". Klicken Sie dann im Bereich auf "Rollupspalte hinzufügen" und dann auf Benutzerdefiniertes Rollup konfigurieren.

   

2. Wählen Sie zwischen Fortschrittsleiste und Gesamt aus.
3. Wählen Sie einen Arbeitselementtyp oder eine Backlogebene aus (in der Regel werden mehrere Arbeitselementtypen aggregiert).
4. Wählen Sie den Aggregationstyp aus. Anzahl der Arbeitselemente oder Summe. Für Summe müssen Sie das feld auswählen, das zusammengefasst werden soll.
5. Über die Schaltfläche OK gelangen Sie zurück zum Spaltenoptionenbereich, in dem Sie Ihre neue benutzerdefinierte Spalte neu anordnen können.

Beachten Sie, dass Sie Ihre benutzerdefinierte Spalte nicht bearbeiten können, nachdem Sie auf OK geklickt haben. Wenn Sie eine Änderung vornehmen müssen, entfernen Sie die benutzerdefinierte Spalte, und fügen Sie eine weitere Spalte wie gewünscht hinzu.

Neue Regel zum Ausblenden von Feldern in einem Arbeitselementformular basierend auf einer Bedingung

Wir haben der geerbten Regel-Engine eine neue Regel hinzugefügt, mit der Sie Felder in einem Arbeitselementformular ausblenden können. Diese Regel blendet Felder basierend auf der Gruppenmitgliedschaft der Benutzer aus. Wenn der Benutzer beispielsweise zur Gruppe "Product Owner" gehört, können Sie ein entwicklerspezifisches Feld ausblenden. Weitere Informationen finden Sie in der Dokumentation hier.

Benachrichtigungseinstellungen für benutzerdefinierte Arbeitselemente

Es ist unglaublich wichtig, über Arbeitselemente auf dem Laufenden zu bleiben, die für Sie oder Ihr Team relevant sind. Es hilft Teams dabei, zusammenzuarbeiten und bei Projekten auf dem richtigen Weg zu bleiben, und stellt sicher, dass alle richtigen Parteien beteiligt sind. Allerdings haben verschiedene Akteure unterschiedliche Investitionen in unterschiedliche Anstrengungen, und wir glauben, dass sich dies in Ihrer Fähigkeit widerspiegeln sollte, die status eines Arbeitselements zu verfolgen.

Wenn Sie zuvor einem Arbeitselement folgen und Benachrichtigungen über vorgenommene Änderungen erhalten möchten, erhalten Sie E-Mail-Benachrichtigungen für alle änderungen, die am Arbeitselement vorgenommen wurden. Nachdem Wir Ihr Feedback berücksichtigt haben, machen wir das Befolgen eines Arbeitselements für alle Beteiligten flexibler. Nun wird eine neue Einstellungsschaltfläche neben der Schaltfläche Folgen in der oberen rechten Ecke des Arbeitselements angezeigt. Dadurch gelangen Sie zu einem Popupfenster, in dem Sie Ihre Folgeoptionen konfigurieren können.

Unter Benachrichtigungseinstellungen können Sie aus drei Benachrichtigungsoptionen auswählen. Zunächst können Sie vollständig abbestellt werden. Zweitens können Sie vollständig abonniert sein, wo Sie Benachrichtigungen für alle Änderungen an Arbeitselementen erhalten. Schließlich können Sie sich für einige der wichtigsten Änderungsereignisse für Arbeitselemente benachrichtigen lassen. Sie können nur eine oder alle drei Optionen auswählen. Dadurch können Teammitglieder Arbeitselemente auf höherer Ebene verfolgen und nicht von jeder einzelnen Vorgenommenen Änderung abgelenkt werden. Mit diesem Feature vermeiden wir unnötige E-Mails und ermöglichen Es Ihnen, sich auf die wichtigen Aufgaben zu konzentrieren.

Verknüpfen von Arbeitselementen mit Bereitstellungen

Wir freuen uns, die Bereitstellungssteuerung für das Arbeitselementformular freizugeben. Dieses Steuerelement verknüpft Ihre Arbeitselemente mit einer Version und ermöglicht Es Ihnen, auf einfache Weise nachzuverfolgen, wo Ihr Arbeitselement bereitgestellt wurde. Weitere Informationen finden Sie in der Dokumentation hier.

Importieren von Arbeitselementen aus einer CSV-Datei

Bisher war der Import von Arbeitselementen aus einer CSV-Datei von der Verwendung des Excel-Plug-Ins abhängig. In diesem Update bieten wir eine erstklassige Importumgebung direkt aus Azure Boards, sodass Sie neue oder vorhandene Arbeitselemente importieren oder aktualisieren können. Weitere Informationen finden Sie in der Dokumentation hier.

Hinzufügen eines übergeordneten Felds zu Arbeitselementkarten

Übergeordneter Kontext ist jetzt in Ihrem Kanban-Board als neues Feld für Arbeitselementkarten verfügbar. Sie können jetzt das Feld Übergeordnetes Zu Ihren Karten hinzufügen, ohne dass Problemumgehungen wie Tags und Präfixe verwendet werden müssen.

Hinzufügen eines übergeordneten Felds zu Backlog und Abfragen

Das übergeordnete Feld ist jetzt verfügbar, wenn Backlogs und Abfrageergebnisse angezeigt werden. Um das übergeordnete Feld hinzuzufügen, verwenden Sie die Ansicht Spaltenoptionen .

Repos

Code coverage metrics and branch policy for pull requests

Sie können jetzt Code Coverage-Metriken für Änderungen in der Pull Request -Ansicht (PR) anzeigen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen durch automatisierte Tests angemessen getestet haben. Coverage status werden als Kommentar in der PR-Übersicht angezeigt. Sie können Details der Abdeckungsinformationen für jede Codezeile anzeigen, die in der Datei diff Ansicht geändert wird.

Darüber hinaus können Repositorybesitzer jetzt Codeabdeckungsrichtlinien festlegen und verhindern, dass große, nicht getestete Änderungen in einem Branch zusammengeführt werden. Gewünschte Abdeckungsschwellenwerte können in einer azurepipelines-coverage.yml Einstellungsdatei definiert werden, die im Stammverzeichnis des Repositorys eingecheckt wird, und die Abdeckungsrichtlinie kann mithilfe der vorhandenen Konfiguration einer Branchrichtlinie für zusätzliche Dienste in Azure Repos definiert werden.

Filtern von Kommentarbenachrichtigungen aus Pull Requests

Kommentare in Pull Requests können aufgrund von Benachrichtigungen häufig zu viel Rauschen führen. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie abonnieren, nach Kommentaralter, Kommentar, gelöschtem Kommentar, erwähnten Benutzern, Pull Request-Autor, Zielbranch und Threadteilnehmern. Sie können diese Benachrichtigungsabonnements erstellen, indem Sie in der oberen rechten Ecke auf das Benutzersymbol klicken und zu Benutzereinstellungen navigieren.

Diensthaken für Pull Request-Kommentare

Sie können jetzt Diensthaken für Kommentare in einem Pull Request basierend auf Repository und Zielbranch erstellen.

Richtlinie zum Blockieren von Dateien mit angegebenen Mustern

Administratoren können jetzt eine Richtlinie festlegen, um zu verhindern, dass Commits basierend auf Dateitypen und Pfaden in ein Repository gepusht werden. Die Dateinamenüberprüfungsrichtlinie blockiert Pushvorgänge, die dem angegebenen Muster entsprechen.

Auflösen von Arbeitselementen über Commits mithilfe von Schlüsselwörtern

Sie können jetzt Arbeitselemente über Commits auflösen, die an die Standardbranch vorgenommen wurden, indem Sie Schlüsselwörter wie Fix, Fixes oder Fixed verwenden. Sie können z. B. "This change fixed #476" in Ihre Commitnachricht schreiben, und das Arbeitselement #476 wird abgeschlossen, wenn der Commit per Push übertragen oder in die Standardbranch zusammengeführt wird. Weitere Informationen finden Sie in der Dokumentation hier.

Granularität für automatische Prüfer

Bisher war beim Hinzufügen von Prüfern auf Gruppenebene zu einem Pull Request nur eine Genehmigung von der hinzugefügten Gruppe erforderlich. Jetzt können Sie Richtlinien festlegen, die mehr als einen Prüfer aus einem Team erfordern, um einen Pull Request zu genehmigen, wenn automatische Prüfer hinzugefügt werden. Darüber hinaus können Sie eine Richtlinie hinzufügen, um zu verhindern, dass Anforderer ihre eigenen Änderungen genehmigen.

Verwenden der dienstkontobasierten Authentifizierung zum Herstellen einer Verbindung mit AKS

Bisher haben wir beim Konfigurieren von Azure Pipelines über das AKS Deployment Center eine Azure Resource Manager-Verbindung verwendet. Diese Verbindung hatte Zugriff auf den gesamten Cluster und nicht nur auf den Namespace, für den die Pipeline konfiguriert wurde. Mit diesem Update verwenden unsere Pipelines die dienstkontobasierte Authentifizierung, um eine Verbindung mit dem Cluster herzustellen, sodass er nur Zugriff auf den namespace hat, der der Pipeline zugeordnet ist.

Vorschau von Markdowndateien in Pull Request Parallele diff

Sie können jetzt eine Vorschau der Darstellung einer Markdowndatei anzeigen, indem Sie die neue Schaltfläche Vorschau verwenden. Darüber hinaus können Sie den vollständigen Inhalt einer Datei aus der parallelen diff anzeigen, indem Sie die Schaltfläche Ansicht auswählen.

Ablauf der Buildrichtlinie für manuelle Builds

Richtlinien erzwingen die Codequalitäts- und Change Management-Standards Ihres Teams. Zuvor konnten Sie Buildablaufrichtlinien für automatisierte Builds festlegen. Jetzt können Sie Buildablaufrichtlinien auch auf Ihre manuellen Builds festlegen.

Hinzufügen einer Richtlinie zum Blockieren von Commits basierend auf der E-Mail des Commitautors

Administratoren können jetzt eine Pushrichtlinie festlegen, um zu verhindern, dass Commits in ein Repository gepusht werden, für das die Commitautor-E-Mail nicht mit dem angegebenen Muster übereinstimmt.

Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert, um eine ähnliche Benutzeroberfläche bereitzustellen. Wir halten das Ticket weiterhin geöffnet und ermutigen Die Benutzer, uns mitzuteilen, welche anderen Arten von Pushrichtlinien Sie sehen möchten.

Markieren von Dateien als überprüft in einem Pull Request

Manchmal müssen Sie Pull Requests überprüfen, die Änderungen an einer großen Anzahl von Dateien enthalten, und es kann schwierig sein, nachzuverfolgen, welche Dateien Sie bereits überprüft haben. Jetzt können Sie Dateien in einem Pull Request als überprüft markieren.

Sie können eine Datei als überprüft markieren, indem Sie das Dropdownmenü neben einem Dateinamen verwenden oder mit dem Mauszeiger auf den Dateinamen klicken.

Hinweis

Dieses Feature dient nur dazu, Ihren Fortschritt zu verfolgen, wenn Sie einen Pull Request überprüfen. Es stellt keine Abstimmung über Pull Requests dar, sodass diese Markierungen nur für den Prüfer sichtbar sind.

Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert.

Neue Web-Benutzeroberfläche für Azure Repos Landing Pages

Sie können jetzt unsere neuen modernen, schnellen und mobilfreundlichen Landing Pages in Azure Repos ausprobieren. Diese Seiten sind als Neue Repos-Zielseiten verfügbar. Zielseiten enthalten alle Seiten mit Ausnahme von Pull Request-Details, Commitdetails und Branchvergleichen.

Web

Mobil

Cross-Repo Branch-Richtlinienverwaltung

Branchrichtlinien sind eines der leistungsstarken Features von Azure Repos, mit denen Sie wichtige Branches schützen können. Obwohl die Möglichkeit zum Festlegen von Richtlinien auf Projektebene in der REST-API vorhanden ist, gab es dafür keine Benutzeroberfläche. Jetzt können Administratoren Richtlinien für einen bestimmten Branch oder die Standardbranch für alle Repositorys in ihrem Projekt festlegen. Beispielsweise könnte ein Administrator zwei Mindestprüfer für alle Pull Requests anfordern, die in jedem Standard Branch in jedem Repository in ihrem Projekt ausgeführt werden. Sie finden das Feature Branchschutz hinzufügen in den Repository-Projekteinstellungen.

Neue Zielseiten für die Webplattformkonvertierung

Wir haben die Benutzeroberfläche für Repos-Zielseiten aktualisiert, um sie modern, schnell und mobil zu gestalten. Im Folgenden finden Sie zwei Beispiele für die Seiten, die aktualisiert wurden. In zukünftigen Updates werden weitere Seiten aktualisiert.

Weberfahrung:

Mobile Erfahrung:

Unterstützung für die Sprache Kotlin

Wir freuen uns, Ihnen mitteilen zu können, dass wir jetzt die Sprachheraushebung von Kotlin im Datei-Editor unterstützen. Die Hervorhebung verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen, schnell zu überprüfen, um Fehler zu finden. Wir haben dieses Feature basierend auf einem Vorschlag aus dem Entwicklercommunity priorisiert.

Benutzerdefiniertes Benachrichtigungsabonnement für Pull Requests-Entwürfe

Um die Anzahl der E-Mail-Benachrichtigungen von Pull Requests zu reduzieren, können Sie jetzt ein benutzerdefiniertes Benachrichtigungsabonnement für Pull Requests erstellen, die im Entwurfszustand erstellt oder aktualisiert werden. Sie können E-Mails speziell für Entwürfe von Pull Requests erhalten oder E-Mails aus Pull Requests-Entwürfen herausfiltern, damit Ihr Team nicht benachrichtigt wird, bevor der Pull Request zur Überprüfung bereit ist.

Verbesserte PR-Umsetzbarkeit

Wenn Sie viele Pull Requests überprüfen müssen, kann es schwierig sein, zu verstehen, wo Sie zuerst maßnahmen sollten. Um die Aktionsfähigkeit von Pull Request zu verbessern, können Sie jetzt mehrere benutzerdefinierte Abfragen auf der Seite der Pull Request-Liste mit mehreren neuen Optionen erstellen, nach denen Gefiltert werden kann, z. B. entwurfszustand. Diese Abfragen erstellen separate und reduzierbare Abschnitte auf Ihrer Pull Request-Seite sowie "Von mir erstellt" und "Mir zugewiesen". Sie können es auch ablehnen, einen Pull Request zu überprüfen, dem Sie über das Abstimmungsmenü oder das Kontextmenü auf der Pull Request-Listenseite hinzugefügt wurden. In den benutzerdefinierten Abschnitten werden nun separate Registerkarten für Pull Requests angezeigt, für die Sie eine Überprüfung bereitgestellt oder abgelehnt haben. Diese benutzerdefinierten Abfragen funktionieren repositoryübergreifend auf der Registerkarte "Meine Pull Requests" der Sammlungsstartseite. Wenn Sie zu einem Pull Request zurückkehren möchten, können Sie ihn kennzeichnen, und sie werden oben in der Liste angezeigt. Schließlich werden Pull Requests, die auf auto-complete festgelegt wurden, mit einer Pille gekennzeichnet, die in der Liste "Auto-complete" lautet.

Pipelines

Mehrstufige Pipelines

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Pipelines zu verwalten. Diese Updates machen die Pipelines modern und konsistent mit der Richtung von Azure DevOps. Darüber hinaus vereinen diese Updates klassische Buildpipelines und mehrstufige YAML-Pipelines in einer einzigen Oberfläche. Es ist für Mobilgeräte geeignet und bietet verschiedene Verbesserungen bei der Verwaltung Ihrer Pipelines. Sie können Einen Drilldown durchführen und Pipelinedetails anzeigen, Details ausführen, Pipelineanalysen, Auftragsdetails, Protokolle und vieles mehr.

Die folgenden Funktionen sind in der neuen Benutzeroberfläche enthalten:

• Anzeigen und Verwalten mehrerer Phasen
• Genehmigen von Pipelineausführungen
• Scrollen Sie den ganzen Weg zurück in Protokollen, während eine Pipeline noch ausgeführt wird
• Pro-Branch-Integrität einer Pipeline.

Continuous deployment in YAML

Wir freuen uns, Die YAML-CD-Features von Azure Pipelines bereitstellen zu können. Wir bieten jetzt eine einheitliche YAML-Benutzeroberfläche, sodass Sie jede Ihrer Pipelines so konfigurieren können, dass CI, CD oder CI und CD gemeinsam ausgeführt werden. YaML CD-Features führen mehrere neue erweiterte Features ein, die für alle Sammlungen mit mehrstufigen YAML-Pipelines verfügbar sind. Einige der Highlights sind unter anderem:

• Mehrstufige YAML-Pipelines (für CI und CD)
• Genehmigungen und Überprüfungen von Ressourcen
• Umgebungen und Bereitstellungsstrategien
• Kubernetes - und VM-Ressourcen in der Umgebung
• Überprüfen von Apps auf Zusammenarbeit
• Aktualisierte Benutzeroberfläche für Dienstverbindungen
• Ressourcen in YAML-Pipelines

Wenn Sie mit dem Erstellen beginnen möchten, lesen Sie die Dokumentation oder den Blog zum Erstellen mehrstufiger CI/CD-Pipelines.

Verwalten von Pipelinevariablen im YAML-Editor

Wir haben die Benutzeroberfläche für die Verwaltung von Pipelinevariablen im YAML-Editor aktualisiert. Sie müssen nicht mehr zum klassischen Editor wechseln, um Variablen in Ihren YAML-Pipelines hinzuzufügen oder zu aktualisieren.

Genehmigen von Releases direkt über den Releases-Hub

Die Bearbeitung ausstehender Genehmigungen wurde erleichtert. Zuvor war es möglich, eine Version auf der Detailseite des Releases zu genehmigen. Sie können Releases jetzt direkt über den Releases Hub genehmigen.

Verbesserungen bei den ersten Schritten mit Pipelines

Eine häufige Frage mit dem Assistenten für die ersten Schritte war die Möglichkeit, die generierte Datei umzubenennen. Derzeit wird es als azure-pipelines.yml im Stammverzeichnis Ihres Repositorys eingecheckt. Sie können dies nun auf einen anderen Dateinamen oder Speicherort aktualisieren, bevor Sie die Pipeline speichern.

Schließlich haben Sie mehr Kontrolle beim Einchecken der azure-pipelines.yml Datei in einen anderen Branch, da Sie das Erstellen eines Pull Requests aus diesem Branch überspringen können.

Vorschau eines vollständig analysierten YAML-Dokuments ohne Commit oder Ausführen der Pipeline

Wir haben eine Vorschauversion hinzugefügt, aber keinen Ausführungsmodus für YAML-Pipelines. Jetzt können Sie eine YAML-Pipeline ausprobieren, ohne sie in ein Repository zu übertragen oder auszuführen. Angesichts einer vorhandenen Pipeline und einer optionalen neuen YAML-Nutzlast erhalten Sie mit dieser neuen API die vollständige YAML-Pipeline zurück. In zukünftigen Updates wird diese API in einem neuen Editorfeature verwendet.

Für Entwickler: POST mit dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview einem JSON-Text wie folgt:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

Die Antwort enthält das gerenderte YAML.

Cronzeitpläne in YAML

Zuvor konnten Sie den UI-Editor verwenden, um einen geplanten Trigger für YAML-Pipelines anzugeben. Mit diesem Release können Sie Builds mit cron-Syntax in Ihrer YAML-Datei planen und die folgenden Vorteile nutzen:

1. Als Code konfigurieren: Sie können die Zeitpläne zusammen mit Ihrer Pipeline als Teil von Code nachverfolgen.
2. Ausdrucksstark: Sie haben mehr Ausdruckskraft beim Definieren von Zeitplänen als das, was Sie mit der Benutzeroberfläche erreichen konnten. Für instance ist es einfacher, einen einzelnen Zeitplan anzugeben, der jede Stunde eine Ausführung startet.
3. Branchenstandard: Viele Entwickler und Administratoren sind bereits mit der Cron-Syntax vertraut.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Wir haben es Ihnen auch leicht gemacht, Probleme mit Cron-Zeitplänen zu diagnostizieren. Mit den geplanten Ausführungen im Menü Pipeline ausführen erhalten Sie eine Vorschau auf die bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Fehler mit Ihren Cron-Zeitplänen zu diagnostizieren.

Benutzeroberfläche für Updates zu Dienstverbindungen

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Dienstverbindungen zu verwalten. Diese Updates machen die Dienstverbindung modern und konsistent mit der Richtung von Azure DevOps. Anfang dieses Jahres haben wir die neue Benutzeroberfläche für Dienstverbindungen als Vorschaufeature eingeführt. Vielen Dank an alle, die die neue Erfahrung ausprobiert haben und uns ihr wertvolles Feedback gegeben haben.

Neben der Aktualisierung der Benutzeroberfläche haben wir auch zwei Funktionen hinzugefügt, die für die Nutzung von Dienstverbindungen in YAML-Pipelines von entscheidender Bedeutung sind: Pipelineautorisierungen und Genehmigungen und Überprüfungen.

Die neue Benutzeroberfläche wird mit diesem Update standardmäßig aktiviert . Sie haben weiterhin die Möglichkeit, die Vorschau abzuwählen.

Hinweis

Wir planen, projektübergreifendes Teilen von Diensten Connections als neue Funktion einzuführen. Weitere Informationen zur Freigabe und zu den Sicherheitsrollen finden Sie hier.

Überspringen von Phasen in einer YAML-Pipeline

Wenn Sie eine manuelle Ausführung starten, sollten Sie manchmal einige Phasen in Ihrer Pipeline überspringen. Für instance, wenn Sie keine Bereitstellung in der Produktion durchführen möchten oder wenn Sie die Bereitstellung in einigen Umgebungen in der Produktion überspringen möchten. Sie können dies jetzt mit Ihren YAML-Pipelines tun.

Der aktualisierte Ausführungspipelinebereich zeigt eine Liste der Phasen aus der YAML-Datei an, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Sie müssen beim Überspringen von Phasen Vorsicht walten lassen. Wenn ihre erste Phase für instance bestimmte Artefakte erzeugt, die für nachfolgende Phasen benötigt werden, sollten Sie die erste Phase nicht überspringen. Der Ausführungsbereich zeigt eine allgemeine Warnung an, wenn Sie Phasen überspringen, die nachgelagerte Abhängigkeiten aufweisen. Es bleibt Ihnen überlassen, ob es sich bei diesen Abhängigkeiten um echte Artefaktabhängigkeiten handelt oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.

Das Überspringen einer Phase entspricht dem erneuten Verdrahten der Abhängigkeiten zwischen den Phasen. Alle unmittelbar nachgelagerten Abhängigkeiten der übersprungenen Phase hängen vom Upstream übergeordneten Der übersprungenen Phase ab. Wenn bei der Ausführung ein Fehler auftritt und Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, weist auch dieser Versuch das gleiche Übersprungverhalten auf. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.

Neue Benutzeroberfläche für Dienstverbindungen als Standardumgebung

Es gibt eine neue Benutzeroberfläche für Dienstverbindungen. Diese neue Benutzeroberfläche basiert auf modernen Designstandards und verfügt über verschiedene wichtige Features zur Unterstützung mehrstufiger YAML-CD-Pipelines wie Genehmigungen, Autorisierungen und projektübergreifender Freigabe.

Weitere Informationen zu Dienstverbindungen finden Sie hier.

Pipelineressourcenversionsauswahl im Dialogfeld "Ausführen erstellen"

Wir haben die Möglichkeit hinzugefügt, Pipelineressourcenversionen im Dialogfeld "Erstellen ausführen" manuell zu erfassen. Wenn Sie eine Pipeline als Ressource in einer anderen Pipeline nutzen, können Sie nun die Version dieser Pipeline auswählen, wenn Sie eine Ausführung erstellen.

az CLI-Verbesserungen für Azure Pipelines

Befehle zur Pipelinevariablengruppe und Variablenverwaltung

Es kann schwierig sein, YAML-basierte Pipelines von einem Projekt in ein anderes zu portieren, da Sie die Pipelinevariablen und Variablengruppen manuell einrichten müssen. Mit der Pipelinevariablengruppe und den Befehlen für die Variablenverwaltung können Sie jetzt das Einrichten und Verwalten von Pipelinevariablen und Variablengruppen per Skript ausführen, die wiederum versionsgesteuert werden können, sodass Sie problemlos die Anweisungen zum Verschieben und Einrichten von Pipelines von einem Projekt zum anderen freigeben können.

Ausführen der Pipeline für einen PR-Branch

Beim Erstellen eines PR kann es schwierig sein, zu überprüfen, ob die Änderungen die Pipelineausführung auf dem Zielbranch unterbrechen könnten. Mit der Möglichkeit, eine Pipelineausführung auszulösen oder einen Build für einen PR-Branch in eine Warteschlange zu stellen, können Sie nun die änderungen überprüfen und visualisieren, indem Sie ihn für die Zielpipeline ausführen. Weitere Informationen finden Sie in der Dokumentation zum Befehl az pipelines run und az pipelines build queue .

Überspringen der ersten Pipelineausführung

Beim Erstellen von Pipelines möchten Sie manchmal eine YAML-Datei erstellen und committen und die Pipelineausführung nicht auslösen, da dies aus verschiedenen Gründen zu einer fehlerhaften Ausführung führen kann. Die Infrastruktur ist nicht bereit oder muss Variablen-/Variablengruppen usw. erstellen und aktualisieren. Mit der Azure DevOps CLI können Sie jetzt die erste automatisierte Pipelineausführung beim Erstellen einer Pipeline überspringen, indem Sie den Parameter --skip-first-run einschließen. Weitere Informationen finden Sie in der Dokumentation zum Befehl az pipeline create .

Dienstendpunktbefehlserweiterung

Cli-Befehle des Dienstendpunkts unterstützten nur die Einrichtung und Verwaltung des Dienstendpunkts azure rm und github. Mit dieser Version können Sie jedoch mithilfe von Dienstendpunkten einen beliebigen Dienstendpunkt erstellen, indem Sie die Konfiguration per Datei bereitstellen und optimierte Befehle bereitstellen– az devops service-endpoint github und az devops service-endpoint azurerm, die erstklassige Unterstützung zum Erstellen von Dienstendpunkten dieser Art bieten. Weitere Informationen finden Sie in der Befehlsdokumentation .

Bereitstellungsaufträge

Ein Bereitstellungsauftrag ist ein besonderer Auftragstyp , der zum Bereitstellen Ihrer App in einer Umgebung verwendet wird. Mit diesem Update haben wir Unterstützung für Schrittverweise in einem Bereitstellungsauftrag hinzugefügt. Beispielsweise können Sie eine Reihe von Schritten in einer Datei definieren und in einem Bereitstellungsauftrag darauf verweisen.

Außerdem haben wir dem Bereitstellungsauftrag unterstützung für zusätzliche Eigenschaften hinzugefügt. Hier finden Sie beispielsweise einige Eigenschaften eines Bereitstellungsauftrags, die Sie jetzt festlegen können:

• timeoutInMinutes : Wie lange der Auftrag ausgeführt werden soll, bevor er automatisch abgebrochen wird
• cancelTimeoutInMinutes : Wie viel Zeit soll "Immer ausgeführt werden, auch wenn Aufgaben abgebrochen werden" vor dem Beenden der Aufgaben
• Bedingung : Auftrag bedingt ausführen
• Variablen : Hartcodierte Werte können direkt oder Variablengruppen hinzugefügt werden, Variablengruppen, die von einem Azure-Schlüsseltresor unterstützt werden, können referenziert werden, oder Sie können auf eine Gruppe von Variablen verweisen, die in einer Datei definiert sind.
• continueOnError : Wenn zukünftige Aufträge ausgeführt werden sollen, auch wenn dieser Bereitstellungsauftrag fehlschlägt; standardwert auf "false"

Weitere Informationen zu Bereitstellungsaufträgen und der vollständigen Syntax zum Angeben eines Bereitstellungsauftrags finden Sie unter Bereitstellungsauftrag.

Anzeigen zugeordneter CD-Pipelines-Informationen in CI-Pipelines

Wir haben unterstützung für die CD-YAML-Pipelines hinzugefügt, wobei die CI-Pipelines als Pipelineressourcen bezeichnet werden. In ihrer CI-Pipelineausführungsansicht wird nun eine neue Registerkarte "Zugeordnete Pipelines" angezeigt, auf der Sie alle Pipelineausführungen finden können, die Ihre Pipeline nutzen, und Artefakte daraus.

Unterstützung für GitHub-Pakete in YAML-Pipelines

Wir haben kürzlich einen neuen Ressourcentyp namens Packages eingeführt, der Unterstützung für die Nutzung von NuGet - und npm-Paketen von GitHub als Ressource in YAML-Pipelines hinzufügt. Als Teil dieser Ressource können Sie jetzt den Pakettyp (NuGet oder npm) angeben, den Sie über GitHub nutzen möchten. Sie können auch automatisierte Pipelinetrigger nach der Veröffentlichung einer neuen Paketversion aktivieren. Heute steht der Support nur für die Nutzung von Paketen von GitHub zur Verfügung, aber in Zukunft planen wir, die Unterstützung zu erweitern, um Pakete aus anderen Paketrepositorys wie NuGet, npm, AzureArtifacts und viele mehr zu nutzen. Weitere Informationen finden Sie im folgenden Beispiel:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Hinweis

GitHub-Pakete unterstützen heute nur DIE PAT-basierte Authentifizierung. Dies bedeutet, dass die GitHub-Dienstverbindung in der Paketressource vom Typ PAT sein sollte. Sobald diese Einschränkung aufgehoben wurde, bieten wir Unterstützung für andere Authentifizierungstypen.

Standardmäßig werden Pakete in Ihren Aufträgen nicht automatisch heruntergeladen. Daher haben wir ein getPackage-Makro eingeführt, mit dem Sie das in der Ressource definierte Paket nutzen können. Weitere Informationen finden Sie im folgenden Beispiel:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

ressourcenansicht Azure Kubernetes Service Clusterlink in Kubernetes-Umgebungen

Wir haben einen Link zur Ressourcenansicht von Kubernetes-Umgebungen hinzugefügt, damit Sie zum Azure-Blatt für den entsprechenden Cluster navigieren können. Dies gilt für Umgebungen, die Namespaces in Azure Kubernetes Service Clustern zugeordnet sind.

Freigabeordnerfilter in Benachrichtigungsabonnements

Ordner ermöglichen das Organisieren von Pipelines für eine einfachere Auffindbarkeit und Sicherheitskontrolle. Häufig möchten Sie möglicherweise benutzerdefinierte E-Mail-Benachrichtigungen für alle Releasepipelines konfigurieren, die von allen Pipelines in einem Ordner dargestellt werden. Zuvor mussten Sie mehrere Abonnements konfigurieren oder komplexe Abfragen in den Abonnements haben, um fokussierte E-Mails zu erhalten. Mit diesem Update können Sie jetzt eine Releaseordnerklausel zu den Ereignissen "Bereitstellung abgeschlossen" und "Genehmigung ausstehend " hinzufügen und die Abonnements vereinfachen.

Verknüpfen von Arbeitselementen mit mehrstufigen YAML-Pipelines

Derzeit können Sie Arbeitselemente automatisch mit klassischen Builds verknüpfen. Dies war jedoch mit YAML-Pipelines nicht möglich. Mit diesem Update haben wir diese Lücke behoben. Wenn Sie eine Pipeline erfolgreich mit Code aus einem angegebenen Branch ausführen, ordnet Azure Pipelines die Ausführung automatisch allen Arbeitselementen zu (die über die Commits in diesem Code abgeleitet werden). Wenn Sie das Arbeitselement öffnen, können Sie die Ausführungen sehen, in denen der Code für dieses Arbeitselement erstellt wurde. Verwenden Sie den Einstellungsbereich einer Pipeline, um dies zu konfigurieren.

Abbrechen der Phase in einer mehrstufigen YAML-Pipelineausführung

Wenn Sie eine mehrstufige YAML-Pipeline ausführen, können Sie jetzt die Ausführung einer Phase abbrechen, während sie ausgeführt wird. Dies ist hilfreich, wenn Sie wissen, dass die Phase fehlschlägt oder wenn Sie eine andere Ausführung haben, die Sie starten möchten.

Wiederholung fehlgeschlagener Phasen

Eines der am häufigsten angeforderten Features in mehrstufigen Pipelines ist die Möglichkeit, eine fehlgeschlagene Phase zu wiederholen, ohne von Anfang an beginnen zu müssen. Mit diesem Update fügen wir einen großen Teil dieser Funktionalität hinzu.

Sie können jetzt eine Pipelinephase wiederholen, wenn die Ausführung fehlschlägt. Alle Aufträge, die beim ersten Versuch fehlgeschlagen sind, und alle Aufträge, die transitiv von diesen fehlerhaften Aufträgen abhängen, werden erneut versucht.

Dies kann Ihnen dabei helfen, Auf verschiedene Weise Zeit zu sparen. Wenn Sie für instance mehrere Aufträge in einer Phase ausführen, möchten Sie möglicherweise, dass jede Phase Tests auf einer anderen Plattform ausführen. Wenn die Tests auf einer Plattform fehlschlagen, während andere bestehen, können Sie Zeit sparen, indem Sie die erfolgreichen Aufträge nicht erneut ausführen. Ein weiteres Beispiel ist, dass eine Bereitstellungsphase aufgrund einer fehlerhaften Netzwerkverbindung fehlgeschlagen ist. Wenn Sie diese Phase wiederholen, sparen Sie Zeit, da Sie keinen weiteren Build erstellen müssen.

Es gibt einige bekannte Lücken in diesem Feature. Beispielsweise können Sie eine Phase, die Sie explizit abbrechen, nicht wiederholen. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.

Genehmigungen in mehrstufigen YAML-Pipelines

Ihre YAML-CD-Pipelines können manuelle Genehmigungen enthalten. Infrastrukturbesitzer können ihre Umgebungen schützen und manuelle Genehmigungen einholen, bevor eine Phase in einer Pipeline für sie bereitgestellt wird. Mit der vollständigen Trennung der Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie sicher, dass die Bereitstellung in einer bestimmten Pipeline manuell abgemeldet wird, und sie erhalten die zentrale Kontrolle über das Anwenden der gleichen Überprüfungen für alle Bereitstellungen auf die Umgebung.

Die Pipeline führt die Bereitstellung für die Entwicklung aus, wird zu Beginn der Phase zur Genehmigung beendet.

Erhöhung des Timeoutlimits und der Häufigkeit von Gates

Bisher betrug das Timeoutlimit für Gate in Releasepipelines drei Tage. Mit diesem Update wurde das Timeoutlimit auf 15 Tage erhöht, um Gates mit längerer Dauer zuzulassen. Wir haben auch die Frequenz des Gates auf 30 Minuten erhöht.

Neue Buildimagevorlage für Dockerfile

Zuvor wurde beim Erstellen einer neuen Pipeline für eine Dockerfile-Datei in einer neuen Pipeline empfohlen, das Image per Push an einen Azure Container Registry zu übertragen und in einem Azure Kubernetes Service bereitzustellen. Wir haben eine neue Vorlage hinzugefügt, mit der Sie ein Image mit dem Agent erstellen können, ohne pushen in eine Containerregistrierung zu müssen.

Neue Aufgabe zum Konfigurieren Azure App Service App-Einstellungen

Azure App Service ermöglicht die Konfiguration über verschiedene Einstellungen wie App-Einstellungen, Verbindungszeichenfolgen und andere allgemeine Konfigurationseinstellungen. Wir verfügen jetzt über eine neue Azure Pipelines-Aufgabe Azure App Service Einstellungen, die das Massenkonfigurieren dieser Einstellungen mithilfe von JSON-Syntax in Ihrer Web-App oder einem ihrer Bereitstellungsslots unterstützt. Diese Aufgabe kann zusammen mit anderen App Service-Aufgaben verwendet werden, um Ihre Web-Apps, Funktions-Apps oder andere containerisierte App Services bereitzustellen, zu verwalten und zu konfigurieren.

Azure App Service unterstützt jetzt Den Austausch mit der Vorschauversion.

Azure App Service unterstützt jetzt den Austausch mit vorschau auf seinen Bereitstellungsslots. Dies ist eine gute Möglichkeit, die App mit der Produktionskonfiguration zu überprüfen, bevor die App tatsächlich von einem Stagingslot in einen Produktionsslot getauscht wird. Dies würde auch sicherstellen, dass für den Ziel-/Produktionsslot keine Ausfallzeiten auftreten.

Azure App Service Task unterstützt jetzt diesen mehrstufigen Austausch über die folgenden neuen Aktionen:

• Tausch mit Vorschau starten : Initiiert einen Austausch mit einer Vorschau (mehrstufiger Austausch) und wendet die Konfiguration des Zielslots (z. B. des Produktionsslots) auf den Quellslot an.
• Tausch mit Vorschau abschließen: Wenn Sie bereit sind, den ausstehenden Austausch abzuschließen, wählen Sie die Aktion Tausch mit Vorschau abschließen aus.
• Tausch mit Vorschau abbrechen: Um einen ausstehenden Austausch abzubrechen, wählen Sie Austausch mit Vorschau abbrechen aus.

Filter auf Stufenebene für Azure Container Registry- und Docker Hub-Artefakte

Bisher waren Filter für reguläre Ausdrücke für Azure Container Registry und Docker Hub Artefakte nur auf Releasepipelineebene verfügbar. Sie wurden nun auch auf der Bühnenebene hinzugefügt.

Verbesserungen an Genehmigungen in YAML-Pipelines

Wir haben das Konfigurieren von Genehmigungen für Dienstverbindungen und Agentpools aktiviert. Für Genehmigungen folgen wir der Rollentrennung zwischen Infrastrukturbesitzern und Entwicklern. Durch das Konfigurieren von Genehmigungen für Ihre Ressourcen wie Umgebungen, Dienstverbindungen und Agentpools können Sie sicher sein, dass alle Pipelineausführungen, die Ressourcen verwenden, zuerst eine Genehmigung erfordern.

Die Benutzeroberfläche ähnelt der Konfiguration von Genehmigungen für Umgebungen. Wenn eine Genehmigung für eine Ressource aussteht, auf die in einer Phase verwiesen wird, wartet die Ausführung der Pipeline, bis die Pipeline manuell genehmigt wurde.

Unterstützung für Containerstrukturtests in Azure Pipelines

Die Nutzung von Containern in Anwendungen nimmt zu und damit der Bedarf an robusten Tests und Validierungen. Azure Pipelines bietet jetzt Unterstützung für Containerstrukturtests. Dieses Framework bietet eine praktische und leistungsstarke Möglichkeit, den Inhalt und die Struktur Ihrer Container zu überprüfen.

Sie können die Struktur eines Images basierend auf vier Kategorien von Tests überprüfen, die zusammen ausgeführt werden können: Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests. Sie können die Ergebnisse in der Pipeline verwenden, um Go/No Go-Entscheidungen zu treffen. Testdaten sind in der Pipelineausführung mit einer Fehlermeldung verfügbar, mit der Sie Fehler besser beheben können.

Eingeben der Konfigurationsdatei und der Bilddetails

Testdaten und Zusammenfassung

Pipeline-Decorators für Releasepipelines

Pipelinedekortoren ermöglichen das Hinzufügen von Schritten am Anfang und Ende jedes Auftrags. Dies unterscheidet sich vom Hinzufügen von Schritten zu einer einzelnen Definition, da es für alle Pipelines in einer Auflistung gilt.

Wir haben Decorators für Builds und YAML-Pipelines unterstützt, wobei Kunden sie verwenden, um die Schritte in ihren Aufträgen zentral zu steuern. Jetzt erweitern wir die Unterstützung auch auf Releasepipelines. Sie können Erweiterungen erstellen, um Schritte für den neuen Beitragspunkt hinzuzufügen, die allen Agentaufträgen in Releasepipelines hinzugefügt werden.

Bereitstellen von Azure Resource Manager (ARM) auf Abonnement- und Verwaltungsgruppenebene

Bisher haben wir Bereitstellungen nur auf Ressourcengruppenebene unterstützt. Mit diesem Update haben wir unterstützung für die Bereitstellung von ARM-Vorlagen auf Abonnement- und Verwaltungsgruppenebene hinzugefügt. Dies hilft Ihnen, wenn Sie eine Reihe von Ressourcen zusammen bereitstellen, diese jedoch in verschiedenen Ressourcengruppen oder Abonnements platzieren. Beispielsweise wird der virtuelle Sicherungscomputer für Azure Site Recovery in einer separaten Ressourcengruppe und an einem separaten Speicherort bereitgestellt.

CD-Funktionen für Ihre mehrstufigen YAML-Pipelines

Sie können jetzt Artefakte nutzen, die von Ihrer CI-Pipeline veröffentlicht wurden, und Pipeline-Vervollständigungstrigger aktivieren. In mehrstufigen YAML-Pipelines führen pipelines wir als Ressource ein. In Ihrem YAML können Sie jetzt auf eine andere Pipeline verweisen und CD-Trigger aktivieren.

Hier sehen Sie das detaillierte YAML-Schema für pipelines-Ressource.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Darüber hinaus können Sie die von Ihrer Pipelineressource veröffentlichten Artefakte mithilfe der - download Aufgabe herunterladen.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Weitere Informationen finden Sie in der Dokumentation zum Herunterladen von Artefakten.

Orchestrieren der Canary-Bereitstellungsstrategie in der Umgebung für Kubernetes

Einer der wichtigsten Vorteile der Continuous Delivery von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu pushen. Dadurch können Sie schnell auf Änderungen der Geschäftsanforderungen reagieren. Die Umgebung wurde als erstklassiges Konzept eingeführt, das die Orchestrierung von Bereitstellungsstrategien ermöglicht und Releases ohne Ausfallzeiten ermöglicht. Zuvor haben wir die runOnce-Strategie unterstützt, die die Schritte einmal sequenziell ausgeführt hat. Mit der Unterstützung der Canary-Strategie in mehrstufigen Pipelines können Sie das Risiko jetzt reduzieren, indem Sie die Änderung langsam in eine kleine Teilmenge einführen. Wenn Sie mehr Vertrauen in die neue Version gewinnen, können Sie damit beginnen, sie auf mehr Server in Ihrer Infrastruktur bereitzustellen und mehr Benutzer an sie weiterzuleiten.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Die Canary-Strategie für Kuberenetes wird zuerst die Änderungen mit 10 % Pods bereitstellen, gefolgt von 20 %, während die Integrität während postRouteTraffic überwacht wird. Wenn alles gut geht, wird es zu 100% höher geschaltet.

Wir suchen nach frühzeitigem Feedback zur Unterstützung von VM-Ressourcen in Umgebungen und zur Durchführung einer fortlaufenden Bereitstellungsstrategie auf mehreren Computern. Kontaktieren Sie uns , um sich zu registrieren.

Genehmigungsrichtlinien für YAML-Pipelines

In YAML-Pipelines folgen wir einer ressourcenbesitzergesteuerten Genehmigungskonfiguration. Ressourcenbesitzer konfigurieren Genehmigungen für die Ressource und alle Pipelines, die die Ressource verwenden, pausen für Genehmigungen vor Beginn der Phase, in der die Ressource verbraucht wird. Es ist üblich, dass SOX-basierte Anwendungsbesitzer den Anforderer der Bereitstellung daran hindern, eigene Bereitstellungen zu genehmigen.

Sie können jetzt erweiterte Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien zu konfigurieren, z. B. der Anforderer sollte nicht genehmigen, die Genehmigung von einer Teilmenge der Benutzer und das Genehmigungstimeout anfordern.

ACR als erstklassige Pipelineressource

Wenn Sie ein in ACR (Azure Container Registry) veröffentlichtes Containerimage als Teil Ihrer Pipeline nutzen und Ihre Pipeline bei der Veröffentlichung eines neuen Images auslösen müssen, können Sie die ACR-Containerressource verwenden.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Darüber hinaus kann mit vordefinierten Variablen auf ACR-Bildmetadaten zugegriffen werden. Die folgende Liste enthält die verfügbaren ACR-Variablen zum Definieren einer ACR-Containerressource in Ihrer Pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Verbesserungen zum Auswerten der Artefaktüberprüfungsrichtlinie in Pipelines

Wir haben die Überprüfung des Artefakts auswerten erweitert, um das Hinzufügen von Richtlinien aus einer Liste mit sofort einsatzbereiten Richtliniendefinitionen zu erleichtern. Die Richtliniendefinition wird automatisch generiert und der Prüfkonfiguration hinzugefügt, die bei Bedarf aktualisiert werden kann.

Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag

Sie können nun Ausgabevariablen in den Lebenszyklus-Hooks eines Bereitstellungsauftrags definieren und sie in anderen nachgelagerten Schritten und Aufträgen innerhalb derselben Phase nutzen.

Beim Ausführen von Bereitstellungsstrategien können Sie mit der folgenden Syntax auftragsübergreifend auf Ausgabevariablen zugreifen.

• Für die runOnce-Strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Für die Canary-Strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Für rollierende Strategie: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Weitere Informationen zum Festlegen einer Ausgabevariable mit mehreren Aufträgen

Vermeiden eines Rollbacks kritischer Änderungen

In klassischen Releasepipelines ist es üblich, sich für regelmäßige Updates auf geplante Bereitstellungen zu verlassen. Wenn Sie jedoch eine kritische Lösung haben, können Sie eine manuelle Bereitstellung out-of-band starten. Dabei bleiben ältere Releases weiterhin geplant. Dies stellte eine Herausforderung dar, da für die manuelle Bereitstellung ein Rollback ausgeführt wurde, wenn die Bereitstellungen gemäß Zeitplan fortgesetzt wurden. Viele von Ihnen haben dieses Problem gemeldet, und wir haben es jetzt behoben. Mit dem Fix würden alle älteren geplanten Bereitstellungen in der Umgebung abgebrochen, wenn Sie eine Bereitstellung manuell starten. Dies gilt nur, wenn die Warteschlangenoption "Zuletzt bereitstellen und andere abbrechen" ausgewählt ist.

Vereinfachte Ressourcenautorisierung in YAML-Pipelines

Eine Ressource ist alles, was von einer Pipeline außerhalb der Pipeline verwendet wird. Ressourcen müssen vor der Verwendung autorisiert werden. Zuvor war bei der Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline ein Fehler bei der Ressourcenautorisierung aufgetreten. Sie mussten die Ressourcen über die Zusammenfassungsseite der fehlgeschlagenen Ausführung autorisieren. Darüber hinaus ist für die Pipeline ein Fehler aufgetreten, wenn sie eine Variable verwendet hat, die auf eine nicht autorisierte Ressource verweist.

Wir erleichtern nun die Verwaltung von Ressourcenautorisierungen. Anstatt die Ausführung zu verfehlen, wartet die Ausführung zu Beginn der Phase, in der die Ressource verbraucht wird, auf Berechtigungen für die Ressourcen. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource auf der Seite Sicherheit autorisieren.

Artefaktprüfung auswerten

Sie können jetzt einen Satz von Richtlinien definieren und die Richtlinienauswertung als Überprüfung einer Umgebung für Containerimageartefakte hinzufügen. Wenn eine Pipeline ausgeführt wird, wird die Ausführung angehalten, bevor eine Phase gestartet wird, die die Umgebung verwendet. Die angegebene Richtlinie wird anhand der verfügbaren Metadaten für das bereitgestellte Image ausgewertet. Die Überprüfung wird erfolgreich abgeschlossen, wenn die Richtlinie erfolgreich ist, und markiert die Phase als fehlgeschlagen, wenn die Überprüfung fehlschlägt.

Updates zum Bereitstellungstask der ARM-Vorlage

Zuvor haben wir die Dienstverbindungen nicht in der Arm-Vorlagenbereitstellungsaufgabe gefiltert. Dies kann dazu führen, dass die Bereitstellung fehlschlägt, wenn Sie eine Dienstverbindung mit niedrigerem Bereich auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich durchzuführen. Jetzt haben wir die Filterung von Dienstverbindungen hinzugefügt, um Dienstverbindungen mit niedrigerem Umfang basierend auf dem von Ihnen ausgewählten Bereitstellungsbereich herauszufiltern.

ReviewApp in Environment

ReviewApp stellt jeden Pull Request aus Ihrem Git-Repository in einer dynamischen Umgebungsressource bereit. Prüfer können sehen, wie diese Änderungen aussehen und mit anderen abhängigen Diensten arbeiten, bevor sie in den Standard-Branch zusammengeführt und in der Produktion bereitgestellt werden. Dies erleichtert Ihnen das Erstellen und Verwalten von reviewApp-Ressourcen und profitieren von allen Nachverfolgbarkeits- und Diagnosefunktionen der Umgebungsfeatures. Mithilfe der reviewApp Schlüsselwort (keyword) können Sie einen Klon einer Ressource erstellen (dynamisch eine neue Ressource basierend auf einer vorhandenen Ressource in einer Umgebung erstellen) und die neue Ressource der Umgebung hinzufügen.

Im Folgenden finden Sie einen YAML-Beispielausschnitt zur Verwendung von reviewApp unter Umgebungen.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Sammeln automatischer und benutzerdefinierter Metadaten aus der Pipeline

Jetzt können Sie die automatische und benutzerdefinierte Metadatensammlung aus Pipelinetasks aktivieren. Mithilfe von Metadaten können Sie eine Artefaktrichtlinie in einer Umgebung erzwingen, indem Sie die Artefaktprüfung auswerten.

VM-Bereitstellungen mit Umgebungen

Eines der am häufigsten angeforderten Features in Umgebungen waren VM-Bereitstellungen. Mit diesem Update aktivieren wir die Vm-Ressource in Umgebungen. Sie können Bereitstellungen jetzt auf mehreren Computern orchestrieren und fortlaufende Updates mithilfe von YAML-Pipelines durchführen. Sie können den Agent auch direkt auf jedem Ihrer Zielserver installieren und die rollierende Bereitstellung auf diesen Servern vorantreiben. Darüber hinaus können Sie den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.

Eine rollierende Bereitstellung ersetzt Instanzen der vorherigen Version einer Anwendung durch Instanzen der neuen Version der Anwendung auf einer Gruppe von Computern (rolling set) in jeder Iteration.

Beispielsweise werden unter Rollbereitstellung bis zu fünf Ziele in jeder Iteration aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl entspricht der Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, mit Ausnahme der Ziele, für die bereitgestellt wird. Hiermit werden auch die Erfolgs- und Fehlerbedingungen während der Bereitstellung bestimmt.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Hinweis

Mit diesem Update werden alle verfügbaren Artefakte aus der aktuellen Pipeline und aus den zugehörigen Pipelineressourcen nur in deploy lifecycle-hook heruntergeladen. Sie können jedoch den Download auswählen, indem Sie die Aufgabe "Pipelineartefakt herunterladen" angeben. Es gibt einige bekannte Lücken in diesem Feature. Wenn Sie z. B. eine Phase wiederholen, wird die Bereitstellung auf allen VMs erneut ausgeführt, nicht nur auf Zielen mit Fehlern. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.

Zusätzliche Steuerung Ihrer Bereitstellungen

Azure Pipelines unterstützt seit einiger Zeit Bereitstellungen, die mit manuellen Genehmigungen gesteuert werden. Mit den neuesten Verbesserungen haben Sie jetzt zusätzliche Kontrolle über Ihre Bereitstellungen. Zusätzlich zu Genehmigungen können Ressourcenbesitzer jetzt automatisierte checks Hinzufügen, um Sicherheits- und Qualitätsrichtlinien zu überprüfen. Diese Überprüfungen können verwendet werden, um Vorgänge auszulösen und dann zu warten, bis sie abgeschlossen sind. Mithilfe der zusätzlichen Überprüfungen können Sie jetzt Integritätskriterien basierend auf mehreren Quellen definieren und sicher sein, dass alle Bereitstellungen, die auf Ihre Ressourcen abzielen, sicher sind, unabhängig von der YAML-Pipeline, die die Bereitstellung ausführt. Die Auswertung jeder Überprüfung kann basierend auf dem angegebenen Wiederholungsintervall für die Überprüfung regelmäßig wiederholt werden. Die folgenden zusätzlichen Überprüfungen sind jetzt verfügbar:

• Rufen Sie eine beliebige REST-API auf, und führen Sie eine Validierung basierend auf dem Antworttext oder einem Rückruf vom externen Dienst aus.
• Rufen Sie eine Azure-Funktion auf, und führen Sie eine Überprüfung basierend auf der Antwort oder einem Rückruf der Funktion aus.
• Abfragen von Azure Monitor-Regeln für aktive Warnungen
• Sicherstellen, dass die Pipeline eine oder mehrere YAML-Vorlagen erweitert

Genehmigungsbenachrichtigung

Wenn Sie einer Umgebung oder einer Dienstverbindung eine Genehmigung hinzufügen, warten alle mehrstufigen Pipelines, die die Ressource verwenden, automatisch zu Beginn der Phase auf die Genehmigung. Die benannten genehmigenden Personen müssen die Genehmigung abschließen, bevor die Pipeline fortgesetzt werden kann.

Mit diesem Update erhalten die genehmigenden Personen eine E-Mail-Benachrichtigung für die ausstehende Genehmigung. Benutzer und Teambesitzer können benutzerdefinierte Abonnements mithilfe von Benachrichtigungseinstellungen deaktivieren oder konfigurieren.

Konfigurieren von Bereitstellungsstrategien über Azure-Portal

Mit dieser Funktion haben wir es Ihnen erleichtert, Pipelines zu konfigurieren, die die Bereitstellungsstrategie Ihrer Wahl verwenden, z. B . Rolling, Canary oder Blau-Grün. Mithilfe dieser sofort einsatzbereiten Strategien können Sie Updates auf sichere Weise bereitstellen und die damit verbundenen Bereitstellungsrisiken minimieren. Um darauf zuzugreifen, klicken Sie auf die Einstellung "Continuous Delivery" in einem virtuellen Azure-Computer. Im Konfigurationsbereich werden Sie aufgefordert, Details zum Azure DevOps-Projekt auszuwählen, in dem die Pipeline erstellt wird, die Bereitstellungsgruppe, die Buildpipeline, die das bereitzustellende Paket veröffentlicht, und die Bereitstellungsstrategie Ihrer Wahl. Anschließend wird eine voll funktionsfähige Pipeline konfiguriert, die das ausgewählte Paket auf diesem virtuellen Computer bereitstellt.

Weitere Informationen finden Sie in unserer Dokumentation zum Konfigurieren von Bereitstellungsstrategien.

Laufzeitparameter

Laufzeitparameter ermöglichen Ihnen mehr Kontrolle darüber, welche Werte an eine Pipeline übergeben werden können. Im Gegensatz zu Variablen verfügen Laufzeitparameter über Datentypen und werden nicht automatisch zu Umgebungsvariablen. Mit Laufzeitparametern haben Sie folgende Möglichkeiten:

• Unterschiedliche Werte für Skripts und Aufgaben zur Laufzeit bereitstellen
• Parametertypen, zulässige Bereiche und Standardwerte steuern
• Dynamisches Auswählen von Aufträgen und Phasen mit Vorlagenausdruck

Weitere Informationen zu Laufzeitparametern finden Sie in der Dokumentation hier.

Verwenden von erweiterten Schlüsselwort (keyword) in Pipelines

Derzeit können Pipelines in Vorlagen integriert werden, um die Wiederverwendung zu fördern und die Boilerplate zu reduzieren. Die Gesamtstruktur der Pipeline wurde weiterhin durch die YAML-Stammdatei definiert. Mit diesem Update haben wir eine strukturiertere Möglichkeit zur Verwendung von Pipelinevorlagen hinzugefügt. Eine YAML-Stammdatei kann jetzt die Schlüsselwort (keyword)-Erweiterung verwenden, um anzugeben, dass die Standard Pipelinestruktur in einer anderen Datei gefunden werden kann. Dadurch haben Sie die Kontrolle darüber, welche Segmente erweitert oder geändert werden können und welche Segmente behoben werden. Außerdem haben wir Pipelineparameter mit Datentypen erweitert, um die Hooks, die Sie bereitstellen können, deutlich zu machen.

In diesem Beispiel wird veranschaulicht, wie Sie einfache Hooks für den Pipelineautor bereitstellen können. Die Vorlage führt immer einen Build aus, führt optional zusätzliche Schritte aus, die von der Pipeline bereitgestellt werden, und führt dann einen optionalen Testschritt aus.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Steuerungsvariablen, die zur Warteschlangenzeit überschrieben werden können

Zuvor konnten Sie die Benutzeroberfläche oder REST-API verwenden, um die Werte einer beliebigen Variablen vor dem Starten einer neuen Ausführung zu aktualisieren. Während der Autor der Pipeline bestimmte Variablen als _settable at queue time_markieren kann, hat das System dies nicht erzwungen und auch nicht verhindert, dass andere Variablen festgelegt werden. Anders ausgedrückt: Die Einstellung wurde nur verwendet, um beim Starten einer neuen Ausführung zusätzliche Eingaben einzufordern.

Wir haben eine neue Auflistungseinstellung hinzugefügt, die den _settable at queue time_ Parameter erzwingt. Dadurch haben Sie die Kontrolle darüber, welche Variablen beim Starten einer neuen Ausführung geändert werden können. In Zukunft können Sie keine Variable ändern, die vom Autor nicht als _settable at queue time_gekennzeichnet ist.

Hinweis

Diese Einstellung ist in vorhandenen Sammlungen standardmäßig deaktiviert, ist jedoch standardmäßig aktiviert, wenn Sie eine neue Azure DevOps-Sammlung erstellen.

Neue vordefinierte Variablen in der YAML-Pipeline

Variablen sind eine praktische Möglichkeit, wichtige Daten in verschiedene Teile Ihrer Pipeline einzufügen. Mit diesem Update haben wir einem Bereitstellungsauftrag einige vordefinierte Variablen hinzugefügt. Diese Variablen werden automatisch vom System festgelegt, auf den jeweiligen Bereitstellungsauftrag festgelegt und sind schreibgeschützt.

• Environment.Id: Die ID der Umgebung.
• Environment.Name: Der Name der Umgebung, auf die der Bereitstellungsauftrag abzielt.
• Environment.ResourceId: Die ID der Ressource in der Umgebung, auf die der Bereitstellungsauftrag abzielt.
• Environment.ResourceName: Der Name der Ressource in der Umgebung, auf die der Bereitstellungsauftrag abzielt.

Auschecken mehrerer Repositorys

Pipelines basieren häufig auf mehreren Repositorys. Sie können verschiedene Repositorys mit Quelle, Tools, Skripts oder anderen Elementen verwenden, die Sie zum Erstellen Ihres Codes benötigen. Zuvor mussten Sie diese Repositorys als Untermodule oder als manuelle Skripts hinzufügen, um git checkout auszuführen. Jetzt können Sie zusätzlich zu dem Repository, das Sie zum Speichern Ihrer YAML-Pipeline verwenden, andere Repositorys abrufen und auschecken.

Wenn Sie beispielsweise über ein Repository namens MyCode mit einer YAML-Pipeline und einem zweiten Repository namens Tools verfügen, sieht Ihre YAML-Pipeline wie folgt aus:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

Im dritten Schritt werden die beiden Verzeichnisse MyCode und Tools im Verzeichnis sources angezeigt.

Azure Repos Git-Repositorys werden unterstützt. Weitere Informationen finden Sie unter Auschecken mehrerer Repositorys.

Abrufen von Details zur Laufzeit zu mehreren Repositorys

Wenn eine Pipeline ausgeführt wird, fügt Azure Pipelines Informationen zum Repository, Branch und Commit hinzu, die die Ausführung ausgelöst haben. Da YAML-Pipelines nun das Auschecken mehrerer Repositorys unterstützen, können Sie auch das Repository, den Branch und den Commit kennen, die für andere Repositorys ausgecheckt wurden. Diese Daten sind über einen Laufzeitausdruck verfügbar, den Sie nun einer Variablen zuordnen können. Beispiel:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Zulassen von Repositoryverweise auf andere Azure Repos Sammlungen

Wenn Sie zuvor auf Repositorys in einer YAML-Pipeline verwiesen haben, mussten sich alle Azure Repos Repositorys in derselben Sammlung wie die Pipeline befinden. Jetzt können Sie mithilfe einer Dienstverbindung auf Repositorys in anderen Sammlungen verweisen. Beispiel:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection verweist auf eine andere Azure DevOps-Sammlung und verfügt über Anmeldeinformationen, die auf das Repository in einem anderen Projekt zugreifen können. Beide Repositorys self und otherrepowerden am Ende ausgecheckt.

Wichtig

MyServiceConnectionmuss eine Azure Repos-/Team Foundation Server-Dienstverbindung sein, sehen Sie sich die folgende Abbildung an.

Pipelineressourcenmetadaten als vordefinierte Variablen

Wir haben vordefinierte Variablen für YAML-Pipelineressourcen in der Pipeline hinzugefügt. Hier ist die Liste der verfügbaren Pipelineressourcenvariablen.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize and kompose as bake options in KubernetesManifest task

mit kustomize (Teil von Kubernetes sig-cli) können Sie unformatierte, vorlagenfreie YAML-Dateien für mehrere Zwecke anpassen und die ursprüngliche YAML-Datei unberührt lassen. Eine Option für kustomize wurde unter der Bake-Aktion des KubernetesManifest-Tasks hinzugefügt, sodass jeder Ordner, der kustomization.yaml-Dateien enthält, zum Generieren der Manifestdateien verwendet werden kann, die in der Bereitstellungsaktion der KubernetesManifest-Aufgabe verwendet werden.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

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

kompose transformiert eine Docker Compose-Datei in eine Kubernetes-Ressource.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

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

Unterstützung für Clusteradministratoranmeldeinformationen im HelmDeploy-Task

Zuvor hat der HelmDeploy-Task die Clusterbenutzeranmeldeinformationen für Bereitstellungen verwendet. Dies führte zu interaktiven Anmeldeaufforderungen und fehlerhaften Pipelines für einen Azure Active Directory-basierten RBAC-fähigen Cluster. Um dieses Problem zu beheben, haben wir ein Kontrollkästchen hinzugefügt, mit dem Sie anstelle der Anmeldeinformationen eines Clusterbenutzers Anmeldeinformationen für Den Clusteradministrator verwenden können.

Eingabe von Argumenten im Docker Compose-Task

In der Docker Compose-Aufgabe wurde ein neues Feld eingeführt, mit dem Sie Argumente wie --no-cachehinzufügen können. Das Argument wird von der Aufgabe übergeben, wenn Befehle wie build ausgeführt werden.

Verbesserungen von GitHub-Releasetasks

Wir haben mehrere Verbesserungen an der GitHub Release-Aufgabe vorgenommen. Sie können jetzt die Erstellung von Releases mithilfe des Tagmusterfelds besser steuern, indem Sie einen regulären Tagausdruck angeben. Die Freigabe wird nur erstellt, wenn der auslösende Commit mit einer übereinstimmenden Zeichenfolge markiert ist.

Wir haben auch Funktionen zum Anpassen der Erstellung und Formatierung von Changelog hinzugefügt. Im neuen Abschnitt für die Changelogkonfiguration können Sie nun das Release angeben, mit dem das aktuelle Release verglichen werden soll. Der Vergleich mit Release kann das letzte vollständige Release (ohne Vorabversionen), das letzte Nicht-Entwurfs-Release oder ein beliebiges vorheriges Release sein, das dem angegebenen Releasetag entspricht. Darüber hinaus stellt der Task das Changelogtypfeld bereit, um das Changelog zu formatieren. Basierend auf der Auswahl zeigt das Changelog entweder eine Liste von Commits oder eine Liste von Problemen/PRs an, die basierend auf Bezeichnungen kategorisiert sind.

Installationsprogramm für den Richtlinien-Agent öffnen

Der Open Policy-Agent ist eine Open Source allgemeine Richtlinien-Engine, die eine einheitliche, kontextbezogene Richtlinienerzwingung ermöglicht. Wir haben die Installationstask "Open Policy Agent" hinzugefügt. Dies ist besonders nützlich für die In-Pipeline-Richtlinienerzwingung in Bezug auf Infrastructure-as-Code-Anbieter.

Der Open Policy-Agent kann beispielsweise Rego-Richtliniendateien und Terraform-Pläne in der Pipeline auswerten.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Unterstützung für PowerShell-Skripts im Azure CLI-Task

Zuvor konnten Sie Batch- und Bashskripts als Teil einer Azure CLI-Aufgabe ausführen. Mit diesem Update haben wir der Aufgabe Unterstützung für PowerShell- und PowerShell-Kernskripts hinzugefügt.

Service Mesh Interface-basierte Canary-Bereitstellungen im KubernetesManifest-Task

Wenn die Canary-Strategie zuvor im KubernetesManifest-Task angegeben wurde, wurden Mit der Aufgabe Baseline- und Canary-Workloads erstellt, deren Replikate einem Prozentsatz der Replikate entsprachen, die für stabile Workloads verwendet werden. Dies war nicht identisch mit dem Aufteilen des Datenverkehrs auf den gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir der KubernetesManifest-Aufgabe Unterstützung für Service Mesh Interface-basierte Canary-Bereitstellungen hinzugefügt.

Die Abstraktion der Service Mesh-Schnittstelle ermöglicht die Plug-and-Play-Konfiguration mit Service Mesh-Anbietern wie Linkerd und Istio. Nun nimmt die KubernetesManifest-Aufgabe die harte Arbeit, die TrafficSplit-Objekte von SMI den stabilen, Baseline- und Canary-Diensten während des Lebenszyklus der Bereitstellungsstrategie zuzuordnen. Die gewünschte prozentuale Aufteilung des Datenverkehrs zwischen Stable, Baseline und Canary ist genauer, da die prozentuale Datenverkehrsteilung für die Anforderungen in der Dienstgitterebene gesteuert wird.

Im Folgenden wird ein Beispiel für die fortlaufende Ausführung von SMI-basierten Canary-Bereitstellungen gezeigt.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure File Copy Task unterstützt jetzt AzCopy V10

Der Azure-Dateikopiertask kann in einer Build- oder Releasepipeline verwendet werden, um Dateien in Microsoft-Speicherblobs oder virtuelle Computer (VMs) zu kopieren. Die Aufgabe verwendet AzCopy, das Befehlszeilenhilfsprogramm zum schnellen Kopieren von Daten aus und in Azure-Speicherkonten. Mit diesem Update haben wir Unterstützung für AzCopy V10 hinzugefügt, die neueste Version von AzCopy.

Der azcopy copy Befehl unterstützt nur die damit verbundenen Argumente . Aufgrund der Änderung der Syntax von AzCopy sind einige der vorhandenen Funktionen in AzCopy V10 nicht verfügbar. Dazu gehören:

• Angeben des Protokollspeicherorts
• Bereinigen von Protokoll- und Plandateien nach dem Kopieren
• Fortsetzen des Kopierens bei Einem Auftragsfehler

Die zusätzlichen Funktionen, die in dieser Version der Aufgabe unterstützt werden, sind:

• Feldhaltersymbole im Dateinamen/Pfad der Quelle
• Ableiten des Inhaltstyps basierend auf der Dateierweiterung, wenn keine Argumente bereitgestellt werden
• Definieren der Protokoll-Ausführlichkeit für die Protokolldatei durch Übergeben eines Arguments

Verbessern der Pipelinesicherheit durch Einschränken des Umfangs von Zugriffstoken

Jeder Auftrag, der in Azure Pipelines 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, Protokolle hochzuladen, Testergebnisse, Artefakte 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 haben wir die folgenden Verbesserungen hinzugefügt.

• Verhindern des Zugriffs des Tokens auf Ressourcen außerhalb eines Teamprojekts

  Bisher war der Standardbereich aller Pipelines die Teamprojektsammlung. Sie können den Bereich in klassischen Buildpipelines in das Teamprojekt ändern. Für klassische Release- oder YAML-Pipelines hatten Sie diese Kontrolle jedoch nicht. Mit diesem Update führen wir eine Sammlungseinstellung ein, um zu erzwingen, dass jeder Auftrag ein projektbezogenes Token erhält, unabhängig davon, was in der Pipeline konfiguriert ist. Außerdem haben wir die Einstellung auf Projektebene hinzugefügt. Nun ist diese Einstellung für jedes neue Projekt und jede neue Sammlung, die Sie erstellen, automatisch aktiviert.

  Hinweis

  Die Auflistungseinstellung setzt die Projekteinstellung außer Kraft.

  Das Aktivieren dieser Einstellung in vorhandenen Projekten und Sammlungen kann dazu führen, dass bestimmte Pipelines fehlschlagen, wenn Ihre Pipelines mithilfe von Zugriffstoken auf Ressourcen zugreifen, die sich außerhalb des Teamprojekts befinden. Um Pipelinefehler zu minimieren, können Sie dem Project Build-Dienstkonto explizit Zugriff auf die gewünschte Ressource gewähren. Es wird dringend empfohlen, diese Sicherheitseinstellungen zu aktivieren.

• Einschränken des Zugriffs auf Builddienstrepos

  Basierend auf der Verbesserung der Pipelinesicherheit durch Einschränken des Umfangs des Zugriffstokens kann Azure Pipelines jetzt den Repositoryzugriff auf die für eine YAML-basierte Pipeline erforderlichen Repositorys einschränken. Dies bedeutet, dass das Zugriffstoken der Pipelines nur die in der Pipeline verwendeten Repositorys sehen würde. Zuvor war das Zugriffstoken für jedes Azure Repos Repository im Projekt oder möglicherweise für die gesamte Sammlung geeignet.

  Dieses Feature ist standardmäßig für neue Projekte und Sammlungen aktiviert. Für vorhandene Sammlungen müssen Sie sie inden Pipelineeinstellungen> für Sammlungen> aktivieren. Wenn Sie dieses Feature verwenden, müssen alle Repositorys, die für den Build benötigt werden (auch diejenigen, die Sie mithilfe eines Skripts klonen) in die Repositoryressourcen der Pipeline aufgenommen werden.

• Entfernen bestimmter Berechtigungen für das Zugriffstoken

  Standardmäßig gewähren wir eine Reihe von Berechtigungen für das Zugriffstoken. Eine dieser Berechtigungen ist Warteschlangenbuilds. Mit diesem Update haben wir diese Berechtigung für das Zugriffstoken entfernt. Wenn Ihre Pipelines diese Berechtigung benötigen, können Sie sie je nach dem verwendeten Token explizit dem Project Build-Dienstkonto oder dem Project Collection Build Service-Konto gewähren.

Sicherheit auf Projektebene für Dienstverbindungen

Wir haben die Sicherheit auf Hubebene für Dienstverbindungen hinzugefügt. Jetzt können Sie Benutzer hinzufügen/entfernen, Rollen zuweisen und den Zugriff für alle Dienstverbindungen zentral verwalten.

Schrittweises Targeting und Befehlsisolation

Azure Pipelines unterstützt die Ausführung von Aufträgen in Containern oder auf dem Agenthost. Zuvor wurde ein ganzer Auftrag auf eines dieser beiden Ziele festgelegt. Nun können einzelne Schritte (Aufgaben oder Skripts) auf dem von Ihnen ausgewählten Ziel ausgeführt werden. Schritte können auch auf andere Container abzielen, sodass eine Pipeline jeden Schritt in einem speziellen, speziell dafür erstellten Container ausführen kann.

Container können als Isolationsgrenzen fungieren und verhindern, dass Code unerwartete Änderungen auf dem Hostcomputer vornimmt. Die Art und Weise, wie Schritte mit dem Agent kommunizieren und auf Dienste zugreifen , wird durch das Isolieren von Schritten in einem Container nicht beeinflusst. Daher führen wir auch einen Befehlseinschränkungsmodus ein, den Sie mit Schrittzielen verwenden können. Wenn Sie dies aktivieren, werden die Dienste eingeschränkt, die ein Schritt vom Agent anfordern kann. Es ist nicht mehr in der Lage, Protokolle anzufügen, Artefakte und bestimmte andere Vorgänge hochzuladen.

Hier sehen Sie ein umfassendes Beispiel, das die Ausführung von Schritten auf dem Host in einem Auftragscontainer und in einem anderen Container zeigt:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Schreibgeschützte Variablen

Systemvariablen wurden als unveränderlich dokumentiert, in der Praxis könnten sie jedoch von einer Aufgabe überschrieben werden, und nachgelagerte Aufgaben würden den neuen Wert übernehmen. Mit diesem Update erhöhen wir die Sicherheit rund um Pipelinevariablen, um System- und Warteschlangenzeitvariablen schreibgeschützt zu machen. Darüber hinaus können Sie eine YAML-Variable schreibgeschützt machen, indem Sie sie wie folgt markieren.

variables:
- name: myVar
  value: myValue
  readonly: true

Rollenbasierter Zugriff für Dienstverbindungen

Wir haben den rollenbasierten Zugriff für Dienstverbindungen hinzugefügt. Bisher konnte die Sicherheit der Dienstverbindung nur über vordefinierte Azure DevOps-Gruppen wie Endpunktadministratoren und Endpunktersteller verwaltet werden.

Im Rahmen dieser Arbeit haben wir die neuen Rollen Leser, Benutzer, Ersteller und Administrator eingeführt. Sie können diese Rollen über die Seite Dienstverbindungen in Ihrem Projekt festlegen, und diese werden von den einzelnen Verbindungen geerbt. In jeder Dienstverbindung haben Sie die Möglichkeit, die Vererbung zu aktivieren oder zu deaktivieren und die Rollen im Bereich der Dienstverbindung außer Kraft zu setzen.

Weitere Informationen zur Sicherheit von Dienstverbindungen finden Sie hier.

Projektübergreifende Freigabe von Dienstverbindungen

Wir haben die Unterstützung für die projektübergreifende Freigabe von Dienstverbindungen aktiviert. Sie können Ihre Dienstverbindungen jetzt sicher und sicher für Ihre Projekte freigeben.

Weitere Informationen zur Freigabe von Dienstverbindungen finden Sie hier.

Nachverfolgbarkeit für Pipelines und ACR-Ressourcen

Wir stellen die vollständige E2E-Rückverfolgbarkeit sicher, wenn Pipelines und ACR-Containerressourcen in einer Pipeline verwendet werden. Für jede Ressource, die von Ihrer YAML-Pipeline genutzt wird, können Sie zu den Commits, Arbeitselementen und Artefakten zurückverfolgen.

In der Zusammenfassungsansicht der Pipelineausführung sehen Sie Folgendes:

• Die Ressourcenversion, die die Ausführung ausgelöst hat. Nun kann Ihre Pipeline nach Abschluss einer anderen Azure-Pipelineausführung oder beim Pushen eines Containerimages an ACR ausgelöst werden.

  

• Die Commits , die von der Pipeline genutzt werden. Sie finden auch die Aufschlüsselung der Commits nach den einzelnen Ressourcen, die von der Pipeline genutzt werden.

  

• Die Arbeitselemente , die den einzelnen Ressourcen zugeordnet sind, die von der Pipeline genutzt werden.

• Die Artefakte , die für die Ausführung verfügbar sind.

  

In der Bereitstellungsansicht der Umgebung sehen Sie die Commits und Arbeitselemente für jede Ressource, die in der Umgebung bereitgestellt wird.

Unterstützung für große Testanlagen

Mit der Aufgabe "Testergebnisse veröffentlichen" in Azure Pipelines können Sie Testergebnisse veröffentlichen, wenn Tests ausgeführt werden, um eine umfassende Testberichterstattung und Analyseumgebung bereitzustellen. Bisher galt ein Grenzwert von 100 MB für Testanlagen sowohl für Testausführungen als auch für Testergebnisse. Dadurch wurde das Hochladen großer Dateien wie Absturzabbilder oder Videos eingeschränkt. Mit diesem Update haben wir die Unterstützung für umfangreiche Testanlagen hinzugefügt, sodass Sie über alle verfügbaren Daten verfügen, um Fehler bei Tests zu beheben.

In den Protokollen wird möglicherweise der VSTest-Task oder der Task "Testergebnisse veröffentlichen" angezeigt, der den Fehler 403 oder 407 zurückgibt. Wenn Sie selbstgehostete Builds oder Release-Agents hinter einer Firewall verwenden, die ausgehende Anforderungen filtert, müssen Sie einige Konfigurationsänderungen vornehmen, um diese Funktionalität verwenden zu können. ​

Um dieses Problem zu beheben, wird empfohlen, die Firewall für ausgehende Anforderungen auf zu https://*.vstmrblob.vsassets.ioaktualisieren. Informationen zur Problembehandlung finden Sie hier in der Dokumentation. ​

Hinweis

Dies ist nur erforderlich, wenn Sie selbstgehostete Azure Pipelines-Agents verwenden und sich hinter einer Firewall befinden, die ausgehenden Datenverkehr filtert. Wenn Sie von Microsoft gehostete Agents in der Cloud verwenden oder den ausgehenden Netzwerkdatenverkehr nicht filtern, müssen Sie keine Maßnahmen ergreifen.

Anzeigen der richtigen Poolinformationen für jeden Auftrag

Wenn Sie zuvor eine Matrix zum Erweitern von Aufträgen oder einer Variablen zum Identifizieren eines Pools verwendet haben, wurden manchmal falsche Poolinformationen auf den Protokollseiten aufgelöst. Diese Probleme wurden behoben.

CI-Trigger für neue Branches

Es war eine lange ausstehende Anforderung, CI-Builds nicht auszulösen, wenn ein neuer Branch erstellt wird und wenn dieser Branch keine Änderungen enthält. Betrachten Sie die folgenden Beispiele:

• Sie verwenden die Weboberfläche, um einen neuen Branch basierend auf einem vorhandenen Branch zu erstellen. Dies würde sofort einen neuen CI-Build auslösen, wenn Ihr Branchfilter mit dem Namen des neuen Branchs übereinstimmt. Dies ist nicht erwünscht, da der Inhalt des neuen Branchs im Vergleich zum vorhandenen Branch identisch ist.
• Sie verfügen über ein Repository mit zwei Ordnern : App und Dokumentation. Sie haben einen Pfadfilter für CI eingerichtet, der mit "App" übereinstimmt. Mit anderen Worten, Sie möchten keinen neuen Build erstellen, wenn eine Änderung in die Dokumentation gepusht wurde. Sie erstellen einen neuen Branch lokal, nehmen einige Änderungen an der Dokumentation vor und pushen diesen Branch dann an den Server. Wir haben einen neuen CI-Build ausgelöst. Dies ist nicht erwünscht, da Sie explizit aufgefordert haben, nicht nach Änderungen im Ordner "Dokumentation" zu suchen. Aufgrund der Art und Weise, wie wir ein neues Branchereignis behandelt haben, sieht es jedoch so aus, als ob auch am App-Ordner eine Änderung vorgenommen wurde.

Jetzt haben wir eine bessere Möglichkeit, CI für neue Filialen zu behandeln, um diese Probleme anzugehen. Wenn Sie einen neuen Branch veröffentlichen, suchen wir explizit nach neuen Commits in diesem Branch und überprüfen, ob sie mit den Pfadfiltern übereinstimmen.

Aufträge können auf Ausgabevariablen aus früheren Phasen zugreifen.

Ausgabevariablen können jetzt phasenübergreifend in einer YAML-basierten Pipeline verwendet werden. Dadurch können Sie nützliche Informationen wie eine Go/No-Go-Entscheidung oder die ID einer generierten Ausgabe von einer Phase zur nächsten übergeben. Das Ergebnis (status) einer vorherigen Phase und ihrer Aufträge ist ebenfalls verfügbar.

Ausgabevariablen werden weiterhin von Schritten innerhalb von Aufträgen erzeugt. Anstatt auf zu dependencies.jobName.outputs['stepName.variableName']verweisen, verweisen Phasen auf stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Hinweis

Standardmäßig hängt jede Phase in einer Pipeline von der Phase ab, die sich in der YAML-Datei unmittelbar vor ihr befindet. Daher kann jede Phase Ausgabevariablen aus der vorherigen Phase verwenden. Sie können die Abhängigkeitsdiagramm ändern, wodurch auch geändert wird, welche Ausgabevariablen verfügbar sind. Wenn phase 3 für instance eine Variable aus Phase 1 benötigt, muss eine explizite Abhängigkeit von Phase 1 deklariert werden.

Deaktivieren automatischer Agents-Upgrades auf Poolebene

Derzeit aktualisieren Pipelines-Agents bei Bedarf automatisch auf die neueste Version. Dies geschieht in der Regel, wenn ein neues Feature oder eine neue Aufgabe vorhanden ist, für die eine neuere Agent-Version erforderlich ist, um ordnungsgemäß zu funktionieren. Mit diesem Update fügen wir die Möglichkeit hinzu, automatische Upgrades auf Poolebene zu deaktivieren. Wenn in diesem Modus kein Agent der richtigen Version mit dem Pool verbunden ist, schlagen Pipelines mit einer eindeutigen Fehlermeldung fehl, anstatt Agents zur Aktualisierung anzufordern. Dieses Feature ist vor allem für Kunden mit selbstgehosteten Pools und sehr strengen Änderungssteuerungsanforderungen von Interesse. Automatische Updates sind standardmäßig aktiviert, und wir empfehlen den meisten Kunden nicht, sie zu deaktivieren.

Agent-Diagnose

Wir haben Diagnose für viele häufige Agentprobleme hinzugefügt, z. B. viele Netzwerkprobleme und häufige Ursachen für Upgradefehler. Um mit Diagnose zu beginnen, verwenden Sie run.sh --Diagnose oder run.cmd --Diagnose unter Windows.

Diensthaken für YAML-Pipelines

Die Integration von Diensten in YAML-Pipelines ist einfacher geworden. Mithilfe von Diensthakereignissen für YAML-Pipelines können Sie jetzt Aktivitäten in benutzerdefinierten Apps oder Diensten basierend auf dem Fortschritt der Pipelineausführungen steuern. Sie können beispielsweise ein Helpdesk-Ticket erstellen, wenn eine Genehmigung erforderlich ist, einen Überwachungsworkflow initiieren, nachdem eine Phase abgeschlossen ist, oder eine Pushbenachrichtigung an die mobilen Geräte Ihres Teams senden, wenn eine Phase ausfällt.

Das Filtern nach Pipelinenamen und Phasennamen wird für alle Ereignisse unterstützt. Genehmigungsereignisse können auch nach bestimmten Umgebungen gefiltert werden. Auf ähnliche Weise können Zustandsänderungsereignisse nach dem neuen Zustand der Pipelineausführung oder der Phase gefiltert werden.

Optimierung der Integration

Optimizely ist eine leistungsstarke A/B-Test- und Featuremarkierungsplattform für Produktteams. Die Integration von Azure Pipelines mit der Optimizely-Experimentierplattform ermöglicht es Produktteams, schneller zu testen, zu lernen und bereitzustellen und gleichzeitig alle DevOps-Vorteile von Azure Pipelines zu nutzen.

Die Optimizely-Erweiterung für Azure DevOps fügt den Build- und Releasepipelines Experimentier- und Featureflagsrollingschritte hinzu, sodass Sie features kontinuierlich mit Azure Pipelines durchlaufen, rollouten und rollbacken können.

Weitere Informationen zur Azure DevOps Optimizely-Erweiterung finden Sie hier.

Hinzufügen einer GitHub-Version als Artefaktquelle

Jetzt können Sie Ihre GitHub-Releases als Artefaktquelle in Azure DevOps-Releasepipelines verknüpfen. Dadurch können Sie das GitHub-Release als Teil Ihrer Bereitstellungen nutzen.

Wenn Sie in der Definition der Releasepipeline auf Artefakt hinzufügen klicken, finden Sie den neuen GitHub Release-Quelltyp . Sie können die Dienstverbindung und das GitHub-Repository bereitstellen, um das GitHub-Release zu nutzen. Sie können auch eine Standardversion für das GitHub-Release auswählen, um die neueste, bestimmte Tagversion zu nutzen, oder zum Zeitpunkt der Releaseerstellung auswählen. Sobald eine GitHub-Version verknüpft ist, wird sie automatisch heruntergeladen und in Ihren Releaseaufträgen verfügbar gemacht.

Terraform-Integration mit Azure Pipelines

Terraform ist ein Open-Source-Tool zur sicheren und effizienten Entwicklung, Änderung und Versionsverwaltung von Infrastruktur. Terraform codiert APIs in deklarative Konfigurationsdateien, sodass Sie die Infrastruktur mithilfe einer allgemeinen Konfigurationssprache definieren und bereitstellen können. Sie können die Terraform-Erweiterung verwenden, um Ressourcen für alle wichtigen Infrastrukturanbieter zu erstellen: Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP).

Weitere Informationen zur Terraform-Erweiterung finden Sie in der Dokumentation hier.

Integration in Google Analytics

Mit dem Google Analytics-Experimentframework können Sie nahezu jede Änderung oder Variation einer Website oder App testen, um deren Auswirkungen auf ein bestimmtes Ziel zu messen. Beispielsweise können Sie Aktivitäten haben, die Ihre Benutzer abschließen sollen (z. B. einen Kauf tätigen, sich für einen Newsletter registrieren) und/oder Metriken, die Sie verbessern möchten (z. B. Umsatz, Sitzungsdauer, Absprungrate). Mit diesen Aktivitäten können Sie Änderungen identifizieren, die sich auf der Grundlage der direkten Auswirkungen auf die Leistung Ihres Features lohnen.

Die Google Analytics-Experimenterweiterung für Azure DevOps fügt den Build- und Releasepipelines Experimentierschritte hinzu, sodass Sie kontinuierlich durchlaufen, lernen und bereitstellen können, indem Sie die Experimente kontinuierlich verwalten und gleichzeitig alle DevOps-Vorteile von Azure Pipelines nutzen.

Sie können die Erweiterung "Google Analytics-Experimente" aus dem Marketplace herunterladen.

Aktualisierte ServiceNow-Integration in Azure Pipelines

Die Azure Pipelines-App für ServiceNow unterstützt die Integration von Azure Pipelines und ServiceNow Change Management. Mit diesem Update können Sie die New York-Version von ServiceNow integrieren. Die Authentifizierung zwischen den beiden Diensten kann jetzt mithilfe von OAuth und der Standardauthentifizierung erfolgen. Darüber hinaus können Sie jetzt erweiterte Erfolgskriterien konfigurieren, sodass Sie eine beliebige Änderungseigenschaft verwenden können, um das Gateergebnis zu bestimmen.

Create Azure Pipelines über VSCode

Wir haben der Azure Pipelines-Erweiterung für VSCode eine neue Funktionalität hinzugefügt. Jetzt können Sie Azure Pipelines direkt aus VSCode erstellen, ohne die IDE zu verlassen.

Verwaltung und Lösung von Flaky-Fehlern

Wir haben die Flaky-Testverwaltung eingeführt, um den End-to-End-Lebenszyklus mit Erkennung, Berichterstellung und Lösung zu unterstützen. Um es weiter zu verbessern, fügen wir die Verwaltung und Lösung von Flaky-Testfehlern hinzu.

Beim Untersuchen des flockigen Tests können Sie mithilfe der Bug-Aktion einen Fehler erstellen, der dann einem Entwickler zugewiesen werden kann, um die Grundursache des flockigen Tests weiter zu untersuchen. Der Fehlerbericht enthält Informationen zur Pipeline wie Fehlermeldung, Stapelablaufverfolgung und andere Informationen, die dem Test zugeordnet sind.

Wenn ein Fehlerbericht aufgelöst oder geschlossen wird, heben wir die Markierung des Tests automatisch als unproblemaisch auf.

Festlegen eines Fehlers für VSTest-Tasks, wenn eine Mindestanzahl von Tests nicht ausgeführt wird

Der VSTest-Task ermittelt und führt Tests mithilfe von Benutzereingaben (Testdateien, Filterkriterien usw.) sowie einem Testadapter aus, der für das verwendete Testframework spezifisch ist. Änderungen an Benutzereingaben oder am Testadapter können zu Fällen führen, in denen Tests nicht erkannt werden und nur eine Teilmenge der erwarteten Tests ausgeführt wird. Dies kann zu Situationen führen, in denen Pipelines erfolgreich sind, weil Tests übersprungen werden, anstatt dass der Code von ausreichend hoher Qualität ist. Um diese Situation zu vermeiden, haben wir eine neue Option im VSTest-Task hinzugefügt, mit der Sie die Mindestanzahl von Tests angeben können, die ausgeführt werden müssen, damit der Task erfolgreich ist.

VSTest TestResultsDirectory-Option ist auf der Aufgabenoberfläche verfügbar.

Der VSTest-Task speichert Testergebnisse und zugeordnete Dateien im $(Agent.TempDirectory)\TestResults Ordner. Wir haben der Task-Benutzeroberfläche eine Option hinzugefügt, mit der Sie einen anderen Ordner zum Speichern von Testergebnissen konfigurieren können. Jetzt können alle nachfolgenden Aufgaben, die die Dateien an einem bestimmten Speicherort benötigen, diese verwenden.

Markdownunterstützung in automatisierten Testfehlermeldungen

Wir haben Markdownunterstützung für Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie problemlos Fehlermeldungen für Testausführung und Testergebnisse formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu vereinfachen. Die unterstützte Markdownsyntax finden Sie hier.

Verwenden von Pipelinedekoratoren zum automatischen Einfügen von Schritten in einen Bereitstellungsauftrag

Sie können jetzt Pipelinedekortoren zu Bereitstellungsaufträgen hinzufügen. Sie können jeden benutzerdefinierten Schritt (z. B. Sicherheitsrisikoscanner) automatisch in jede Lebenszyklus-Hookausführung jedes Bereitstellungsauftrags einfügen lassen. Da Pipelinedekortoren auf alle Pipelines in einer Sammlung angewendet werden können, kann dies im Rahmen der Erzwingung sicherer Bereitstellungsmethoden genutzt werden.

Darüber hinaus können Bereitstellungsaufträge als Containerauftrag zusammen mit Service-Sidecar ausgeführt werden, wenn definiert.

Test Plans

Seite "Neuer Testplan"

Eine neue Test Plans Page (Test Plans *) ist für alle Azure DevOps-Sammlungen verfügbar. Die neue Seite bietet optimierte Ansichten, mit denen Sie sich auf die aufgabe konzentrieren können : Testplanung, Erstellung oder Ausführung. Es ist auch unübersichtlich und konsistent mit dem rest des Azure DevOps-Angebots.

Helfen Sie mir, die neue Seite zu verstehen

Die neue seite Test Plans umfasst insgesamt 6 Abschnitte, von denen die ersten 4 neu sind, während die Abschnitte Diagramme & Erweiterbarkeit die vorhandene Funktionalität darstellen.

1. Testplanheader: Verwenden Sie diesen, um einen Testplan zu suchen, zu favorisieren, zu bearbeiten, zu kopieren oder zu klonen.
2. Testsammlungsstruktur: Verwenden Sie diese Zum Hinzufügen, Verwalten, Exportieren oder Bestellen von Testsammlungen. Nutzen Sie dies, um auch Konfigurationen zuzuweisen und Benutzerakzeptanztests durchzuführen.
3. Registerkarte definieren: Über diese Registerkarte können Sie Testfälle in einer Testsuite Ihrer Wahl sortieren, hinzufügen und verwalten.
4. Registerkarte Ausführen: Weisen Sie Tests über diese Registerkarte zu, und führen Sie sie aus, oder suchen Sie nach einem Testergebnis, in das ein Drillvorgang ausgeführt werden soll.
5. Registerkarte Diagramm: Verfolgen Sie die Testausführung und status über Diagramme, die auch an Dashboards angeheftet werden können.
6. Erweiterbarkeit: Unterstützt die aktuellen Erweiterbarkeitspunkte innerhalb des Produkts.

Lassen Sie uns eine umfassende Übersicht über diese neuen Abschnitte unten sehen.

1. Testplanheader

Aufgaben

Mit dem Header Testplan können Sie die folgenden Aufgaben ausführen:

• Markieren eines Testplans als Favorit
• Aufheben der Markierung eines bevorzugten Testplans
• Einfaches Navigieren zwischen Ihren bevorzugten Testplänen
• Anzeigen des Iterationspfads des Testplans, der eindeutig angibt, ob der Testplan Aktuell oder Vergangenheit ist
• Zeigen Sie die schnelle Zusammenfassung des Berichts "Teststatus" mit einem Link an, um zum Bericht zu navigieren.
• Navigieren Sie zurück zur Seite All/Mine Test Plans

Kontextmenüoptionen

Das Kontextmenü im Header Testplan bietet die folgenden Optionen:

• Testplan kopieren: Dies ist eine neue Option, mit der Sie den aktuellen Testplan schnell kopieren können. Unten sind weitere Details hierzu angegeben.
• Testplan bearbeiten: Mit dieser Option können Sie das Arbeitselementformular Testplan bearbeiten, um die Arbeitselementfelder zu verwalten.
• Testplaneinstellungen: Mit dieser Option können Sie die Testausführungseinstellungen (zum Zuordnen von Build- oder Freigabepipelines) und die Testergebniseinstellungen konfigurieren.

Kopiertestplan (neue Funktion)

Es wird empfohlen, einen neuen Testplan pro Sprint/Release zu erstellen. Dabei kann im Allgemeinen der Testplan für den vorherigen Zyklus kopiert werden, und mit wenigen Änderungen ist der kopierte Testplan für den neuen Zyklus bereit. Um diesen Prozess zu vereinfachen, haben wir die Funktion "Testplan kopieren" auf der neuen Seite aktiviert. Indem Sie es nutzen, können Sie Testpläne kopieren oder klonen. Die unterstützende REST-API wird hier behandelt, und mit der API können Sie einen Testplan auch projektübergreifend kopieren/klonen.
Weitere Richtlinien für Test Plans Nutzung finden Sie hier.

2. Struktur von Testsammlungen

Aufgaben

Mit dem Test suite-Header können Sie die folgenden Aufgaben ausführen:

• Erweitern/Reduzieren: Mit diesen Symbolleistenoptionen können Sie die Suitehierarchiestruktur erweitern oder reduzieren.
• Testpunkte aus untergeordneten Suites anzeigen: Diese Symbolleistenoption wird nur angezeigt, wenn Sie sich auf der Registerkarte "Ausführen" befinden. Dadurch können Sie alle Testpunkte für die angegebene Suite und ihre untergeordneten Elemente in einer Ansicht anzeigen, um die Verwaltung von Testpunkten zu erleichtern, ohne einzeln zu einzelnen Suiten navigieren zu müssen.
• Suite bestellen: Sie können Suiten per Drag-/Drop verschieben, um die Hierarchie der Suiten neu anzuordnen oder sie innerhalb des Testplans von einer Suitehierarchie in eine andere zu verschieben.

Kontextmenüoptionen

Das Kontextmenü in der Struktur "Testsammlungen" bietet die folgenden Optionen:

• Create neuen Suiten: Sie können 3 verschiedene Arten von Suiten wie folgt erstellen:
  • Verwenden Sie statische Suite oder Ordnersuite, um Ihre Tests zu organisieren.
  • Verwenden Sie die anforderungsbasierte Suite, um eine direkte Verknüpfung mit den Anforderungen/User Storys für eine nahtlose Rückverfolgbarkeit zu erstellen.
  • Verwenden Sie abfragebasiert, um Testfälle dynamisch zu organisieren, die eine Abfragekriterien erfüllen.
• Konfigurationen zuweisen: Sie können Konfigurationen für die Suite zuweisen (Beispiel: Chrome, Firefox, EdgeChromium), die dann für alle vorhandenen Testfälle oder neuen Testfälle gelten, die Sie später dieser Suite hinzufügen.
• Exportieren als PDF/E-Mail: Exportieren Sie die Testplaneigenschaften, Testsammlungseigenschaften sowie Details der Testfälle und Testpunkte entweder als "E-Mail" oder "In PDF drucken".
• Testsammlungs-Arbeitselement öffnen: Mit dieser Option können Sie das Formular test suite work item bearbeiten, um die Arbeitselementfelder zu verwalten.
• Zuweisen von Testern zum Ausführen aller Tests: Diese Option ist sehr nützlich für Benutzerakzeptanztests (User Acceptance Testing, UAT), in denen derselbe Test von mehreren Testern ausgeführt werden muss, die in der Regel zu verschiedenen Abteilungen gehören.
• Umbenennen/Löschen: Mit diesen Optionen können Sie den Suitenamen verwalten oder die Suite und deren Inhalt aus dem Testplan entfernen.

3. Registerkarte definieren

Mithilfe der Registerkarte "Definieren" können Sie Testfälle für eine Testsammlung sortieren, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient hingegen zum Zuweisen und Ausführen von Testpunkten.

Die Registerkarte Definieren und bestimmte Vorgänge sind nur für Benutzer mit der Zugriffsebene Basic + Test Plans oder einer entsprechenden Zugriffsebene verfügbar. Alles andere sollte von einem Benutzer mit der Zugriffsebene "Basic" ausgeführt werden können.

Aufgaben

Auf der Registerkarte Definieren können Sie die folgenden Aufgaben ausführen:

• Neuen Testfall mithilfe des Arbeitselementformulars hinzufügen: Mit dieser Option können Sie mithilfe des Arbeitselementformulars einen neuen Testfall erstellen. Der erstellte Testfall wird automatisch der Suite hinzugefügt.
• Neuen Testfall mit Raster hinzufügen: Mit dieser Option können Sie einen oder mehrere Testfälle mithilfe der Rasteransicht Testfälle erstellen. Die erstellten Testfälle werden automatisch der Suite hinzugefügt.
• Vorhandene Testfälle mithilfe einer Abfrage hinzufügen: Mit dieser Option können Sie der Suite vorhandene Testfälle hinzufügen, indem Sie eine Abfrage angeben.
• Sortieren von Testfällen per Drag/Drop: Sie können Testfälle neu anordnen, indem Sie einen oder mehrere Testfälle innerhalb einer bestimmten Suite ziehen/ablegen. Die Reihenfolge der Testfälle gilt nur für manuelle Testfälle und nicht für automatisierte Tests.
• Verschieben von Testfällen aus einer Suite in eine andere: Mithilfe von Drag/Drop können Sie Testfälle aus einer Testsammlung in eine andere verschieben.
• Raster anzeigen: Sie können den Rastermodus zum Anzeigen/Bearbeiten von Testfällen zusammen mit Testschritten verwenden.
• Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte Definieren im Vollbildmodus anzeigen.
• Filtern: Mithilfe der Filterleiste können Sie die Liste der Testfälle mithilfe der Felder "Testfalltitel", "zugewiesen an" und "status" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.
• Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte Definieren angezeigt werden, indem Sie "Spaltenoptionen" verwenden. Die Liste der spalten, die zur Auswahl verfügbar sind, sind in erster Linie die Felder aus dem Arbeitselementformular für den Testfall.

Kontextmenüoptionen

Das Kontextmenü auf dem Knoten Testfall auf der Registerkarte Definieren bietet die folgenden Optionen:

• Arbeitselementformular für Testfälle öffnen/bearbeiten: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitselementfelder einschließlich Der Testschritte bearbeiten.
• Bearbeiten von Testfällen: Mit dieser Option können Sie Die Arbeitselementfelder des Testfalls in Massenbearbeitung bearbeiten. Sie können diese Option jedoch nicht zum Massenbearbeitungsvorgang von Testschritten verwenden.
• Bearbeiten von Testfällen im Raster: Mit dieser Option können Sie die ausgewählten Testfälle, einschließlich Testschritten, mithilfe der Rasteransicht massenbearbeitungen.
• Konfigurationen zuweisen: Mit dieser Option können Sie die Konfigurationen auf Suiteebene mit Konfigurationen auf Testfallebene überschreiben.
• Entfernen von Testfällen: Mit dieser Option können Sie die Testfälle aus der angegebenen Suite entfernen. Das zugrunde liegende Testfallarbeitselement wird jedoch nicht geändert.
• Create einer Kopie/klon von Testfällen: Mit dieser Option können Sie eine Kopie/einen Klon ausgewählter Testfälle erstellen. Weitere Informationen finden Sie unten.
• Verknüpfte Elemente anzeigen: Mit dieser Option können Sie die verknüpften Elemente für einen bestimmten Testfall anzeigen. Weitere Informationen finden Sie unten.

Kopieren/Klonen von Testfällen (neue Funktion)

In Szenarien, in denen Sie einen Testfall kopieren/klonen möchten, können Sie die Option "Testfall kopieren" verwenden. Sie können das Zielprojekt, den Zieltestplan und die Zieltestsammlung angeben, in der der kopier-/geklonte Testfall erstellt werden soll. Darüber hinaus können Sie auch angeben, ob Sie vorhandene Links/Anlagen einschließen möchten, die in die geklonte Kopie fließen sollen.

Anzeigen verknüpfter Elemente (neue Funktion)

Die Rückverfolgbarkeit zwischen Testartefakten, Anforderungen und Fehlern ist ein wichtiges Wertversprechen des Test Plans Produkts. Mit der Option "Verknüpfte Elemente anzeigen" können Sie alle verknüpften Anforderungen, mit denen dieser Testfall verknüpft ist, alle Testsammlungen/Testpläne, in denen dieser Testfall verwendet wurde, und alle Fehler anzeigen, die im Rahmen der Testausführung gespeichert wurden.

4. Registerkarte "Ausführen"

Mithilfe der Registerkarte "Definieren" können Sie Testfälle für eine Testsammlung sortieren, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient hingegen zum Zuweisen und Ausführen von Testpunkten.

Was ist ein Testpunkt? Testfälle selbst sind nicht ausführbar. Wenn Sie einer Testsammlung einen Testfall hinzufügen, werden Testpunkte generiert. Ein Testpunkt ist eine einzigartige Kombination aus Testfall, Testsammlung, Konfiguration und Tester. Beispiel: Wenn Sie einen Testfall als "Testanmeldungsfunktion" haben und zwei Konfigurationen als Edge und Chrome hinzufügen, ergibt dies 2 Testpunkte. Jetzt können diese Testpunkte ausgeführt werden. Bei der Ausführung werden Testergebnisse generiert. In der Testergebnisansicht (Ausführungsverlauf) können Sie alle Ausführungen eines Testpunkts anzeigen. Die neueste Ausführung für den Testpunkt wird auf der Registerkarte "Ausführen" angezeigt.
Daher sind Testfälle wiederverwendbare Entitäten. Indem Sie sie in einen Testplan oder eine Testsammlung einschließen, werden Testpunkte generiert. Durch die Ausführung von Testpunkten bestimmen Sie die Qualität des zu entwickelnden Produkts oder Dienstes.

Einer der Hauptvorteile der neuen Seite ist für Benutzer, die hauptsächlich Testausführung/Nachverfolgung durchführen (benötigen nur "Basic"-Zugriffsebene), sie sind nicht von der Komplexität der Suite-Verwaltung überfordert (die Registerkarte definieren ist für solche Benutzer ausgeblendet).

Die Registerkarte Definieren und bestimmte Vorgänge sind nur für Benutzer mit der Zugriffsebene Basic + Test Plans oder einer entsprechenden Zugriffsebene verfügbar. Alles andere, einschließlich der Registerkarte "Ausführen", sollte von einem Benutzer mit der Zugriffsebene "Basic" ausgeführt werden können.

Aufgaben

Auf der Registerkarte Ausführen können Sie die folgenden Aufgaben ausführen:

• Massenmarkierung von Testpunkten: Mit dieser Option können Sie das Ergebnis der Testpunkte – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend – schnell markieren, ohne den Testfall über den Testrunner ausführen zu müssen. Das Ergebnis kann für einen oder mehrere Testpunkte auf einmal markiert werden.
• Testpunkte ausführen: Mit dieser Option können Sie die Testfälle ausführen, indem Sie jeden Testschritt einzeln durchlaufen und sie mit einem Testrunner als "bestanden/fehlgeschlagen" markieren. Abhängig von der Anwendung, die Sie testen, können Sie den "Web Runner" zum Testen einer "Webanwendung" oder den "Desktop-Runner" zum Testen von Desktop- und/oder Webanwendungen verwenden. Sie können auch die Option "Ausführen mit Optionen" aufrufen, um einen Build anzugeben, für den die Tests ausgeführt werden sollen.
• Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte Ausführen angezeigt werden, indem Sie "Spaltenoptionen" verwenden. Die Liste der spalten, die zur Auswahl verfügbar sind, sind Testpunkten zugeordnet, z. B. Ausführen von, Zugewiesener Tester, Konfiguration usw.
• Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte "Ausführen" im Vollbildmodus anzeigen.
• Filtern: Mithilfe der Filterleiste können Sie die Liste der Testpunkte mithilfe der Felder "Testfalltitel", "zugewiesen", "Status", "Testergebnis", "Tester" und "Konfiguration" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.

Kontextmenüoptionen

Das Kontextmenü auf dem Knoten Testpunkt auf der Registerkarte Ausführen bietet die folgenden Optionen:

• Testergebnis markieren: Wie oben können Sie das Ergebnis der Testpunkte – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend – schnell markieren.
• Testpunkte ausführen: Wie oben können Sie die Testfälle über einen Testrunner ausführen.
• Test auf aktiv zurücksetzen: Mit dieser Option können Sie das Testergebnis auf aktiv zurücksetzen, wodurch das letzte Ergebnis des Testpunkts ignoriert wird.
• Arbeitselementformular für Testfälle öffnen/bearbeiten: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitselementfelder einschließlich Der Testschritte bearbeiten.
• Tester zuweisen: Mit dieser Option können Sie die Testpunkte Testern für die Testausführung zuweisen.
• Anzeigen des Testergebnisses: Mit dieser Option können Sie die neuesten Testergebnisse anzeigen, einschließlich des Ergebnisses jedes Testschritts, hinzugefügter Kommentare oder gespeicherter Fehler.
• Ausführungsverlauf anzeigen: Mit dieser Option können Sie den gesamten Ausführungsverlauf für den ausgewählten Testpunkt anzeigen. Dadurch wird eine neue Seite geöffnet, auf der Sie die Filter anpassen können, um den Ausführungsverlauf nicht nur des ausgewählten Testpunkts, sondern auch für den gesamten Testfall anzuzeigen.

Test Plans Statusbericht

Mit diesem sofort einsatzbereiten Bericht können Sie die Ausführung und status eines oder mehrerer Test Plans in einem Projekt nachverfolgen. Besuchen Sie Test Plans > Statusbericht*, um mit der Verwendung des Berichts zu beginnen.

Die drei Abschnitte des Berichts umfassen Folgendes:

1. Zusammenfassung: Zeigt eine konsolidierte Ansicht für die ausgewählten Testpläne an.
2. Ergebnistrend: Rendert eine tägliche Momentaufnahme, um Ihnen eine Ausführungs- und status Trendlinie zu bieten. Es kann Daten für 14 Tage (Standard), 30 Tage oder einen benutzerdefinierten Bereich anzeigen.
3. Details: In diesem Abschnitt können Sie einen Drilldown nach jedem Testplan durchführen und wichtige Analysen für jede Testsammlung bereitstellen.

Artifacts

Hinweis

Azure DevOps Server 2020 importiert keine Feeds, die sich während des Datenimports im Papierkorb befinden. Wenn Sie Feeds importieren möchten, die sich im Papierkorb befinden, stellen Sie sie aus dem Papierkorb wieder her, bevor Sie mit dem Datenimport beginnen.

Lizenzausdrücke und eingebettete Lizenzen

Jetzt können Sie die Details der Lizenzinformationen für NuGet-Pakete anzeigen, die in Azure Artifacts gespeichert sind, während Sie Pakete in Visual Studio durchsuchen. Dies gilt für Lizenzen, die mithilfe von Lizenzausdrücken oder eingebetteten Lizenzen dargestellt werden. Nun sehen Sie einen Link zu den Lizenzinformationen auf der Detailseite des Visual Studio-Pakets (roter Pfeil in der abbildung unten).

Wenn Sie auf den Link klicken, gelangen Sie zu einer Webseite, auf der Sie die Details der Lizenz anzeigen können. Diese Benutzeroberfläche ist sowohl für Lizenzausdrücke als auch für eingebettete Lizenzen identisch, sodass Sie Lizenzdetails für Pakete, die in Azure Artifacts gespeichert sind, an einem Ort anzeigen können (für Pakete, die Lizenzinformationen angeben und von Visual Studio unterstützt werden).

Einfache Authentifizierungsaufgaben

Sie können sich jetzt mit beliebten Paket-Managern aus Azure Pipelines mithilfe von leichten Authentifizierungstasks authentifizieren. Dies umfasst NuGet, npm, PIP, Twine und Maven. Zuvor konnten Sie sich bei diesen Paket-Managern mithilfe von Aufgaben authentifizieren, die eine große Menge an Funktionalität bereitstellten, einschließlich der Möglichkeit, Pakete zu veröffentlichen und herunterzuladen. Dies erforderte jedoch die Verwendung dieser Aufgaben für alle Aktivitäten, die mit den Paket-Managern interagierten. Wenn Sie ihre eigenen Skripts zum Ausführen von Aufgaben wie dem Veröffentlichen oder Herunterladen von Paketen ausführen würden, könnten Sie diese nicht in Ihrer Pipeline verwenden. Jetzt können Sie Skripts ihres eigenen Designs in Ihrer YAML-Pipeline verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben durchführen. Beispiel für die Verwendung von npm:

Die Verwendung der Befehle "ci" und "publish" in dieser Abbildung ist willkürlich. Sie können alle von Azure Pipelines YAML unterstützten Befehle verwenden. Dadurch haben Sie die vollständige Kontrolle über den Befehlsaufruf und vereinfachen die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration. Weitere Informationen finden Sie in der Dokumentation zu NuGet-, npm-, PIP-, Twine- und Maven-Authentifizierungstasks.

Verbesserungen bei der Ladezeit der Feedseite

Wir freuen uns, ihnen mitteilen zu können, dass wir die Ladezeit der Feedseite verbessert haben. Im Durchschnitt sind die Ladezeiten der Feedseiten um 10 % zurückgegangen. Die größten Feeds haben die größte Verbesserung gesehen, dass die Ladezeit der 99. Perzentil-Feedseiten (Ladezeiten in den höchsten 99 % aller Feeds) um 75 % gesunken ist.

Öffentliches Freigeben Ihrer Pakete mit öffentlichen Feeds

Sie können Ihre Pakete jetzt in öffentlichen Feeds erstellen und speichern. Pakete, die in öffentlichen Feeds gespeichert sind, sind ohne Authentifizierung im Internet verfügbar, unabhängig davon, ob sie sich in Ihrer Sammlung befinden oder sogar bei einer Azure DevOps-Sammlung angemeldet sind. Erfahren Sie mehr über öffentliche Feeds in unserer Feeds-Dokumentation , oder besuchen Sie unser Tutorial zum öffentlichen Freigeben von Paketen.

Konfigurieren von Upstreams in verschiedenen Sammlungen innerhalb eines AAD-Mandanten

Sie können jetzt einen Feed in einer anderen Sammlung hinzufügen, die Ihrem Azure Active Directory -Mandanten (AAD) zugeordnet ist, als Upstream Quelle zu Ihrem Artefaktfeed. Ihr Feed kann Pakete aus den Feeds finden und verwenden, die als Upstream-Quellen konfiguriert sind, sodass Pakete problemlos für Sammlungen freigegeben werden können, die Ihrem AAD-Mandanten zugeordnet sind. Informationen dazu finden Sie in der Dokumentation.

Verwenden des Python-Anmeldeinformationsanbieters zum Authentifizieren von pip und Twine mit Azure Artifacts-Feeds

Sie können jetzt den Python-Anmeldeinformationsanbieter (artifacts-keyring) installieren und verwenden, um die Authentifizierung automatisch einzurichten, um Python-Pakete in oder aus einem Azure Artifacts-Feed zu veröffentlichen oder zu nutzen. Mit dem Anmeldeinformationsanbieter müssen Sie keine Konfigurationsdateien einrichten (pip.ini/pip.conf/.pypirc). Sie werden einfach durch einen Authentifizierungsfluss in Ihrem Webbrowser weitergeleitet, wenn Sie pip oder Twine zum ersten Mal aufrufen. Weitere Informationen finden Sie in der Dokumentation.

Azure Artifacts-Feeds im Visual Studio-Paket-Manager

Wir zeigen jetzt Paketsymbole, Beschreibungen und Autoren im Visual Studio NuGet-Paket-Manager für Pakete an, die aus Azure Artifacts-Feeds bereitgestellt werden. Zuvor wurden die meisten dieser Metadaten nicht für VS bereitgestellt.

Aktualisierte Benutzeroberfläche "Verbinden mit Feed"

Das Dialogfeld Mit Feed verbinden ist der Einstieg in die Verwendung von Azure Artifacts. Enthält Informationen zum Konfigurieren von Clients und Repositorys zum Pushen und Pullen von Paketen aus Feeds in Azure DevOps. Wir haben das Dialogfeld aktualisiert, um detaillierte Informationen zur Einrichtung hinzuzufügen, und die Tools, für die wir Anweisungen geben, erweitert.

Öffentliche Feeds sind jetzt allgemein verfügbar mit Upstream Support

Die öffentliche Vorschau der öffentlichen Feeds hat große Akzeptanz und Feedback erhalten. In diesem Release haben wir zusätzliche Features auf die allgemeine Verfügbarkeit erweitert. Jetzt können Sie einen öffentlichen Feed als Upstream Quelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl zu und aus privaten als auch projektbezogenen Feeds Upstream können.

Create projektbezogene Feeds aus dem Portal

Als wir öffentliche Feeds veröffentlicht haben, haben wir auch projektbezogene Feeds veröffentlicht. Bisher konnten projektbezogene Feeds über REST-APIs oder durch Erstellen eines öffentlichen Feeds erstellt werden und das Projekt dann privat machen. Jetzt können Sie projektbezogene Feeds direkt im Portal aus jedem Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch in der Feedauswahl sehen, welche Feeds projekt- und welche Sammlungsbereiche sind.

npm-Leistungsverbesserungen

Wir haben Änderungen an unserem Kernentwurf vorgenommen, um die Art und Weise zu verbessern, wie wir npm-Pakete in Azure Artifacts-Feeds speichern und bereitstellen. Dies hat uns geholfen, die Latenz für einige der am höchsten verwendeten APIs für npm bis zu das 10-fache zu reduzieren.

Verbesserungen in Bezug auf die Barrierefreiheit

Wir haben Korrekturen bereitgestellt, um Probleme mit der Barrierefreiheit auf unserer Feedseite zu beheben. Die Fehlerbehebungen umfassen Folgendes:

• Create Feederfahrung
• Globale Feedeinstellungen
• Herstellen einer Verbindung mit der Feedumgebung

Wiki

Umfangreiche Bearbeitung für Codewiki-Seiten

Zuvor wurden Sie beim Bearbeiten einer Codewikiseite zum Azure Repos Hub zur Bearbeitung weitergeleitet. Derzeit ist der Repository-Hub nicht für die Bearbeitung von Markdowns optimiert.

Jetzt können Sie eine Codewikiseite im parallelen Editor innerhalb des Wikis bearbeiten. Auf diese Weise können Sie die Symbolleiste "Rich Markdown" verwenden, um Ihre Inhalte zu erstellen, sodass die Bearbeitungsoberfläche mit der im Projektwiki identisch ist. Sie können weiterhin in Repositorys bearbeiten, indem Sie im Kontextmenü die Option In Repositorys bearbeiten auswählen.

Create und Einbetten von Arbeitselementen auf einer Wikiseite

Während wir Ihr Feedback gehört haben, haben wir gehört, dass Sie Wiki verwenden, um Brainstorming-Dokumente, Planungsdokumente, Ideen zu Features, Spezifikationsdokumenten und Besprechungsprotokollen zu erfassen. Jetzt können Sie problemlos Features und Benutzerberichte direkt aus einem Planungsdokument erstellen, ohne die Wikiseite zu verlassen.

Um ein Arbeitselement zu erstellen, wählen Sie den Text auf der Wikiseite aus, auf der Sie das Arbeitselement einbetten möchten, und wählen Sie Neues Arbeitselement aus. Dadurch sparen Sie Zeit, da Sie das Arbeitselement nicht zuerst erstellen müssen, zu Bearbeiten wechseln und dann nach dem Arbeitselement suchen müssen, um es einzubetten. Außerdem wird der Kontextwechsel reduziert, da Sie den Wikibereich nicht beenden.

Weitere Informationen zum Erstellen und Einbetten eines Arbeitselements aus dem Wiki finden Sie in unserer Dokumentation hier.

Kommentare auf Wikiseiten

Zuvor hatten Sie keine Möglichkeit, mit anderen Wiki-Benutzern innerhalb des Wikis zu interagieren. Dies machte die Zusammenarbeit an Inhalten und das Beantworten von Fragen zu einer Herausforderung, da Unterhaltungen über E-Mail- oder Chatkanäle erfolgen mussten. Mit Kommentaren können Sie jetzt direkt im Wiki mit anderen zusammenarbeiten. Sie können die @mention Benutzerfunktionalität in Kommentaren nutzen, um die Aufmerksamkeit anderer Teammitglieder zu lenken. Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert. Weitere Kommentare finden Sie in unserer Dokumentation.

Ausblenden von Ordnern und Dateien ab "" in der Wikistruktur

Bisher wurden in der Wikistruktur alle Ordner und Dateien angezeigt, die mit einem Punkt (.) in der Wikistruktur beginnen. In Codewiki-Szenarien wurden dadurch Ordner wie .vscode, die ausgeblendet werden sollen, in der Wikistruktur angezeigt. Jetzt bleiben alle Dateien und Ordner, die mit einem Punkt beginnen, in der Wikistruktur ausgeblendet, wodurch unnötige Unordnung verringert wird.

Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert.

Kurze und lesbare Wiki-Seiten-URLs

Sie müssen keine mehrteilige URL mehr verwenden, um Wiki-Seitenlinks zu teilen. Wir nutzen die Seiten-IDs in der URL, um Parameter zu entfernen, wodurch die URL kürzer und leichter zu lesen ist.

Die neue Struktur der URLs sieht wie folgt aus:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Dies ist ein Beispiel für die neue URL für eine Willkommensseite im Azure DevOps-Wiki :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Dies wurde basierend auf diesem Featurevorschlagsticket aus dem Entwicklercommunity priorisiert.

Synchroner Bildlauf zum Bearbeiten von Wikiseiten

Das Bearbeiten von Wikiseiten ist jetzt einfacher mit synchronem Scrollen zwischen dem Bearbeitungs- und dem Vorschaubereich. Beim Scrollen auf der einen Seite wird automatisch die andere Seite scrollen, um die entsprechenden Abschnitte zu zuordnen. Sie können den synchronen Bildlauf mit der Umschalttaste deaktivieren.

Hinweis

Der Zustand der synchronen Scroll-Umschaltfläche wird pro Benutzer und Konto gespeichert.

Seitenbesuche für Wiki-Seiten

Sie können jetzt Einblicke in die Seitenbesuche für Wiki-Seiten erhalten. Mit der REST-API können Sie auf die Seitenbesuchsinformationen der letzten 30 Tage zugreifen. Sie können diese Daten verwenden, um Berichte für Ihre Wiki-Seiten zu erstellen. Darüber hinaus können Sie diese Daten in Ihrer Datenquelle speichern und Dashboards erstellen, um bestimmte Erkenntnisse wie die am häufigsten angezeigten Seiten zu erhalten.

Außerdem wird eine aggregierte Anzahl der Seitenaufrufe für die letzten 30 Tage auf jeder Seite angezeigt.

Hinweis

Ein Seitenbesuch wird als Seitenansicht eines bestimmten Benutzers in einem Intervall von 15 Minuten definiert.

Berichterstellung

Berichte zu Pipelinefehlern und -dauer

Metriken und Erkenntnisse helfen Ihnen, den Durchsatz und die Stabilität Ihrer Pipelines kontinuierlich zu verbessern. Wir haben zwei neue Berichte hinzugefügt, um Ihnen Einblicke in Ihre Pipelines zu geben.

1. Der Pipelinefehlerbericht zeigt die Builddurchlaufrate und den Fehlertrend an. Darüber hinaus wird auch der Fehlertrend der Vorgänge angezeigt, um Erkenntnisse darüber zu liefern, welche Aufgabe in der Pipeline zur maximalen Anzahl von Fehlern beiträgt.

2. Der Bericht zur Pipelinedauer zeigt den Trend der Zeit, die für die Ausführung einer Pipeline gedauert hat. Außerdem wird angezeigt, welche Aufgaben in der Pipeline die meiste Zeit in Anspruch nehmen.

Verbesserung des Widgets "Abfrageergebnisse"

Das Widget für Abfrageergebnisse ist eines unserer beliebtesten Widgets, und das aus gutem Grund. Das Widget zeigt die Ergebnisse einer Abfrage direkt auf Ihrem Dashboard an und ist in vielen Situationen nützlich.

Mit diesem Update haben wir viele lang erwartete Verbesserungen enthalten:

• Sie können jetzt so viele Spalten auswählen, wie Sie im Widget anzeigen möchten. Kein 5-Spalten-Limit mehr!
• Das Widget unterstützt alle Größen von 1x1 bis 10x10.
• Wenn Sie die Größe einer Spalte ändern, wird die Spaltenbreite gespeichert.
• Sie können das Widget in die Vollbildansicht erweitern. Wenn sie erweitert wird, werden alle von der Abfrage zurückgegebenen Spalten angezeigt.

Erweiterte Filterung von Lead- und Zykluszeitwidgets

Die Vor- und Zykluszeit wird von Teams genutzt, um zu ermitteln, wie lange es dauert, bis die Arbeit ihre Entwicklungspipelines durchläuft und letztendlich einen Mehrwert für ihre Kunden bietet.

Bisher unterstützten die Lead- und Zykluszeitwidgets keine erweiterten Filterkriterien, um Fragen zu stellen, z. B.: "Wie lange dauert es mein Team, die Elemente mit höherer Priorität zu schließen?"

Mit diesem Update können Fragen wie diese beantwortet werden, indem Sie die Board-Schwimmlane filtern.

Wir haben auch Arbeitselementfilter eingefügt, um die im Diagramm angezeigten Arbeitselemente einzuschränken.

Inline-Sprint-Burndown mithilfe von Story-Punkten

Ihr Sprint-Burndown kann jetzt nach Storys burndownen. Hier wird Ihr Feedback vom Entwicklercommunity berücksichtigt.

Wählen Sie im Sprint-Hub die Registerkarte Analyse aus. Konfigurieren Sie dann den Bericht wie folgt:

1. Stories backlog auswählen
2. Auswählen des Burndowns für die Summe der Story-Punkte

Ein Sprint Burndown-Widget mit allem, was Sie gefragt haben

Das neue Sprint Burndown-Widget unterstützt das Brennen nach Story Points, Anzahl von Aufgaben oder durch Summieren benutzerdefinierter Felder. Sie können sogar einen Sprint-Burndown für Features oder Epics erstellen. Das Widget zeigt durchschnittlichen Burndown, % abgeschlossen und Bereichsvergrößerung an. Sie können das Team konfigurieren, sodass Sie Sprint-Burndowns für mehrere Teams auf demselben Dashboard anzeigen können. Mit all diesen großartigen Informationen, die angezeigt werden sollen, können Sie die Größe auf dem Dashboard auf bis zu 10 x 10 ändern.

Um es auszuprobieren, können Sie es aus dem Widgetkatalog hinzufügen, oder indem Sie die Konfiguration für das vorhandene Sprint Burndown-Widget bearbeiten und das Kontrollkästchen Neue Version jetzt testen aktivieren.

Hinweis

Das neue Widget verwendet Analytics. Wir haben den Legacy-Sprint-Burndown beibehalten, falls Sie keinen Zugriff auf Analytics haben.

Miniaturansicht des Inline-Sprint-Burndowns

Der Sprint Burndown ist zurück! Vor einigen Sprints haben wir den Kontext-Sprint-Burndown aus den Sprint Burndown- und Taskboard-Headern entfernt. Basierend auf Ihrem Feedback haben wir die Miniaturansicht des Sprint-Burndowns verbessert und wieder eingeführt.

Wenn Sie auf die Miniaturansicht klicken, wird sofort eine größere Version des Diagramms mit der Option angezeigt, den vollständigen Bericht auf der Registerkarte Analyse anzuzeigen. Alle Änderungen, die am vollständigen Bericht vorgenommen werden, werden im Im Header angezeigten Diagramm widergespiegelt. So können Sie es jetzt basierend auf Geschichten, Storypunkten oder der Anzahl der Aufgaben als Burndown konfigurieren, anstatt nur die verbleibende Menge an Arbeit.

Create eines Dashboard ohne Team

Sie können jetzt eine Dashboard erstellen, ohne sie einem Team zuzuordnen. Wählen Sie beim Erstellen eines Dashboard den Projektdashboardtyp aus.

Ein Projektdashboard ähnelt einem Teamdashboard, es ist jedoch nicht einem Team zugeordnet, und Sie können entscheiden, wer das Dashboard bearbeiten/verwalten kann. Genau wie ein Teamdashboard ist es für jeden im Projekt sichtbar.

Alle Azure DevOps-Widgets, die einen Teamkontext erfordern, wurden aktualisiert, damit Sie ein Team in ihrer Konfiguration auswählen können. Sie können diese Widgets zu Project Dashboards hinzufügen und das gewünschte Team auswählen.

Hinweis

Für benutzerdefinierte Widgets oder Drittanbieterwidgets übergibt ein Projektdashboard den Standardkontext des Teams an diese Widgets. Wenn Sie über ein benutzerdefiniertes Widget verfügen, das vom Teamkontext abhängig ist, sollten Sie die Konfiguration aktualisieren, damit Sie ein Team auswählen können.

---

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