Versionshinweise zu Azure DevOps Server 2020

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

In diesem Artikel finden Sie Informationen zur neuesten Version für Azure DevOps Server.

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

Direktes Upgrade auf Azure DevOps Server 2020 wird von Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2010 oder einer früheren Version befindet, müssen Sie vor dem Upgrade auf Azure DevOps Server 2019 einige Zwischenschritte ausführen. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps vor Ort.

---

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

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

Azure DevOps Server 2020 behandelt die Buildaufbewahrung anders, basierend auf Aufbewahrungsrichtlinien auf Pipelineebene. Bestimmte Richtlinienkonfigurationen führen dazu, dass Pipelineausführungen nach dem Upgrade gelöscht werden. Pipelineausführungen, die manuell aufbewahrt oder durch eine Veröffentlichung zurückgehalten wurden, werden nach dem Upgrade nicht gelöscht.

Weitere Informationen dazu, wie Sie sicher von Azure DevOps Server 2019 auf Azure DevOps Server 2020 upgraden können, finden Sie in unserem Blogbeitrag.

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

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

• Erweiterte Liste der zulässigen PowerShell-Aufgaben für Parameterüberprüfung der Shellaufgabenargumenteaktivieren.

Anmerkung

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

Installieren von Patches

Wichtig

Wir haben Updates für den Azure Pipelines-Agent mit Patch 4 veröffentlicht, der am 12. September 2023 veröffentlicht wurde. Wenn Sie die Agentupdates nicht installiert haben, wie in den Versionshinweisen für Patch 4beschrieben, empfehlen wir, 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. Befolgen Sie die Schritte in den -Aufgaben zum Hochladen in die Projektsammlungsdokumentation, um tfx-cli zu installieren und sich anzumelden.

Aktualisieren von Aufgaben mithilfe von TFX

Datei	SHA-256-Hash
Tasks20231103.zip	389BA66EEBC3262FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Pipelineanforderungen

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

• Im klassischen Modus:

  Definieren Sie die Variable auf der Variablenregisterkarte in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Wichtig

Wir haben Updates für den Azure Pipelines-Agent mit Patch 4 veröffentlicht, der am 12. September 2023 veröffentlicht wurde. Wenn Sie die Agentupdates nicht installiert haben, wie in den Versionshinweisen für Patch 4beschrieben, empfehlen wir, 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 Korrekturen für Folgendes enthält.

• Ein Fehler wurde behoben, bei dem die Identität "Analysebesitzer" auf Rechnern mit Patch-Upgrade als "Inaktive Identität" angezeigt wird.

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

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

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

Wichtig

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

Anmerkung

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.

Installieren von Patches

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

Aktualisieren des Azure Pipelines-Agents

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

Anmerkung

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

Konfigurieren von TFX

1. Befolgen Sie die Schritte in den -Uploadaufgaben, um die Projektsammlungsdokumentation zu installieren und sich mit tfx-cli anzumelden.

Aktualisieren von Aufgaben mithilfe von TFX

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

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

Pipelineanforderungen

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

• Im klassischen Modus:

  Definieren Sie die Variable auf dem Variablen-Tab in der Pipeline.

• YAML-Beispiel:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• Es wurde ein Fehler behoben, der das Verteilen von Paketen beim Upgrade von 2018 oder einer früheren Version behinderte.

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 Korrekturen für Folgendes enthält.

• Es wurde ein Fehler behoben, der das Verschieben von Paketen beim Upgrade von 2018 oder früheren Versionen gestört 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 Korrekturen für Folgendes enthält.

• Beheben Sie das Problem mit neu hinzugefügten AD-Identitäten, die nicht in den Identitätsauswahlen des Sicherheitsdialogfelds angezeigt werden.
• Behebung eines Problems mit dem Filter "Angefordert von Gruppenmitglied" in den Web-Hook-Einstellungen.
• Beheben Sie den Fehler bei Gated-Check-In-Builds, wenn die Pipeline-Einstellungen der Organisation den Auftragsautorisierungsbereich für Nicht-Release-Pipelines so eingestellt hatten, dass sie auf das aktuelle Projekt beschränkt sind.

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

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

Anmerkung

Das Datenmigrationstool ist ungefähr drei Wochen nach dieser Version für Azure DevOps Server 2020.0.2 verfügbar. Sie können unsere Liste der derzeit unterstützten Versionen für den Import hiersehen.

Diese Version enthält Korrekturen für Folgendes:

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

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

Azure DevOps Server 2020.0.1 Patch 9 Veröffentlichungsdatum: 26. Januar 2022

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

• E-Mail-Benachrichtigungen wurden nicht gesendet, wenn die @mention-Kontrollfunktion in einem Arbeitselement verwendet wurde.
• Beheben Sie den Fehler TF400813 beim Wechseln von Konten. Dieser Fehler ist beim Upgrade von TFS 2018 auf Azure DevOps Server 2020.0.1 aufgetreten.
• Problem beheben, dass die Zusammenfassungsseite "Projektübersicht" nicht geladen wird.
• Verbesserung der Active Directory-Benutzersynchronisierung.
• Die Sicherheitsanfälligkeit in der Elasticsearch wurde behoben, indem die jndilookup-Klasse aus log4j-Binärdateien entfernt wird.

Installationsschritte

1. Aktualisieren Sie den Server mit Patch 9.
2. Überprüfen Sie den Registrierungswert bei 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 aus, wie in der Infodatei angegeben. Es kann eine Warnung zum Beispiel: Kann keine Verbindung mit dem Remote-Server herstellenzurückgeben. Schließen Sie das Fenster nicht, da das Update erneut ausgeführt wird, bis es abgeschlossen ist.

Anmerkung

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 bei 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", der sich auf C:\Program Files\{TFS Version Folder}\Search\zip befindet, in den Remotedateiordner für "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 Veröffentlichungsdatum: 15. Dezember 2021

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

• Lokalisierungsproblem für benutzerdefinierte Layoutzustände von Arbeitselementen.
• Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
• Problem mit Konsolenprotokollen, die abgeschnitten werden, wenn mehrere identische Links in einer Zeile vorhanden sind.
• Problem mit NOTSAMEAS-Regelauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

Azure DevOps Server 2020.0.1 Patch 7 Veröffentlichungsdatum: 26. Oktober 2021

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

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

Azure DevOps Server 2020.0.1 Patch 6 Veröffentlichungsdatum: 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.
• Behebung eines Problems mit inkonsistenten Testergebnissen.

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.

• Behebung des Fehlers in der Build-Definition-Benutzeroberfläche.
• Der Browserverlauf wurde geändert, um Dateien anstelle des Stamm-Repositorys anzuzeigen.
• Behebung eines Problems mit E-Mail-Zustellungsaufträgen für einige Arbeitsaufgabentypen.

Azure DevOps Server 2020.0.1 Patch 4 Veröffentlichungsdatum: 15. Juni 2021

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

• Behebung eines Problems mit dem Datenimport. Der Datenimport dauerte lange für Kunden mit vielen veralteten Testfällen. 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 Datenimportvorgang 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 Testergebnissedaten 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 3installieren.

Überprüfung der Installation

• Option 1: Ausführen devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe ist die Datei, die über den obigen Link heruntergeladen wird. Die Ausgabe des Befehls gibt entweder an, dass der Patch installiert wurde oder nicht installiert ist.

• Option 2: Überprüfen Sie die Version der folgenden Datei: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 ist standardmäßig auf c:\Program Files\Azure DevOps Server 2020 installiert. 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

Anmerkung

Wenn Sie Über Azure DevOps Server 2020 verfügen, sollten Sie zuerst auf Azure DevOps Server 2020.0.1 aktualisieren. Installieren Sie einmal am 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: Offenlegung von Informationen
• CVE-2021-28459: Rechteerweiterung

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

Allgemeine Patchinstallation

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

Überprüfung der Installation

• Option 1: Ausführen devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe ist die Datei, die über den obigen Link heruntergeladen wird. Die Ausgabe des Befehls gibt entweder an, dass der Patch installiert wurde oder nicht installiert ist.

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

AzureResourceGroupDeploymentV2-Aufgabeninstallation

Anmerkung

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

Installieren

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

2. Laden Sie Node.js 14.15.1 und npm (im Node.js Download enthalten) entsprechend Ihrem 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 Vollzugriff Berechtigungen, und kopieren Sie es. Dieses token für den persönlichen Zugriff wird verwendet, wenn der Befehl tfx login ausgeführt wird.This Personal access token will be used when running the tfx login command.

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 die Aufgabe auf dem 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-Aufgabeninstallation

Anmerkung

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) entsprechend Ihrem Rechner 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 Vollzugriff Berechtigungen, und kopieren Sie es. Dieses token für den persönlichen Zugriff wird verwendet, wenn der Befehl tfx login ausgeführt wird.This Personal access token will be used when running the tfx login command.

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 die Aufgabe auf dem 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 Sie das Problem, das im Feedbackticket der Entwicklercommunity gemeldet wurde| Die Schaltfläche „Neuer Testfall“ funktioniert nicht.
• Schließen Sie Korrekturen ein, die mit Azure DevOps Server 2020 Patch 2veröffentlicht wurden.

Azure DevOps Server 2020 Patch 3 Veröffentlichungsdatum: 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 Feedbackticket der Entwicklercommunity gemeldet wurde| Die Schaltfläche 'Neuer Testfall' funktioniert nicht

Veröffentlichungsdatum von Azure DevOps Server 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 von einer vorhandenen Installation aktualisieren. 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 die folgenden Fehler:

• Beheben Sie ein Upgradeproblem von Azure DevOps Server 2019, bei dem Git-Proxy nach dem Upgrade möglicherweise nicht mehr funktioniert.
• Beheben Sie system.OutOfMemoryException-Ausnahme für Nicht-ENU-Auflistungen vor Team Foundation Server 2017 beim Upgrade auf Azure DevOps Server 2020. Behebt das Problem, das in diesem Feedbackticket der Entwickler-Communitygemeldet wurde.
• Wartungsfehler aufgrund fehlender Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Behebt das Problem, das in diesem Feedbackticket der Entwickler-Communitygemeldet wurde.
• Fehler mit ungültigem Spaltennamen in Analytics beim Upgrade auf Azure DevOps Server 2020 beheben. Behebt das Problem, das in diesem Entwickler-Community-Feedback-Ticket gemeldet wurde.
• Gespeicherte XSS beim Anzeigen von Testfallschritten in Testfallergebnissen.
• Fehler beim Upgradeschritt während der Migration von Ergebnisdaten zu TCM.

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

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

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

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: Spoofing-Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Services

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

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

Anmerkung

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

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

Um eine Reparatur auszuführen, wechseln Sie auf dem Azure DevOps Server-Computer/der VM zu Settings -> Apps & Features, und führen Sie eine Reparatur auf Azure DevOps 2020 Server aus. Nachdem die Reparatur abgeschlossen ist, können Sie den Computer/die VM neu starten.

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

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

Neuveröffentlichung von Azure DevOps Server 2020 RC1: 10. Juli 2020

Wir haben Azure DevOps Server 2020 RC1 erneut veröffentlicht, um den in beschriebenen Fehler dieses Entwickler-Community-Feedbackticketszu 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 angibt, ein unerwarteter Fehler in diesem Bereich der Seite aufgetreten ist. Sie können versuchen, diese Komponente neu zu laden oder die gesamte Seitezu aktualisieren. Mit dieser Version wurde dieses Problem behoben. Weitere Informationen finden Sie im Blogbeitrag.

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

Zusammenfassung der Neuerungen in Azure DevOps Server 2020

Azure DevOps Server 2020 führt viele neue Features ein. Zu den Highlights gehören:

• mehrstufige Pipelines
• Kontinuierliche Bereitstellung in YAML
• Nachverfolgen des Fortschritts der übergeordneten Elemente mithilfe von Rollup on Boards Backlog
• Filter "Übergeordnete Arbeitsaufgabe" zum Task Board hinzufügen und Sprint-Backlog
• Neue Webbenutzeroberfläche für Azure Repos-Zielseiten
• Verwaltung von Repositories-übergreifenden Zweigstellenrichtlinien
• Seite "Neuer Testplan"
• Erweiterte Bearbeitung für Code-Wiki-Seiten
• Pipelinefehler- und -dauerberichte

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

• Allgemeine
• Boards
• Repos
• Rohrleitungen
• Testpläne
• Artefakte
• Wiki
• Berichterstellung

---

Allgemein

Allgemeine Verfügbarkeit der Azure DevOps CLI

Im Februar haben wir die Azure DevOps-Erweiterung für 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 jetzt, ihnen mitzuteilen, dass die Erweiterung allgemein verfügbar ist.

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

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

Jetzt können Sie die profilbasierte Authentifizierung zum Bereitstellen Ihrer Azure WebApps für Windows über das Deployment Center verwenden. Wenn Sie die Berechtigung zur Bereitstellung in einer Azure WebApp für Windows mit dem Veröffentlichungsprofil haben, können Sie die Pipeline mithilfe dieses Profils in den Deployment-Center-Workflows einrichten.

Bretter

Filter "Übergeordnete Arbeitsaufgabe" zur Aufgabentafel und zum Sprint-Backlog hinzufügen

Wir haben sowohl dem Sprintboard als auch dem Sprint-Backlog einen neuen Filter hinzugefügt. Auf diese Weise können Sie Anforderungen auf Backlog-Ebene (erste Spalte links) nach ihrem übergeordneten Element filtern. Im folgenden Screenshot haben wir beispielsweise die Ansicht so gefiltert, dass nur User Stories angezeigt werden, deren übergeordnetes Element "Mein großes Feature" ist.

Verbesserung der Erfahrung mit der Fehlerbehandlung – erforderliche Felder bei Fehlern/Aufgaben

Wenn Sie eine Arbeitsaufgabe von einer Spalte in eine andere verschoben haben, bei der eine Zustandsänderung Feldregeln ausgelöst hat, zeigt die Karte einfach eine rote Fehlermeldung an, die Sie dazu zwingt, die Arbeitsaufgabe zu öffnen, um die Ursache zu verstehen. In Sprint 170 haben wir die Erfahrung verbessert, sodass Sie jetzt auf die rote Fehlermeldung klicken können, um die Details des Fehlers anzuzeigen, ohne die Arbeitsaufgabe selbst öffnen zu müssen.

Arbeitsaufgabe live neu laden

Zuvor, wenn ein Arbeitsgegenstand aktualisiert wurde und ein zweites Teammitglied gleichzeitig Änderungen an demselben Arbeitsgegenstand vornahm, verlor der zweite Benutzer seine Änderungen. Solange Sie nun beide unterschiedliche Felder bearbeiten, werden live Aktualisierungen der Änderungen angezeigt, die an der Arbeitsaufgabe vorgenommen wurden.

Verwalten von Iterations- und Bereichspfaden über die Befehlszeile

Sie können nun Iterations- und Bereichspfade über die Befehlszeile verwalten, indem Sie die Befehle az boards iteration und az boards area verwenden. Sie können beispielsweise 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.

Übergeordnete Arbeitselementspalte als Spaltenoption

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

Ändern des von einem Projekt verwendeten Prozesses

Ihre Tools sollten sich mit Ihrem Team weiterentwickeln. Sie können Ihre Projekte jetzt von jeder vorkonfigurierten Prozessvorlage auf jeden anderen vorkonfigurierten Prozess umstellen. Beispielsweise können Sie Ihr Projekt von Agile zu Scrum oder Basic zu Agile ändern. Sie finden die vollständige schrittweise Dokumentation hier.

Ausblenden von benutzerdefinierten Feldern aus dem Layout

Sie können benutzerdefinierte Felder jetzt beim Anpassen des Prozesses aus dem Formularlayout ausblenden. Das Feld steht weiterhin in Abfragen und REST-APIs zur Verfügung. Dies ist praktisch, um zusätzliche Felder zu verfolgen, wenn Sie in andere Systeme integriert sind.

Erhalten Sie Einblicke in die Gesundheit Ihres Teams mit drei neuen Berichten von Azure Boards.

Sie können nicht beheben, was sie nicht sehen können. Daher möchten Sie den Zustand und die Gesundheit ihrer Arbeitsprozesse genau im Auge behalten. Mit diesen Berichten erleichtern wir Es Ihnen, wichtige Metriken mit minimalem Aufwand in Azure Boards nachzuverfolgen.

Die drei neuen interaktiven Berichte sind: Burndown, Kumulatives Flussdiagramm (CFD) und Velocity. Sie können die Berichte auf der neuen Registerkarte "Analyse" sehen.

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

• Wie viel Arbeit haben wir in diesem Sprint noch übrig? Sind wir auf dem Weg, es abzuschließen?
• Welcher Schritt des Entwicklungsprozesses dauert am längsten? Können wir etwas dagegen tun?
• Basierend auf vorherigen Iterationen, wie viel Arbeit sollten wir für den nächsten Sprint planen?

Anmerkung

Die zuvor in den Kopfzeilen gezeigten Diagramme wurden durch diese erweiterten Berichte ersetzt.

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

• Das Burndowndiagramm befindet sich unter dem Sprints Hub.

  

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

  

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

• Der Sprint Burndown- und die Velocity-Berichte können so festgelegt werden, dass entweder die Anzahl der Arbeitsaufgaben verwendet wird oder die Summe der verbleibenden Arbeit.
• Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne dass sich dies auf die Projekttermine auswirkt. Wenn Ihr Team also in der Regel den ersten Tag jeder Sprint-Planung verbringt, können Sie das Diagramm entsprechend anpassen, um dies widerzuspiegeln.
• Das Burndown-Diagramm zeigt jetzt ein Wasserzeichen, das die Wochenenden markiert.
• Mit dem CFD-Bericht können Sie Boardspalten wie Design entfernen, um den Fluss, über den die Teams Kontrolle haben, besser zu fokussieren.

Hier ist ein Beispiel für den CFD-Bericht, der den Fluss für die letzten 30 Tage des Stories-Backlogs zeigt.

Das Geschwindigkeitsdiagramm kann jetzt für alle Backlog-Ebenen verfolgt werden. Beispielsweise können Sie jetzt Features und Epics hinzufügen, während das vorherige Diagramm nur Anforderungen unterstützte. Hier ist ein Beispiel für einen Geschwindigkeitsbericht für die letzten 6 Iterationen des Features-Backlogs.

Anpassen von Taskboardspalten

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

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

Dieses Feature wurde basierend auf einem Vorschlag aus der Entwicklercommunity priorisiert.

Umschalten, um abgeschlossene untergeordnete Aufgaben im Backlog anzuzeigen oder zu verbergen.

Oft möchten Sie beim Verfeinern des Backlogs nur Elemente sehen, die noch nicht abgeschlossen wurden. Jetzt haben Sie die Möglichkeit, abgeschlossene Teilaufgaben im Backlog ein- oder auszublenden.

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

Die letzten Tags, die beim Markieren einer Arbeitsaufgabe angezeigt werden

Beim Tagging eines Arbeitselements wird die Option "Auto-Vervollständigung" jetzt bis zu fünf Ihrer zuletzt verwendeten Tags anzeigen. Dies erleichtert das Hinzufügen der richtigen Informationen zu Ihren Arbeitsaufgaben.

Schreibgeschützte und erforderliche Regeln für die Gruppenmitgliedschaft

Mithilfe von Arbeitsaufgabenregeln können Sie bestimmte Aktionen für Arbeitsaufgabenfelder festlegen, um ihr Verhalten zu automatisieren. Sie können eine Regel erstellen, um ein Feld abhängig von der Gruppenmitgliedschaft schreibgeschützt oder erforderlich zu machen. Sie können beispielsweise Produktverantwortlichen die Möglichkeit geben, die Priorität Ihrer Features festzulegen, während die Features für alle anderen nur lesbar sind.

Anpassen von Systemauswahlwerten

Sie können jetzt die Werte für jede Systemauswahlliste (mit Ausnahme des Grundfelds) anpassen, z. B. Schweregrad, Aktivität, Priorität usw. Die Auswahllistenanpassungen sind bereichsbezogene Anpassungen, sodass Sie unterschiedliche Werte für dasselbe Feld für jeden Arbeitsaufgabentyp verwalten können.

URL-Parameter für neue Arbeitsaufgabe

Teilen Sie Links zu einer Arbeitsaufgabe im Kontext Ihres Boards oder Backlogs mit unserem neuen URL-Parameter für Arbeitsaufgaben. Sie können nun ein Dialogfeld für Arbeitsaufgaben auf Ihrem Board, in Ihrem Backlog oder Sprint-Erlebnis öffnen, indem Sie den Parameter ?workitem=[ID] an die URL anfügen.

Jeder, mit dem Sie den Link teilen, wird mit demselben Kontext in dieselbe Situation gelangen, den Sie beim Teilen des Links hatten!

Erwähnen von Personen, Arbeitsaufgaben und PRs in Textfeldern

Als wir Ihr Feedback angehört haben, haben wir gehört, dass Sie sich die Möglichkeit wünschten, Personen, Arbeitselemente und PRs im Beschreibungsbereich des Arbeitselements (und andere HTML-Felder) innerhalb des Arbeitselements und nicht nur in Kommentaren zu erwähnen. Manchmal arbeiten Sie mit einer Person an einer Arbeitsaufgabe zusammen oder möchten eine PR in Ihrer Beschreibung ihrer Arbeitsaufgabe hervorheben, haben aber keine Möglichkeit, diese Informationen hinzuzufügen. Jetzt können Sie Personen, Arbeitsaufgaben und PRs in allen langen Textfeldern für die Arbeitsaufgabe erwähnen.

Hier sehen Sie ein Beispiel.

• Wenn Sie Personen erwähnen möchten, geben Sie das @ Zeichen und den Namen der Person ein, die Sie erwähnen möchten. In den Feldern der Arbeitsaufgaben generiert @mentions E-Mail-Benachrichtigungen ähnlich wie bei Kommentaren.
• Wenn Sie Arbeitsaufgaben-Erwähnungen verwenden möchten, geben Sie das # Vorzeichen gefolgt von der Arbeitsaufgaben-ID oder dem Titel ein. #mentions erstellt eine Verknüpfung zwischen den beiden Arbeitsaufgaben.
• Um PR-Erwähnungen zu verwenden, fügen Sie eine und hinzu, gefolgt von Ihrer PR-ID oder Ihrem Namen.

Reaktionen auf Diskussionskommentare

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

Sie können Reaktionen zu einem beliebigen Kommentar hinzufügen, und es gibt zwei Möglichkeiten, Ihre Reaktionen hinzuzufügen – das Smiley-Symbol 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 ein oder zwei. Um Ihre Reaktion zu entfernen, klicken Sie auf die Reaktion am unteren Rand Ihres Kommentars, und es wird entfernt. Unten können Sie die Erfahrung beim Hinzufügen einer Reaktion sowie sehen, wie die Reaktionen in einem Kommentar aussehen.

Azure Boards-Berichte zum Dashboard hinzufügen

Im Sprint 155 Update haben wir aktualisierten Versionen der CFD- und Velocity-Berichteenthalten. Diese Berichte sind auf der Registerkarte "Analyse" von Boards und Backlogs verfügbar. Jetzt können Sie die Berichte direkt an Ihr Dashboard anheften. Um die Berichte anzuheften, zeigen Sie mit der Maus auf den Bericht, wählen Sie das Menü mit den Auslassungspunkten '...' und In das Dashboard kopieren.

Nachverfolgen des Fortschritts der übergeordneten Elemente mithilfe des Rollups auf Boards-Backlog

Rollup-Spalten zeigen Fortschrittsbalken und/oder Summen von numerischen Feldern oder untergeordneten Elementen in einer Hierarchie an. Nachfolgende Elemente beziehen sich auf alle Kind-Elemente innerhalb der Hierarchie. Eine oder mehrere Rollupspalten können einem Produkt- oder Portfolio-Backlog hinzugefügt werden.

Hier zeigen wir zum Beispiel Fortschritt nach Arbeitsaufgaben, das Fortschrittsbalken für übergeordnete Arbeitsaufgaben basierend auf dem Prozentsatz der untergeordneten Elemente anzeigt, die geschlossen wurden. Untergeordnete Elemente für Epics umfassen alle untergeordneten Features und ihre untergeordneten oder großen untergeordneten Arbeitsaufgaben. Untergeordnete Elemente für Features umfassen alle untergeordneten Benutzergeschichten und ihre untergeordneten Arbeitsaufgaben.

Liveupdates für Taskboards

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 F5 nicht mehr drücken, um die neuesten Änderungen anzuzeigen.

Unterstützung für benutzerdefinierte Felder in Rollupspalten

Das Rollup kann jetzt für jedes Feld, einschließlich benutzerdefinierter Felder, ausgeführt werden. Wenn Sie eine Rollupspalte hinzufügen, können Sie weiterhin eine Rollupspalte aus der Schnellliste auswählen. Wenn Sie jedoch ein Rollup für numerische Felder ausführen möchten, die nicht Teil der einsatzbereiten Prozessvorlage sind, können Sie ihre eigenen wie folgt konfigurieren:

1. Klicken Sie im Backlog auf "Spaltenoptionen". Klicken Sie dann im Bereich auf "Rollupspalte hinzufügen" und konfigurieren Sie das benutzerdefinierte Rollup.

   

2. Wählen Sie zwischen Fortschrittsbalken und Summeaus.
3. Wählen Sie einen Arbeitsaufgabentyp oder eine Backlog-Ebene aus (in der Regel werden mehrere Arbeitsaufgabentypen aggregiert).
4. Wählen Sie den Aggregationstyp aus. Anzahl der Arbeitsaufgaben oder Summe. Für Summe müssen Sie das Feld auswählen, das zusammengefasst werden soll.
5. Mit der Schaltfläche "OK" gelangen Sie zurück zum Bereich "Spaltenoptionen", in dem Sie die 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 nach Bedarf hinzu.

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

Wir haben dem geerbten Regelmodul eine neue Regel hinzugefügt, damit Sie Felder in einem Arbeitsaufgabenformular ausblenden können. Diese Regel blendet Felder basierend auf der Benutzergruppenmitgliedschaft aus. Wenn der Benutzer beispielsweise zur Gruppe "Produktbesitzer" gehört, können Sie ein entwicklerspezifisches Feld ausblenden. Weitere Details finden Sie in der Dokumentation hier.

Benachrichtigungseinstellungen für benutzerdefinierte Arbeitsaufgaben

Es ist unglaublich wichtig, auf dem laufenden zu bleiben, was für Sie oder Ihr Team relevant ist. Es hilft Teams, bei Projekten zusammenzuarbeiten und den Überblick zu behalten, und stellt sicher, dass alle relevanten Parteien beteiligt sind. Verschiedene Interessengruppen haben jedoch unterschiedliche Ebenen des Engagements in unterschiedlichen Vorhaben, und wir glauben, dass sich dies in Ihrer Fähigkeit widerspiegeln sollte, den Status eines Arbeitselements zu verfolgen.

Wenn Sie zuvor einer Arbeitsaufgabe folgen und Benachrichtigungen zu änderungen erhalten möchten, erhalten Sie E-Mail-Benachrichtigungen für alle änderungen, die an der Arbeitsaufgabe vorgenommen wurden. Nachdem Wir Ihr Feedback berücksichtigt haben, machen wir ein Arbeitselement flexibler für alle Projektbeteiligten. Nun wird neben der Schaltfläche "Folgen" oben rechts von der Arbeitsaufgabe eine neue Einstellungen-Schaltfläche angezeigt. Dadurch gelangen Sie zu einem Popup, mit dem Sie Die folgenden Optionen konfigurieren können.

In Benachrichtigungseinstellungenkönnen Sie aus drei Benachrichtigungsoptionen auswählen. Zunächst können Sie das Abonnement vollständig kündigen. Zweitens können Sie vollständig abonnieren, dabei erhalten Sie Benachrichtigungen für alle Änderungen der Arbeitsgegenstände. Schließlich können Sie auswählen, dass Sie über einige der wichtigsten und wichtigen Ereignisse zur Änderung von Arbeitsaufgaben benachrichtigt werden. Sie können nur eine oder alle drei Optionen auswählen. Dadurch können Teammitglieder Arbeitsaufgaben auf einer höheren Ebene verfolgen, ohne von jeder einzelnen vorgenommenen Änderung abgelenkt zu werden. Mit diesem Feature beseitigen wir unnötige E-Mails und ermöglichen Es Ihnen, sich auf die wichtigen Aufgaben zu konzentrieren.

Verknüpfen von Arbeitsaufgaben mit Bereitstellungen

Wir freuen uns, die Bereitstellungssteuerung im Arbeitsaufgabenformular freizugeben. Dieses Steuerelement verknüpft Ihre Arbeitselemente mit einer Freigabe. Es ermöglicht Ihnen, einfach nachzuverfolgen, wo Ihr Arbeitselement bereitgestellt wurde. Weitere Informationen finden Sie in der Dokumentation hier.

Importieren von Arbeitsaufgaben aus einer CSV-Datei

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

Hinzufügen eines übergeordneten Felds zu Arbeitsaufgabenkarten

Der übergeordnete Kontext ist jetzt in Ihrem Kanban-Board als neues Feld für Arbeitselementkarten verfügbar. Sie können jetzt das übergeordnete Feld zu Ihren Karten hinzufügen und die Notwendigkeit umgehen, Problemumgehungen wie Tags und Präfixe zu verwenden.

Hinzufügen eines übergeordneten Felds zum Backlog und zu Abfragen

Das übergeordnete Feld ist jetzt verfügbar, wenn Backlogs und Abfrageergebnisse angezeigt werden. Verwenden Sie zum Hinzufügen des übergeordneten Felds die Spaltenoptionen Ansicht.

Repos

Codeabdeckungsmetriken und Zweigrichtlinie für Pullanforderungen

Sie können jetzt Codeabdeckungsmetriken für Änderungen in der Pull-Request-Ansicht sehen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen durch automatisierte Tests angemessen getestet haben. Der Abdeckungsstatus wird 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 Besitzer von Repositorys jetzt Codeabdeckungsrichtlinien festlegen und verhindern, dass große, nicht getestete Änderungen in eine Verzweigung zusammengeführt werden. Gewünschte Abdeckungsschwellenwerte können in einer azurepipelines-coverage.yml Einstellungsdatei festgelegt werden, die im Stammverzeichnis des Repositorys eingecheckt wird, und die Abdeckungsrichtlinie kann mit der vorhandenen Funktion eine Verzweigungsrichtlinie für zusätzliche Dienste konfigurieren in Azure Repos definiert werden.

Filtern von Kommentarbenachrichtigungen aus Pullanforderungen

Kommentare in Pullanforderungen können aufgrund von Benachrichtigungen oft viel Rauschen erzeugen. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie nach Kommentaralter, Kommentator, gelöschtem Kommentar, erwähnten Benutzern, Autor der Pull-Anforderung, Zielzweig und Teilnehmern eines Gesprächsfadens abonnieren. Sie können diese Benachrichtigungsabonnements erstellen, indem Sie auf das Benutzersymbol in der oberen rechten Ecke klicken und zu Benutzereinstellungennavigieren.

Service-Hooks für Pull-Request-Kommentare

Sie können jetzt Dienst-Hooks für Kommentare in einer Pull-Anforderung basierend auf Repository und Zielzweig 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 an ein Repository übertragen werden. Die Dateinamenüberprüfungsrichtlinie blockiert Pushs, die mit dem angegebenen Muster übereinstimmen.

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

Sie können nun Arbeitsaufgaben mit Commits, die an der Standardverzweigung vorgenommen wurden, mithilfe von Schlüsselwörtern wie behebt, korrigiertoder behobenauflösen. Sie können zum Beispiel in Ihrer Commit-Nachricht schreiben: "Diese Änderung behebt #476" und die Arbeitsaufgabe #476 wird abgeschlossen sein, wenn der Commit gepusht oder in den Standard-Branch integriert wird. Weitere Details finden Sie in der Dokumentation hier.

Granularität für automatische Prüfer

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

Verwenden der dienstkontobasierten Authentifizierung zum Herstellen einer Verbindung mit AKS

Beim Konfigurieren von Azure-Pipelines aus dem AKS Deployment Center haben wir zuvor eine Azure Resource Manager-Verbindung verwendet. Diese Verbindung hatte Zugriff auf den gesamten Cluster und nicht nur 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 sie nur Zugriff auf den Namespace hat, der der Pipeline zugeordnet ist.

Vorschau von Markdown-Dateien in Pullanforderung parallele Diffs

Sie können nun eine Vorschau anzeigen, wie eine Markdowndatei aussehen wird, indem Sie die neue Schaltfläche Vorschau verwenden. Darüber hinaus können Sie den vollständigen Inhalt einer Datei aus dem Seitenansicht-Diff einsehen, indem Sie die Schaltfläche Ansicht auswählen.

Ablauf der Buildrichtlinie für manuelle Builds

Regeln setzen die Standards für Codequalität und Änderungsmanagement in Ihrem Team durch. Zuvor konnten Sie Ablaufrichtlinien für automatisierte Builds festlegen. Jetzt können Sie Ablaufrichtlinien für Builds auch auf Ihre manuell erstellten 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 an ein Repository gesendet werden, für das die E-Mail des Commitautors nicht mit dem bereitgestellten Muster übereinstimmt.

Dieses Feature wurde basierend auf einem Vorschlag der Developer Community priorisiert, um eine ähnliche Erfahrung zu erzielen. Wir werden das Ticket weiterhin offen halten und die Benutzer ermutigen, uns mitzuteilen, welche anderen Arten von Pushrichtlinien Sie sehen möchten.

Markieren von Dateien als überprüft in einer Pullanforderung

Manchmal müssen Sie Pullanforderungen ü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 einer Pullanforderung als überprüft markieren.

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

Anmerkung

Dieses Feature soll ihren Fortschritt nur nachverfolgen, wenn Sie eine Pull-Anforderung überprüfen. Es stellt keine Abstimmung über Pull-Anfragen dar, sodass diese Markierungen nur für den Prüfer sichtbar sind.

Dieses Feature wurde basierend auf einem Vorschlag der Developer Communitypriorisiert.

Neue Webbenutzeroberfläche für Azure Repos-Zielseiten

Sie können jetzt unsere neuen modernen, schnellen und mobilen Startseiten in Azure Repos ausprobieren. Diese Seiten sind als New Repos Landing Pagesverfügbar. Zielseiten umfassen alle Seiten, mit Ausnahme der Details von Pull-Requests, Commit-Details und dem Zweigvergleich.

Web

Mobil

Repository-übergreifende Zweigrichtlinienverwaltung

Verzweigungsrichtlinien sind eines der leistungsstarken Features von Azure Repos, die Ihnen dabei helfen, wichtige Zweigstellen zu schützen. 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 den Standard-Branch in allen Repositorys ihres Projekts festlegen. Beispielsweise könnte ein Administrator mindestens zwei Prüfer für alle Pull-Anfragen verlangen, die in jedem Haupt-Branch in jedem Repository in ihrem Projekt vorhanden sind. Sie finden das Feature "Verzweigungsschutz hinzufügen" in den Einstellungen für "Projekt neu erstellen".

Neue Webplattform-Konvertierungs-Zielseiten

Wir haben die Benutzeroberfläche der Repos-Zielseiten aktualisiert, um sie modern, schnell und mobil zu gestalten. Hier sind zwei Beispiele für die Seiten, die aktualisiert wurden, wir werden auch weiterhin andere Seiten in zukünftigen Updates aktualisieren.

Weberfahrung:

Mobile Erfahrung:

Unterstützung für Kotlin-Sprache

Wir freuen uns, ihnen mitzuteilen, dass wir jetzt Kotlin-Sprachheraushebungen im Datei-Editor unterstützen. Das Hervorheben verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen, schnell nach Fehlern zu suchen. Wir haben dieses Feature basierend auf einem Vorschlag der Developer Communitypriorisiert.

Benutzerdefiniertes Benachrichtigungsabonnement für Entwürfe von Pull Requests

Um die Anzahl der E-Mail-Benachrichtigungen von Pullanforderungen zu verringern, können Sie jetzt ein benutzerdefiniertes Benachrichtigungsabonnement für Pullanforderungen erstellen oder aktualisieren, die in Entwurfszustanderstellt oder aktualisiert werden. Sie können E-Mails speziell für Pull-Entwürfe abrufen oder E-Mails aus Pull-Entwürfen herausfiltern, damit Ihr Team nicht benachrichtigt wird, bevor die Pullanforderung überprüft werden kann.

Verbesserte PR-Umsetzbarkeit

Wenn Sie viele Pullanforderungen zum Überprüfen haben, kann es schwierig sein, zu verstehen, wo Sie zuerst Maßnahmen ergreifen sollten. Um die Handlungsfähigkeit von Pull-Anfragen zu verbessern, können Sie jetzt auf der Seite mit der Pull-Anforderungsliste mehrere benutzerdefinierte Abfragen erstellen, mit mehreren neuen Optionen zum Filtern, wie zum Beispiel nach Entwurfsstatus. Diese Abfragen erstellen separate und einklappbare Abschnitte auf Ihrer Pull-Request-Seite, zusätzlich zu "Erstellt von mir" und "Mir zugewiesen". Sie können auch ablehnen, eine Pullanfrage zu überprüfen, zu der Sie über das Menü "Abstimmung" oder das Kontextmenü auf der Seite "Pullanforderungsliste" hinzugefügt wurden. In den benutzerdefinierten Abschnitten werden jetzt separate Registerkarten für Pull-Requests angezeigt, die Sie überprüft haben oder deren Überprüfung Sie abgelehnt haben. Diese benutzerdefinierten Abfragen arbeiten über mehrere Repositories hinweg auf der Registerkarte "Meine Pull-Requests" der Startseite der Sammlung. Wenn Sie zu einem Pull-Request zurückkehren möchten, können Sie ihn kennzeichnen, und er wird oben in Ihrer Liste angezeigt. Schließlich werden Pull-Requests, die auf Auto-Complete festgelegt wurden, mit einem Badge gekennzeichnet, das in der Liste "Auto-Complete" lautet.

Rohrleitungen

Mehrstufige Pipelines

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Pipelines zu verwalten. Diese Updates modernisieren die Pipelines und stellen Konsistenz mit der Ausrichtung von Azure DevOps her. Darüber hinaus bringen diese Updates klassische Buildpipelinen und mehrstufige YAML-Pipelines zu einer einzigen Oberfläche zusammen. Es ist mobilfreundlich und bietet verschiedene Verbesserungen, wie Sie Ihre Pipelines verwalten. Sie können näher auf Pipelinedetails, Ausführungsdetails, Pipelineanalysen, Auftragsdetails, Protokolle und mehr eingehen und diese anzeigen.

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

• Anzeigen und Verwalten mehrerer Phasen
• Genehmigung von Pipeline-Durchläufen.
• Scrollen Sie bis ganz zurück in den Protokollen, während eine Pipeline noch in Bearbeitung ist.
• Gesundheit pro Verzweigung einer Pipeline.

Kontinuierliche Bereitstellung in YAML

Wir freuen uns, Azure Pipelines YAML CD-Features bereitzustellen. Wir bieten jetzt eine einheitliche YAML-Erfahrung, damit Sie jede Ihrer Pipelines so konfigurieren können, dass CI, CD oder CI und CD zusammen durchgeführt werden. YaML-CD-Features bieten mehrere neue erweiterte Features, die für alle Sammlungen mit mehrstufigen YAML-Pipelines verfügbar sind. Zu den Highlights gehören:

• mehrstufige YAML-Pipelines (für CI und CD)
• Genehmigungen und Überprüfungen von Ressourcen
• Umgebungen und Bereitstellungsstrategien
• Kubernetes und virtuellen Computer Ressourcen in der Umgebung
• Überprüfen von Apps für die Zusammenarbeit
• Aktualisierte UX für Dienstverbindungen
• Ressourcen in YAML-Pipelines

Wenn Sie mit dem Erstellen beginnen möchten, schauen Sie sich die Dokumentation oder Blog- zum Erstellen von mehrstufigen CI/CD-Pipelines an.

Verwalten von Pipelinevariablen im YAML-Editor

Wir haben die Oberflä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 Versionen direkt über den Veröffentlichungshub

Die Bearbeitung ausstehender Genehmigungen wurde vereinfacht. Zuvor war es möglich, eine Freigabe von der Detailseite der Freigabe zu genehmigen. Sie können jetzt Versionen direkt über den Veröffentlichungshub genehmigen.

Verbesserungen bei den ersten Schritten mit Pipelines

Ein häufig geäußerter Wunsch beim Startassistenten war die Möglichkeit, die generierte Datei umzubenennen. Derzeit wird sie als azure-pipelines.yml im Stammverzeichnis Ihres Repositorys eingecheckt. Sie können dies jetzt vor dem Speichern der Pipeline auf einen anderen Dateinamen oder Speicherort aktualisieren.

Schließlich werden wir mehr Kontrolle haben, wenn Sie die azure-pipelines.yml Datei in einen anderen Branch einchecken, da Sie die Erstellung eines Pull Requests von diesem Branch überspringen können.

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

Wir haben eine Vorschau hinzugefügt, aber führen den Modus für YAML-Pipelines nicht aus. Jetzt können Sie mit einer YAML-Pipeline experimentieren, ohne einen Commit in einem Repository auszuführen oder sie auszuführen. Angesichts einer vorhandenen Pipeline und einer optionalen neuen YAML-Nutzlast gibt Ihnen diese neue API die vollständige YAML-Pipeline zurück. In zukünftigen Updates wird diese API in einem neuen Editor-Feature verwendet.

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

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

Die Antwort enthält das gerenderte YAML.

Cron-Zeitpläne in YAML

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

1. Konfiguration als Code: Sie können die Zeitpläne zusammen mit Ihrer Pipeline im Code nachverfolgen.
2. Ausdrucksstärker: Sie haben mehr Ausdruckskraft beim Definieren von Zeitplänen als es mit der Benutzeroberfläche möglich war. Beispielsweise ist es einfacher, einen einzelnen Zeitplan anzugeben, der jede Stunde einen Lauf 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. Die geplante Ausführung im Menü "Pipeline ausführen" gibt Ihnen eine Vorschau der bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Fehler mit Ihren Cron-Zeitplänen zu diagnostizieren.

Aktualisierungen der Benutzeroberfläche für 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. Die neue Benutzeroberfläche für Dienstverbindungen wurde in diesem Jahr als Vorschaufeature eingeführt. Vielen Dank an alle, die die neue Erfahrung ausprobiert haben und uns ihr wertvolles Feedback gegeben haben.

Zusammen mit 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 standardmäßig mit diesem Update aktiviert. Sie haben weiterhin die Möglichkeit, von der Vorschau abzumelden.

Anmerkung

Wir planen, projektübergreifende Freigabe von Dienstverbindungen als neue Funktion einzuführen. Weitere Details zu Ihrer Erfahrung mit dem Freigeben und zu den Sicherheitsrollen finden Sie hier.

Überspringen von Phasen in einer YAML-Pipeline

Wenn Sie eine manuelle Ausführung starten, möchten Sie vielleicht manchmal einige Phasen in Ihrer Pipeline überspringen. Wenn Sie beispielsweise nicht für die Produktion bereitstellen möchten oder die Bereitstellung in einigen Umgebungen in der Produktion überspringen möchten. Sie können dies jetzt mit Ihren YAML-Pipelines tun.

Der Bereich für die aktualisierte Ausführungspipeline enthält eine Liste der Phasen aus der YAML-Datei, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Beim Überspringen von Stadien müssen Sie Vorsicht walten lassen. Wenn ihre erste Phase beispielsweise bestimmte Artefakte erzeugt, die für nachfolgende Phasen erforderlich sind, sollten Sie die erste Phase nicht überspringen. Im Ausführungsbereich wird eine allgemeine Warnung angezeigt, wenn Sie Phasen überspringen, die über nachgeschaltete Abhängigkeiten verfügen. Es bleibt Ihnen überlassen, ob diese Abhängigkeiten echte Artefaktabhängigkeiten sind oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.

Das Überspringen einer Stufe entspricht dem Neuverwirren der Abhängigkeiten zwischen Phasen. Alle unmittelbaren nachgelagerten Abhängigkeiten der übersprungenen Stufe werden abhängig gemacht vom übergeordneten Element der übersprungenen Stufe. Wenn die Ausführung fehlschlägt und Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, wird auch dieser Versuch das gleiche Überspringverhalten aufweisen. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.

Neue Benutzeroberfläche für Dienstverbindungen als Standarderfahrung

Es gibt eine neue Dienstverbindungs-UI. Diese neue Benutzeroberfläche basiert auf modernen Designstandards und bietet verschiedene wichtige Features zur Unterstützung von mehrstufigen YAML-CD-Pipelines wie Genehmigungen, Autorisierungen und projektübergreifender Freigabe.

Erfahren Sie mehr über Dienstverbindungen hier.

Pipelineressourcenversionsauswahl im Dialog "Ausführung erstellen"

Wir haben die Möglichkeit hinzugefügt, im Dialog „Ausführung erstellen“ Pipelineressourcenversionen manuell auszuwählen. Wenn Sie eine Pipeline als Ressource in einer anderen Pipeline nutzen, können Sie jetzt die Version dieser Pipeline beim Erstellen einer Ausführung auswählen.

az CLI-Verbesserungen für Azure-Pipelines

Pipelinevariablengruppen- und Variablenverwaltungsbefehle

Es kann schwierig sein, YAML-basierte Pipelines von einem Projekt zu einem anderen zu portieren, da Sie die Pipelinevariablen und Variablengruppen manuell einrichten müssen. Mit den Verwaltungsbefehlen für die Pipelinevariablen , die Variablen sowie die Variablengruppe können Sie nun das Einrichten und Verwalten von Pipeline-Variablen und Variablen-Gruppen skripten, die wiederum versionsgesteuert werden können. Dadurch können Sie die Anweisungen zum Verschieben und Einrichten von Pipelines problemlos von einem Projekt zu einem anderen freigeben.

Pipeline für einen PR-Branch ausführen

Beim Erstellen einer PR kann es schwierig sein zu überprüfen, ob die Änderungen die Pipeline für den Zielzweig unterbrechen könnten. Mit der Möglichkeit, eine Pipelineausführung auszulösen oder einen Build für eine PR-Verzweigung in die Warteschlange zu stellen, können Sie die Änderungen jetzt überprüfen und visualisieren, indem Sie sie für die Zielpipeline ausführen. Weitere Informationen finden Sie in der Befehlsdokumentation zu den Befehlen az pipelines run und az pipelines build queue.

Erste Pipelineausführung überspringen

Beim Erstellen von Pipelines möchten Sie manchmal eine YAML-Datei erstellen und übernehmen und die Pipelineausführung nicht auslösen, da dies zu einer fehlerhaften Ausführung aufgrund einer Vielzahl von Gründen führen kann – Infrastruktur ist nicht bereit oder muss Variable/Variable-Gruppen erstellen und aktualisieren usw. Mit 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 az pipeline create command documentation.

Verbesserungen des Dienstendpunktbefehls

Dienstendpunkt-CLI-Befehle unterstützen ausschließlich das Einrichten und Verwalten von Azure RM- und GitHub-Dienstendpunkten. Mit dieser Version können Sie jedoch mit Dienstendpunktbefehlen einen beliebigen Dienstendpunkt erstellen, indem Sie die Konfiguration über 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 Typen bieten. Weitere Informationen finden Sie in der Befehlsdokumentation.

Bereitstellungsaufträge

Ein Bereitstellungsauftrag ist ein spezieller Typ von Auftrag, der verwendet wird, um Ihre App in einer Umgebung bereitzustellen. Mit diesem Update haben wir Unterstützung für Schrittverweise in einem Bereitstellungsauftrag hinzugefügt. Sie können z. B. eine Reihe von Schritten in einer Datei definieren und in einem Bereitstellungsauftrag darauf verweisen.

Wir haben auch den Support für zusätzliche Eigenschaften des Bereitstellungs-Jobs hinzugefügt. Hier sind beispielsweise einige Eigenschaften eines Bereitstellungsauftrags, den Sie jetzt festlegen können,

• timeoutInMinutes – Wie lange der Auftrag ausgeführt werden soll, bevor er automatisch storniert wird.
• cancelTimeoutInMinutes – wie viel Zeit den Vorgängen „immer ausführen, auch wenn abgebrochen“ gegeben wird, bevor sie beendet werden.
• Bedingung – Auftrag bedingt ausführen
• Variablen : Hartcodierte Werte können direkt hinzugefügt werden, oder Variablengruppen, Variablengruppe, die von einem Azure Key Vault- unterstützt wird, können referenziert werden, oder Sie können auf eine Reihe von Variablen verweisen, die in einer Dateidefiniert sind.
• continueOnError – wenn zukünftige Aufträge auch dann ausgeführt werden sollen, wenn dieser Bereitstellungsauftrag fehlschlägt; Standardwert ist "false"

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

Anzeigen von Informationen zu den zugehörigen CD-Pipelines in CI-Pipelines

Wir haben Unterstützung für die Details der CD-YAML-Pipelines hinzugefügt, in denen die CI-Pipelines als Pipeline-Ressourcen bezeichnet werden. In der Ansicht "CI-Pipelineausführung" wird nun eine neue Registerkarte "Zugeordnete Pipelines" angezeigt, auf der Sie alle Pipelineläufe finden können, die Ihre Pipeline und Artefakte davon verbrauchen.

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

Wir haben kürzlich einen neuen Ressourcentyp namens Pakete eingeführt, der Unterstützung für die Nutzung NuGet- und npm--Pakete von GitHub als Ressource in YAML-Pipelines hinzufügt. Als Teil dieser Ressource können Sie nun den Pakettyp (NuGet oder npm) angeben, den Sie von GitHub nutzen möchten. Sie können auch automatisierte Pipelinetrigger bei der Veröffentlichung einer neuen Paketversion aktivieren. Heute ist der Support nur für die Nutzung von Paketen von GitHub verfügbar, aber in Zukunft planen wir, die Unterstützung für die Nutzung von Paketen aus anderen Paketrepositorys wie NuGet-, npm, AzureArtifacts und vielem mehr zu erweitern. Ausführliche 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

Anmerkung

GitHub-Pakete unterstützen heute nur PAT-basierte Authentifizierung, was 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 Arten der Authentifizierung.

Standardmäßig werden Pakete nicht automatisch in ihre Aufgaben heruntergeladen. Deshalb haben wir das Makro getPackage eingeführt, mit dem Sie das Paket verwenden können, das in der Ressource definiert ist. Ausführliche Informationen finden Sie im folgenden Beispiel:

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

Azure Kubernetes-Dienst-Cluster-Link in die Ressourcenansicht der 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-Dienstclustern zugeordnet sind.

Freigeben von Ordnerfiltern in Benachrichtigungsabonnements

Ordner ermöglichen das Organisieren von Pipelines für eine einfachere Auffindbarkeit und Sicherheitskontrolle. Häufig möchten Sie benutzerdefinierte E-Mail-Benachrichtigungen für alle Releasepipelines konfigurieren, die von allen Pipelines unter 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 der Bereitstellung hinzufügen, die abgeschlossen wurde, und Genehmigung ausstehende Ereignisse ausstehen und die Abonnements vereinfachen.

Verknüpfen von Arbeitsaufgaben mit mehrstufigen YAML-Pipelines

Derzeit können Sie Arbeitsaufgaben 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 mithilfe von Code aus einer angegebenen Verzweigung ausführen, ordnet Azure Pipelines die Ausführung automatisch allen Arbeitsaufgaben zu (die durch die Commits in diesem Code abgeleitet werden). Wenn Sie die Arbeitsaufgabe öffnen, können Sie die Ausführung sehen, in der der Code für diese Arbeitsaufgabe erstellt wurde. Um dies zu konfigurieren, verwenden Sie das Einstellungsmenü einer Pipeline.

Phase in einem mehrstufigen YAML-Pipeline-Lauf abbrechen

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.

Wiederholen fehlgeschlagener Phasen

Eines der am häufigsten angeforderten Features in mehrstufigen Pipelines ist die Möglichkeit, eine fehlgeschlagene Phase erneut auszuführen, 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 nun eine Pipeline-Stufe erneut versuchen, wenn die Ausführung fehlschlägt. Alle Aufträge, die beim ersten Versuch fehlgeschlagen sind, und diejenigen, die transitiv von diesen fehlgeschlagenen Aufträgen abhängen, werden alle erneut versucht.

Dies kann Ihnen dabei helfen, Zeit auf verschiedene Arten zu sparen. Wenn Sie beispielsweise mehrere Aufträge in einer Phase ausführen, möchten Sie möglicherweise, dass jede Phase Tests auf einer anderen Plattform ausführt. 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: Aufgrund einer instabilen Netzwerkverbindung könnte ein Bereitstellungsstadium fehlgeschlagen sein. Wenn Sie diese Phase wiederholen, können Sie Zeit sparen, indem Sie keinen anderen Build erstellen müssen.

In diesem Feature gibt es einige bekannte Lücken. Sie können z. B. keine Phase wiederholen, die Sie explizit abbrechen. 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 Freigaben enthalten. Infrastrukturbetreiber können ihre Umgebungen schützen und manuelle Genehmigungen einholen, bevor eine Phase in irgendeiner Pipeline dort bereitgestellt wird. Mit vollständiger Trennung von Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie sicher, dass Sie eine manuelle Freigabe der Bereitstellung in einer bestimmten Pipeline erhalten und zentrale Kontrolle bei der Anwendung derselben Überprüfungen in der gesamten Umgebung sichern.

Die Pipeline, die auf dem Entwicklungsserver bereitstellt, stoppt zu Beginn der Phase zur Genehmigung.

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

Zuvor war das Timeoutlimit für Toren in Releasepipelinen drei Tage. Mit diesem Update wurde das Timeoutlimit auf 15 Tage erhöht, um Zeitlimits mit längerer Dauer zuzulassen. Wir haben auch die Frequenz des Tors auf alle 30 Minutenerhöht.

Neue Build-Image-Vorlage für Dockerfile

Beim Erstellen einer neuen Pipeline für ein Dockerfile wurde früher im Rahmen der Pipelineerstellung empfohlen, das Image in einer Azure-Containerregistrierung abzulegen und in einem Azure Kubernetes-Dienst bereitzustellen. Wir haben eine neue Vorlage hinzugefügt, mit der Sie ein Image mit dem Agent erstellen können, ohne es an ein Container-Register senden zu müssen.

Neue Aufgabe zum Konfigurieren von Azure App Service-App-Einstellungen

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

Azure App Service unterstützt jetzt Swap with preview

Azure App Service unterstützt jetzt Swap mit Vorschau in seinen Bereitstellungs-Slots. Dies ist eine gute Möglichkeit, die App mit Produktionskonfiguration zu validieren, bevor die App von einem Staging-Slot in einen Produktions-Slot übertragen wird. Dies würde auch sicherstellen, dass der Ziel-/Produktionsplatz keine Ausfallzeiten erlebt.

Azure App Service-Aufgabe unterstützt jetzt diesen mehrstufigen Austausch durch die folgenden neuen Aktionen:

• Start Swap with Preview – Initiiert einen Tausch mit einer Vorschau (Mehrphasentausch) und wendet die Konfiguration des Zielplatzes (z. B. der Produktionsplatz) auf den Quellplatz an.
• Vollständiger Tausch mit Vorschau – Wenn Sie bereit sind, den ausstehenden Tausch abzuschließen, wählen Sie die Aktion "Tausch mit Vorschau abschließen" aus.
• Abbrechen des Tauschs mit Vorschau – Um einen ausstehenden Tausch abzubrechen, wählen Sie "Abbrechen des Tauschs mit Vorschau" aus.

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

Zuvor waren reguläre Ausdrucksfilter für Azure Container Registry- und Docker Hub-Artefakte nur auf der Releasepipelineebene verfügbar. Sie wurden nun auch auf Stufenebene hinzugefügt.

Verbesserungen bei den Freigaben in YAML-Pipelines

Wir haben die Möglichkeit aktiviert, Genehmigungen für Dienstverbindungen und Agentpools zu konfigurieren. Für Genehmigungen folgen wir der Trennung von Rollen zwischen Infrastrukturbesitzern und Entwicklern. Durch die Konfiguration von Genehmigungen für Ihre Ressourcen wie Umgebungen, Dienstverbindungen und Agentpools werden Sie sicher sein, dass alle Pipelineausführungen, die Ressourcen verwenden, zuerst eine Genehmigung erfordern.

Die Erfahrung ähnelt dem Konfigurieren von Genehmigungsprozessen 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

Der Einsatz von Containern in Anwendungen nimmt zu und benötigt daher robuste Tests und Validierungen. Azure Pipelines bietet jetzt Unterstützung für Containerstrukturtests. Dieses Framework bietet eine bequeme und leistungsstarke Möglichkeit, den Inhalt und die Struktur Ihrer Container zu überprüfen.

Sie können die Struktur eines Bilds basierend auf vier Testkategorien ü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, damit Sie Fehler besser beheben können.

Eingeben der Konfigurationsdatei und Bilddetails

Testdaten und Zusammenfassung

Dekoratoren für Freigabepipelines

Pipeline-Dekoratoren erlauben es, Schritte am Beginn und Ende jedes Auftrags hinzuzufügen. Dies unterscheidet sich von dem Hinzufügen von Schritten zu einer einzelnen Definition, da sie für alle Pipelines in einer Auflistung gilt.

Wir haben Dekoratoren für Builds und YAML-Pipelines unterstützt, wobei Kunden sie verwenden, um die Schritte in ihren Prozessen zentral zu steuern. Wir erweitern nun die Unterstützung auch auf Release-Pipelines. Sie können Erweiterungen erstellen, um Schritte hinzuzufügen, die auf das neue Beitragspunktziel abzielen, und sie werden allen Agentaufträgen in Releasepipelines hinzugefügt.

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

Zuvor haben wir Bereitstellungen nur auf Ressourcengruppenebene unterstützt. Mit diesem Update haben wir Unterstützung hinzugefügt, um ARM-Vorlagen sowohl auf abonnement- als auch auf Verwaltungsgruppenebene bereitzustellen. Dies hilft Ihnen beim Gemeinsamen Bereitstellen einer Gruppe von Ressourcen, platzieren sie jedoch in verschiedenen Ressourcengruppen oder Abonnements. Stellen Sie beispielsweise den virtuellen Sicherungscomputer für Azure Site Recovery in einer separaten Ressourcengruppe und einem separaten Speicherort bereit.

CD-Funktionen für Ihre mehrstufigen YAML-Pipelines

Sie können jetzt Artefakte nutzen, die von Ihrer CI-Pipeline veröffentlicht wurden, und Auslöser für den Abschluss der Pipeline aktivieren. In mehrstufigen YAML-Pipelines führen wir pipelines als Ressource ein. In Ihrem YAML können Sie jetzt auf eine andere Pipeline verweisen und auch CD-Trigger aktivieren.

Hier ist das detaillierte YAML-Schema für die 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 Artefakte, die von Ihrer Pipeline-Ressource veröffentlicht wurden, mithilfe des - download Schritts herunterladen.

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

Weitere Details finden Sie in der Dokumentation zum Herunterladen von Artefakten hier.

Orchestriere die Canary-Bereitstellungsstrategie in der Umgebung für Kubernetes

Einer der wichtigsten Vorteile der kontinuierlichen Bereitstellung von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu übertragen. Dadurch erhalten Sie die Möglichkeit, schnell auf Änderungen der Geschäftsanforderungen zu reagieren. Environment wurde als erstklassiges Konzept eingeführt, das die Orchestrierung von Bereitstellungsstrategien und die Erleichterung von Veröffentlichungen ohne Ausfallzeiten ermöglicht. Zuvor haben wir die runOnce Strategie unterstützt, die die Schritte einmal sequenziell ausgeführt hat. Mit Unterstützung für die "Canary Strategy" in mehrstufigen Pipelines können Sie das Risiko jetzt verringern, indem Sie die Änderung schrittweise an eine kleine Teilmenge ausrollen. Wenn Sie mehr Vertrauen in die neue Version gewinnen, können Sie damit beginnen, sie auf mehr Servern in Ihrer Infrastruktur bereitzustellen und weitere 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 Kubernetes 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 auf 100%erhöht.

Wir suchen frühzeitiges Feedback zur Unterstützung von VM-Ressourcen in verschiedenen Umgebungen und zur Durchführung einer schrittweisen Bereitstellungsstrategie auf mehreren Maschinen. Kontaktieren Sie uns, um sich zu registrieren.

Genehmigungsrichtlinien für YAML-Pipelines

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

Sie können jetzt die erweiterten Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien zu konfigurieren, wie dass der Antragsteller nicht genehmigen sollte, die Genehmigung von einer Teilmenge von Benutzern erforderlich ist und ein Genehmigungs-Timeout festgelegt wird.

ACR als erstklassige Pipelineressource

Wenn Sie ein Container-Image verwenden müssen, das in ACR (Azure Container Registry) veröffentlicht wurde und Bestandteil Ihrer Pipeline ist und Ihre Pipeline auslösen, sobald ein neues Image veröffentlicht wird, können Sie die ACR-Container-Ressource 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 können auf ACR-Bildmetadaten mithilfe vordefinierter Variablen zugegriffen werden. Die folgende Liste enthält die ACR-Variablen, die zum Definieren einer ACR-Containerressource in Ihrer Pipeline verfügbar sind.

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 bei der Bewertung der Artefaktüberprüfungsrichtlinie in Pipelines

Wir haben den Artefaktevaluierungstest verbessert, um das Hinzufügen von Richtlinien aus einer Liste vordefinierter Richtliniendefinitionen zu vereinfachen. Die Richtliniendefinition wird automatisch generiert und der Prüfkonfiguration hinzugefügt, die bei Bedarf aktualisiert werden kann.

Unterstützung für Ausgabevariablen in einer Bereitstellungsaufgabe

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

Beim Ausführen von Bereitstellungsstrategien können Sie mithilfe der folgenden Syntax auf Ausgabevariablen für alle Aufträge zugreifen.

• Für die runOnce-Strategie: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Für Canary Strategie: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Für die 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 für mehrere Aufträge

Vermeiden eines Rollbacks kritischer Änderungen

In klassischen Release-Pipelines ist es üblich, dass sie auf geplante Bereitstellungen für regelmäßige Updates angewiesen sind. Wenn Sie jedoch über einen kritischen Fix verfügen, können Sie eine manuelle Bereitstellung außerhalb des Bandes starten. Auf diese Weise bleiben ältere Versionen weiterhin geplant. Dies stellt eine Herausforderung dar, da die manuelle Bereitstellung zurückgesetzt würde, wenn die Bereitstellungen planmäßig fortgesetzt werden. 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 als "Neueste bereitstellen und andere abbrechen" ausgewählt ist.

Vereinfachte Ressourcenautorisierung in YAML-Pipelines

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

Wir machen es jetzt einfacher, Ressourcenautorisierungen zu verwalten. Anstatt dass die Ausführung fehlschlägt, wartet sie am Anfang der Phase, in der die Ressource genutzt wird, auf die Berechtigungen für die Ressourcen. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource über die Seite "Sicherheit" autorisieren.

Evaluierung der Artefaktprüfung

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

Aktualisierungen der Aufgabe zur Bereitstellung der ARM-Vorlage

Zuvor haben wir die Dienstverbindungen in der Bereitstellungsaufgabe der ARM-Vorlage nicht gefiltert. Dies kann dazu führen, dass die Bereitstellung fehlschlägt, wenn Sie eine Verbindung mit einem niedrigeren Bereich auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich auszuführen. Wir haben jetzt eine Filterung für Dienstverbindungen hinzugefügt, um abhängig vom gewählten Bereitstellungsbereich weniger relevante herauszufiltern.

ReviewApp in Umgebung

ReviewApp stellt jede Pullanforderung aus Ihrem Git-Repository in einer dynamischen Umgebungsressource bereit. Reviewer können sehen, wie diese Änderungen aussehen und mit anderen abhängigen Diensten arbeiten, bevor sie mit dem Hauptbranch zusammengeführt und in die Produktion gebracht werden. Dies erleichtert Ihnen das Erstellen und Verwalten von reviewApp-Ressourcen und Sie profitieren von allen Funktionen zur Rückverfolgbarkeit und Diagnose der Umgebungsfeatures. Mithilfe des Schlüsselworts reviewApp können Sie einen Klon einer Ressource erstellen (dynamisch eine neue Ressource basierend auf einer vorhandenen Ressource in einer Umgebung erstellen) und der Umgebung die neue Ressource hinzufügen.

Es folgt ein Beispiel für einen YAML-Codeausschnitt der 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

Automatische und vom Benutzer angegebene Metadaten aus der Pipeline sammeln

Jetzt können Sie die automatische und vom Benutzer angegebene Metadatensammlung aus Pipelineaufgaben aktivieren. Mithilfe von Metadaten können Sie Artefaktrichtlinien für eine Umgebung erzwingen, indem Sie die Artefaktüberprüfungausführen.

VM-Bereitstellungen mit Umgebungen

Eine der am häufigsten angeforderten Features in Umgebungen war VM-Bereitstellungen. Mit diesem Update aktivieren wir die Ressource "Virtueller Computer" in Umgebungen. Sie können jetzt Bereitstellungen auf mehreren Computern koordinieren und Roll- Updates mithilfe von YAML-Pipelines durchführen. Sie können den Agenten auch direkt auf jedem Ihrer Zielserver installieren und die Rollbereitstellung 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 einem rollierenden Satz von Maschinen in jeder Iteration.

Ein Beispiel: Bei einem Rollout von Bereitstellungsupdates werden in jeder Iteration bis zu fünf Ziele aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl berücksichtigt die Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, abzüglich der Ziele, auf die bereitgestellt wird. Es wird auch verwendet, um die Erfolgs- und Fehlerbedingungen während der Bereitstellung zu bestimmen.

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

Anmerkung

Mit diesem Update werden alle verfügbaren Artefakte aus der aktuellen Pipeline und aus den zugehörigen Pipelineressourcen nur im deploy-Lebenszyklus-Hook heruntergeladen. Sie können sich jedoch für den Download entscheiden, indem Sie Aufgabe "Pipelineartefakte herunterladen"angeben. In diesem Feature gibt es einige bekannte Lücken. Wenn Sie beispielsweise eine Phase wiederholen, wird die Bereitstellung auf allen VMs erneut ausgeführt; nicht nur auf den fehlgeschlagenen Zielen. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.

Zusätzliche Kontrolle über Ihre Bereitstellungen

Azure Pipelines unterstützt bereitstellungen, die seit einiger Zeit 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 Prüfungen können verwendet werden, um Vorgänge auszulösen und dann auf den Abschluss zu warten. Mithilfe der zusätzlichen Überprüfungen können Sie nun 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 durchführt. Die Auswertung der einzelnen Überprüfung kann regelmäßig gemäß dem angegebenen Wiederholungsintervall für die Überprüfung wiederholt werden. Die folgenden zusätzlichen Prüfungen sind jetzt verfügbar:

• Aufrufen einer beliebigen REST-API und Durchführen einer Überprüfung basierend auf dem Antworttext oder einem Rückruf vom externen Dienst
• Aufrufen einer Azure-Funktion und Durchführen einer Überprüfung basierend auf der Antwort oder einem Rückruf aus der Funktion
• Abfragen von Azure Monitor-Regeln für aktive Benachrichtigungen
• Stellen Sie sicher, 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 müssen die Genehmigung abschließen, bevor die Pipeline fortgesetzt werden kann.

Mit diesem Update erhalten die Genehmigenden eine E-Mail-Benachrichtigung über die ausstehende Genehmigung. Benutzer und Teambesitzer können benutzerdefinierte Abonnements über Benachrichtigungseinstellungendeaktivieren oder konfigurieren.

Konfigurieren von Bereitstellungsstrategien über das Azure-Portal

Mit dieser Funktion haben wir es Ihnen einfacher gemacht, Pipelines zu konfigurieren, die die Bereitstellungsstrategie Ihrer Wahl verwenden, z. B. Rolling, Canaryoder Blue-Green. Mithilfe dieser sofort einsatzbereiten Strategien können Sie Updates auf sichere Weise bereitstellen und damit verbundene Bereitstellungsrisiken mindern. Um darauf zuzugreifen, klicken Sie auf die Einstellung "Kontinuierliche Übermittlung" 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 zu bereitstellende Paket veröffentlicht, und die Bereitstellungsstrategie Ihrer Wahl. In Zukunft 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

Mit Laufzeitparametern haben Sie mehr Kontrolle darüber, welche Werte an eine Pipeline übergeben werden können. Im Gegensatz zu Variablen weisen Laufzeitparameter Datentypen auf und werden nicht automatisch zu Umgebungsvariablen. Mit Laufzeitparametern können Sie:

• Bereitstellen unterschiedlicher Werte für Skripts und Aufgaben zur Laufzeit
• Steuerelementparametertypen, zulässige Bereiche und Standardwerte
• Dynamisches Auswählen von Aufträgen und Phasen mit Vorlagenausdruck

Weitere Informationen zu Laufzeitparametern finden Sie in der Dokumentation hier.

Verwenden des extends-Schlüsselworts in Pipelines

Derzeit können Pipelines in Vorlagen aufgeteilt werden, die Wiederverwendung fördern und die Bausteine reduzieren. Die Gesamtstruktur der Pipeline wurde noch durch die YaML-Stammdatei definiert. Mit diesem Update haben wir eine strukturiertere Methode zur Verwendung von Pipelinevorlagen hinzugefügt. Eine YAML-Stammdatei kann nun das Schlüsselwort extends verwenden, um anzugeben, dass die Pipeline-Hauptstruktur in einer anderen Datei gefunden werden kann. Dadurch können Sie steuern, welche Segmente erweitert oder geändert werden können und welche Segmente behoben sind. Außerdem haben wir die Pipelineparameter mit Datentypen verbessert, um die bereitstellbaren Hooks klarer zu definieren.

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

# 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 }}

Steuervariablen, die während der Warteschlangenzeit überschrieben werden können

Zuvor können Sie die UI oder REST-API verwenden, um die Werte einer beliebigen Variablen zu aktualisieren, bevor Sie eine neue Ausführung starten. Während der Autor der Pipeline bestimmte Variablen als _settable at queue time_markieren kann, hat das System dies nicht erzwungen oder verhindert, dass andere Variablen festgelegt werden. Mit anderen Worten: Die Einstellung wurde nur verwendet, um beim Starten einer neuen Ausführung zusätzliche Eingaben einzufordern.

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

Anmerkung

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

Neue vordefinierte Variablen in der YAML-Pipeline

Variablen bieten Ihnen eine bequeme Möglichkeit, entscheidende 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, gelten für den spezifischen Bereitstellungsauftrag 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, die durch den Bereitstellungsauftrag angesteuert wird.
• Environment.ResourceName – Der Name der Ressource in der Umgebung, auf die der Bereitstellungsauftrag abzielt.

Auschecken mehrerer Repositories

Pipelines basieren häufig auf mehreren Repositorys. Sie können verschiedene Repositorys mit Quell-, Tools, Skripts oder anderen Elementen verwenden, die Sie zum Erstellen ihres Codes benötigen. Zuvor mussten Sie diese Repositorien als Untermodule oder als manuelle Skripte hinzufügen, um Git-Checkoutauszufü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 ein Repository namens MyCode mit einer YAML-Pipeline und einem zweiten Repository namens Toolshaben, 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 zwei Verzeichnisse MyCode- und Tools im Quellverzeichnis angezeigt.

Azure Repos Git-Repositorys werden unterstützt. Weitere Informationen finden Sie unter Multi-Repo-Checkout.

Abrufen von Details zur Laufzeit zu mehreren Repositories

Wenn eine Pipeline ausgeführt wird, fügt Azure Pipelines Informationen über das Repository, die Verzweigung und den Commit hinzu, der die Ausführung ausgelöst hat. Da YAML-Pipelines das Auschecken mehrerer Repositories unterstützen, möchten Sie möglicherweise auch wissen, welches Repository, welcher Branch und welcher Commit für andere Repositories ausgecheckt wurden. Diese Daten sind über einen Laufzeitausdruck verfügbar, den Sie nun einer Variablen zuordnen können. Zum 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"

Repositoryverweise auf andere Azure Repos-Sammlungen zulassen

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. Zum 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. Sowohl Repos als auch self und otherrepowerden ausgecheckt.

Wichtig

MyServiceConnection muss eine Azure Repos/Team Foundation Server-Dienstverbindung sein, siehe abbildung unten.

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

kustomisieren und kompose als Backoptionen in KubernetesManifest-Aufgabe

mit kustomize (Teil von Kubernetes sig-cli) können Sie rohe, vorlagenfreie YAML-Dateien für mehrere Zwecke anpassen und das ursprüngliche YAML unverändert lassen. Eine Option für kustomize wurde unter Backaktion von KubernetesManifest-Task hinzugefügt, sodass alle Ordner, die kustomization.yaml-Dateien enthalten, zum Generieren der Manifestdateien verwendet werden können, 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 wandelt eine Docker Compose-Dateien in eine Kubernetes-Ressource um.

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 Cluster-Admin-Anmeldedaten in der Helm-Bereitstellungsaufgabe

Zuvor verwendete die Aufgabe HelmDeploy die Cluster-Anmeldeinformationen für Deployments. Dies führte zu interaktiven Anmeldeaufforderungen und fehlerhaften Pipelines für einen azure Active Directory-basierten RBAC-aktivierten Cluster. Um dieses Problem zu beheben, haben wir ein Kontrollkästchen hinzugefügt, mit dem Sie Clusteradministratoranmeldeinformationen anstelle von Clusterbenutzeranmeldeinformationen verwenden können.

Argumenteingabe in Docker Compose-Aufgabe

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 beim Ausführen von Befehlen wie Build übergeben.

Verbesserungen der GitHub-Veröffentlichungsaufgabe

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

Wir haben auch Funktionen hinzugefügt, um die Erstellung und Formatierung von Änderungsprotokollen anzupassen. Im neuen Abschnitt für die Änderungsprotokollkonfiguration können Sie jetzt die Version angeben, mit der die aktuelle Version verglichen werden soll. Die Compare to Release kann die letzte vollständige Version sein (schließt Vorabversionen aus), die letzte Nichtentwurfsversion oder jede vorherige Version, die Ihrem bereitgestellten Releasetag entspricht. Darüber hinaus stellt der Vorgang ein Änderungsprotokolltypfeld zum Formatieren des Änderungsprotokolls bereit. Basierend auf der Auswahl zeigt der Änderungsprotokoll entweder eine Liste von Commits oder eine Liste von Problemen/PRs an, die basierend auf Bezeichnungen kategorisiert sind.

Öffnen der Installationsaufgabe für Open Policy Agent

Der Open Policy Agent ist ein Open Source-Modul für allgemeine Richtlinien, das eine einheitliche, kontextbezogene Richtlinienerzwingung ermöglicht. Wir haben die Installationsprogrammaufgabe des Open Policy Agent hinzugefügt. Es ist besonders nützlich für die Durchsetzung von In-Pipeline-Richtlinien in Bezug auf Infrastruktur als Codeanbieter.

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

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

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

Zuvor konnten Sie Batch- und Bash-Skripts 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.

Canary-Bereitstellungen basierend auf der Service-Mesh-Schnittstelle in der Kubernetes-Manifest-Aufgabe

Wenn früher die Canary-Strategie in der KubernetesManifest-Aufgabe angegeben wurde, erstellte die Aufgabe Baseline- und Canary-Workloads, deren Replikas einem Prozentsatz der Replikas entsprachen, die für stabile Workloads verwendet wurden. Dies war nicht genau identisch mit dem Aufteilen des Datenverkehrs bis zum gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir Unterstützung für Service Mesh Interface basierte Canary-Bereitstellungen zur KubernetesManifest-Aufgabe hinzugefügt.

Die Abstraktion von Service Mesh Interface ermöglicht die Plug-and-Play-Konfiguration mit Dienstanbietern wie Linkerd und Istio. Jetzt übernimmt die KubernetesManifest-Aufgabe die harte Arbeit der Zuordnung von SMI-TrafficSplit-Objekten zu den stabilen, Basis- und Canary-Diensten während der Phase der Bereitstellungsstrategie. Die gewünschte prozentuale Aufteilung des Datenverkehrs zwischen stabilen Versionen, Baseline und Canary-Versionen ist genauer, da die prozentuale Datenverkehrsteilung für die Anfragen in der Service-Mesh-Ebene gesteuert wird.

Im Folgenden sehen Sie ein Beispiel für die Durchführung von SMI-basierten Canary-Bereitstellungen in einer rollierenden Weise.

- 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

Die Azure-Dateikopie-Aufgabe kann in einer Build- oder Releasepipeline verwendet werden, um Dateien auf Microsoft-Speicher-Blobs oder virtuelle Computer (VMs) zu kopieren. Die Aufgabe verwendet AzCopy, das Befehlszeilenwerkzeug für das schnelle Kopieren von Daten aus und in Azure-Speicherkonten. Mit diesem Update haben wir Unterstützung für AzCopy V10 hinzugefügt, die die neueste Version von AzCopyist.

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

• Speicherort des Protokolls angeben
• Bereinigen von Protokoll- und Plandateien nach der Kopie
• Fortsetzen, wenn Auftrag fehlschlägt

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

• Wildcardsymbole im Dateinamen/Pfad der Quelle
• Ableiten des Inhaltstyps basierend auf der Dateierweiterung, wenn keine Argumente angegeben werden
• Festlegen der Protokollausfü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 in Azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Protokolle hochzuladen, Testergebnisse, Artefakte oder REST-Aufrufe in Azure DevOps auszuführen. Ein neues Zugriffstoken wird für jeden Auftrag generiert und läuft nach Abschluss des Auftrags ab. Mit diesem Update haben wir die folgenden Verbesserungen hinzugefügt.

• Verhindern des Zugriffs auf Ressourcen außerhalb eines Teamprojekts

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

  Anmerkung

  Die Sammlungseinstellung 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 auf Ressourcen zugreifen, die sich außerhalb des Teamprojekts befinden und Zugriffstoken verwenden. Um Pipelinefehler zu vermeiden, können Sie dem Project Build Service Account explizit Zugriff auf die gewünschte Ressource gewähren. Es wird dringend empfohlen, diese Sicherheitseinstellungen zu aktivieren.

• Umfangszugriff der Build-Service-Repos einschränken

  Basierend auf der Verbesserung der Pipelinesicherheit durch Einschränken des Umfangs des Zugriffstokens können Azure Pipelines nun ihren Repositoryzugriff auf nur die Repos beschränken, die für eine YAML-basierte Pipelineerforderlich sind. Dies bedeutet, dass, wenn das Zugriffstoken der Pipelines leaken würde, es nur die in der Pipeline verwendeten Repositorys sehen könnte. Zuvor war das Zugriffstoken für jedes Azure Repos-Repository im Projekt oder potenziell 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 es in den Sammlungseinstellungen>Pipelines>Einstellungenaktivieren. Bei Verwendung dieses Features müssen alle Repositorys, die vom Build benötigt werden (auch diejenigen, die Sie mit einem Skript klonen), in die Repositoryressourcen der Pipeline einbezogen werden.

• Bestimmte Berechtigungen für das Zugriffstoken entfernen

  Standardmäßig gewähren wir dem Zugriffstoken eine Reihe von Berechtigungen, 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 diese dem Project Build Service Account oder Project Collection Build Service Account je nach verwendeten Token explizit erteilen.

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 an einem zentralen Ort für alle Dienstverbindungen verwalten.

Schrittzielsetzung und Befehlsisolation

Azure Pipelines unterstützt das Ausführen von Aufträgen entweder in Containern oder auf dem Agenthost. Zuvor wurde ein vollständiger Auftrag auf eines dieser beiden Ziele festgelegt. Jetzt 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 spezialisierten, zweckgebauten Container ausführen kann.

Container können als Isolationsgrenzen fungieren und verhindern, dass Code unerwartete Änderungen auf dem Hostcomputer vornehmen kann. Die Art und Weise, wie Schritte mit dem Agenten kommunizieren und auf dessen Dienste zugreifen, wird durch die Isolierung von Schritten in einem Container nicht beeinträchtigt. 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 Agenten anfordern kann. Es wird nicht mehr in der Lage sein, Protokolle anzuhängen, Artefakte hochzuladen und bestimmte andere Vorgänge auszuführen.

Im Folgenden finden 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, aber in der Praxis könnten sie von einem Vorgang überschrieben werden, und nachgelagerte Vorgänge 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 rollenbasierten Zugriff für Dienstverbindungen hinzugefügt. Bisher konnte die Dienstverbindungssicherheit nur über vordefinierte Azure DevOps-Gruppen wie Endpunktadministratoren und Endpunktersteller verwaltet werden.

Im Rahmen dieser Arbeit haben wir die neuen Rollen "Reader", "User", "Creator" 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. Und 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.

Erfahren Sie mehr über die Sicherheit von Dienstverbindungen hier.

Projektübergreifende Freigabe von Dienstverbindungen

Wir haben die Unterstützung für die Dienstverbindungsfreigabe über mehrere Projekte hinweg aktiviert. Sie können jetzt Ihre Dienstverbindungen sicher und sicher mit Ihren Projekten teilen.

Erfahren Sie hier mehr über das Teilen von Dienstverbindungen.

Rückverfolgbarkeit 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 verbraucht wird, können Sie die Commits, Arbeitsaufgaben und Artefakte zurückverfolgen.

In der Zusammenfassungsansicht "Pipelineausführung" können Sie Folgendes sehen:

• Die Ressourcenversion, die die Ausführungausgelöst hat. Jetzt kann Ihre Pipeline nach Abschluss einer anderen Azure-Pipelineausführung ausgelöst werden oder wenn ein Containerimage an ACR weitergeleitet wird.

  

• Die von der Pipeline verbrauchten Commits . Sie finden auch die Aufschlüsselung der Commits nach jeder Ressource, die von der Pipeline verbraucht wird.

  

• Die Arbeitsaufgaben, die den einzelnen Ressourcen zugeordnet sind, die von der Pipeline verwendet werden.

• Die Artefakte, die beim Lauf verwendet werden können.

  

In der Bereitstellungsansicht der Umgebung können Sie die Commits und Arbeitsaufgaben für jede Ressource anzeigen, die in der Umgebung bereitgestellt wird.

Unterstützung für große Testanhänge

Mit der Aufgabe zum Veröffentlichen von Testergebnissen in Azure Pipelines können Sie Testergebnisse veröffentlichen, wenn Tests ausgeführt werden, um eine umfassende Testberichterstattung und Analyseerfahrung bereitzustellen. Bisher gab es eine Beschränkung von 100 MB für Testanlagen sowohl für Testausführungen als auch für Testergebnisse. Dies beschränkte den Upload großer Dateien wie Absturzabbilder oder Videos. Mit diesem Update haben wir Unterstützung für große Testanhänge hinzugefügt, sodass Sie alle verfügbaren Daten zur Problembehandlung Ihrer fehlgeschlagenen Tests zur Verfügung haben.

Möglicherweise treten die VSTest-Aufgabe oder die Aufgabe zum Veröffentlichen von Testergebnissen auf, die einen Fehler von 403 oder 407 in den Protokollen zurückgeben. Wenn Sie selbst gehostete 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, empfehlen wir, die Firewall für ausgehende Anfragen auf https://*.vstmrblob.vsassets.iozu aktualisieren. Informationen zur Problembehandlung finden Sie in der Dokumentation hier. ​

Anmerkung

Dies ist nur erforderlich, wenn Sie selbst gehostete 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 nicht ausgehenden Netzwerkdatenverkehr filtern, müssen Sie keine Maßnahmen ergreifen.

Richtige Poolinformationen für jeden Auftrag anzeigen

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

CI-Trigger für neue Filialen

Es war seit langem eine offene Anforderung, CI-Builds nicht auszulösen, wenn ein neuer Branch erstellt wird und dieser Branch keine Änderungen hat. Betrachten Sie die folgenden Beispiele:

• Sie verwenden die Webschnittstelle, um eine neue Verzweigung basierend auf einer vorhandenen Verzweigung zu erstellen. Dadurch würde sofort ein neuer CI-Build ausgelöst werden, wenn Ihr Branch-Filter mit dem Namen des neuen Branches übereinstimmt. Dies ist unerwünscht, da der Inhalt der neuen Verzweigung mit der bestehenden Verzweigung identisch ist.
• Sie verfügen über ein Repository mit zwei Ordnern – App und Dokumente. Sie richten einen Pfadfilter für CI ein, der mit "app" übereinstimmt. Mit anderen Worten, Sie möchten keinen neuen Build erstellen, wenn eine Änderung an die Dokumentation übertragen wurde. Sie erstellen lokal einen neuen Branch, nehmen einige Änderungen an der Dokumentation vor und übertragen diesen Branch dann auf den Server. Früher haben wir einen neuen CI-Build ausgelöst. Dies ist unerwünscht, da Sie explizit aufgefordert haben, nicht nach Änderungen im Dokumentordner zu suchen. Aufgrund der Art und Weise, wie wir ein neues Branch-Event behandelt haben, könnte es so aussehen, als wäre auch eine Änderung am App-Ordner vorgenommen worden.

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

Jobs können auf Ausgabevariablen aus früheren Phasen zugreifen.

Jetzt können Ausgabevariablen in einer YAML-basierten Pipeline über Phasen hinweg verwendet werden. Auf diese Weise können Sie nützliche Informationen, z. B. eine Go/no-go Entscheidung oder die ID einer generierten Ausgabe, von einer Phase bis zur nächsten übergeben. Das Ergebnis (Status) einer vorherigen Stufe und deren Aufträge sind ebenfalls verfügbar.

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

Anmerkung

Standardmäßig hängt jede Phase in einer Pipeline von demjenigen unmittelbar davor in der YAML-Datei ab. Daher kann jede Phase Ausgabevariablen aus der vorherigen Phase verwenden. Sie können das Abhängigkeitsdiagramm ändern, wodurch auch geändert wird, welche Ausgabevariablen verfügbar sind. Wenn Stufe 3 beispielsweise eine Variable aus Phase 1 benötigt, muss sie eine explizite Abhängigkeit von Stufe 1 deklarieren.

Deaktivieren von automatischen Agents-Upgrades auf Poolebene

Derzeit werden Pipelines-Agents bei Bedarf automatisch auf die neueste Version aktualisiert. Dies geschieht in der Regel, wenn eine neue Funktion oder Aufgabe verfügbar ist, die eine neuere Version des Agenten benötigt, 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 die Pipelines mit einer klaren Fehlermeldung fehl, anstatt die Agents zur Aktualisierung aufzufordern. Dieses Feature ist hauptsächlich für Kunden mit selbst gehosteten Pools und sehr strengen Änderungskontrollanforderungen von Interesse. Automatische Updates sind standardmäßig aktiviert, und wir empfehlen den meisten Kunden nicht, sie zu deaktivieren.

Agentendiagnostik

Wir haben Diagnosen für viele häufige Agent-bezogene Probleme hinzugefügt, z. B. viele Netzwerkprobleme und häufige Ursachen von Upgradefehlern. Um mit der Diagnose zu beginnen, verwenden Sie run.sh --diagnostics- oder run.cmd --diagnostics- unter Windows.

Service-Hooks für YAML-Pipelines

Die Integration von Diensten in YAML-Pipelines ist noch einfacher geworden. Mithilfe von Dienst-Hooks-Ereignissen für YAML-Pipelines können Sie nun Aktivitäten in benutzerdefinierten Apps oder Diensten basierend auf dem Fortschritt der Pipelineausführung steuern. Sie können z. B. 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 fehlschlägt.

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

Optimierung der Integration

Optimizely ist eine leistungsstarke A/B-Test- und Feature-Flagging-Plattform für Produktteams. Durch die Integration von Azure-Pipelines mit der Plattform "Optimierungsexperiment" können Produktteams in beschleunigtem Tempo testen, lernen und bereitstellen und gleichzeitig alle DevOps-Vorteile von Azure-Pipelines gewinnen.

Die Optimizely-Erweiterung für Azure DevOps fügt den Build- und Release-Pipelines Experimentier- und Feature-Flags-Rollout-Schritte hinzu, sodass Sie kontinuierlich iterieren, Features ausrollen und mit Azure-Pipelines zurückrollen können.

Erfahren Sie mehr über die Azure DevOps Optimizely-Erweiterung hier.

Hinzufügen einer GitHub-Version als Artefaktquelle

Jetzt können Sie Ihre GitHub-Versionen als Artefaktquelle in Azure DevOps-Releasepipelinen verknüpfen. Dadurch können Sie die GitHub-Version als Teil Ihrer Bereitstellungen nutzen.

Wenn Sie in der Release-Pipeline-Definition auf "Artefakt hinzufügen" klicken, finden Sie den neuen Quelltyp GitHub Release. Sie können die Dienstverbindung und das GitHub-Repository bereitstellen, um die GitHub-Version zu nutzen. Sie können auch eine Standardversion für die GitHub-Version auswählen, um sie als neueste, spezifische Tagversion zu nutzen oder zum Zeitpunkt der Veröffentlichungserstellung auszuwä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, Änderungs- und Versionsverwaltungsinfrastruktur. 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 ihre Auswirkungen auf ein bestimmtes Ziel zu messen. Sie können beispielsweise Aktivitäten haben, die Ihre Benutzer abschließen möchten (z. B. einen Kauf tätigen, sich für einen Newsletter registrieren) und/oder Metriken, die Sie verbessern möchten (z. B. Umsatz, Sitzungsdauer, Unzustellbarkeitsrate). Mit diesen Aktivitäten können Sie Änderungen identifizieren, die eine Implementierung wert sind, basierend auf den direkten Auswirkungen, die sie auf die Leistung Ihres Features haben.

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

Sie können die Google Analytics Experiment Erweiterung aus dem Marketplace herunterladen.

Aktualisierte ServiceNow-Integration mit Azure Pipelines

Die Azure Pipelines-App für ServiceNow hilft bei der 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 mit OAuth und Standardauthentifizierung erfolgen. Darüber hinaus können Sie jetzt erweiterte Erfolgskriterien konfigurieren, damit Sie jede Änderungseigenschaft verwenden können, um das Gate-Ergebnis zu entscheiden.

Erstellen von Azure-Pipelines aus 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.

Unzuverlässige Fehlerverwaltung und -behebung

Wir haben ein instabiles Testmanagement eingeführt, um den End-to-End-Lebenszyklus mit Erkennung, Berichterstattung und Lösung von Problemen zu unterstützen. Um es weiter zu verbessern, fügen wir die Verwaltung und Behebung von instabilen Testfehlern hinzu.

Bei der Untersuchung des instabilen Tests können Sie einen Fehler mithilfe der Aktion Bug erstellen, der dann einem Entwickler zugewiesen werden kann, um die Ursache des instabilen 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 behoben oder geschlossen wird, entfernen wir automatisch die Markierung des Tests als unzuverlässig.

Festlegen, dass VSTest-Aufgaben fehlschlagen, wenn eine Mindestanzahl von Tests nicht ausgeführt wird

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

Die Option "VSTest TestResultsDirectory" ist in der Aufgaben-UI verfügbar.

Die VSTest-Aufgabe speichert Testergebnisse und zugeordnete Dateien im ordner $(Agent.TempDirectory)\TestResults. Wir haben der Aufgaben-UI 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.

Markdown-Unterstützung in automatisierten Testfehlermeldungen

Wir haben markdown-Unterstützung für Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie Fehlermeldungen sowohl für testausführungs- als auch für Testergebnisse problemlos formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu vereinfachen. Die unterstützte Markdownsyntax finden Sie hier .

Verwenden Sie Pipelinedekoratoren, um Schritte automatisch in einen Bereitstellungsjob einzufügen.

Sie können jetzt Pipelinedekoratoren zu Bereitstellungsjobs hinzufügen. Sie können jeden benutzerdefinierten Schritt (z. B. Schwachstellenscanner) automatisch in jede Ausführung eines Lebenszyklus-Hooks jedes Bereitstellungsauftrags einfügen. Da Pipelinendekoratoren auf alle Pipelines in einer Kollektion angewendet werden können, kann dies als Teil der Durchsetzung sicherer Bereitstellungspraktiken genutzt werden.

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

Testpläne

Seite "Neuer Testplan"

Eine neue Seite "Testpläne" (Testpläne *) ist für alle Azure DevOps-Sammlungen verfügbar. Die neue Seite bietet optimierte Ansichten, die Ihnen dabei helfen, sich auf die aufgabe zu konzentrieren – Testplanung, Erstellung oder Ausführung. Es ist auch übersichtlich und konsistent mit dem restlichen Azure DevOps-Angebot.

Helfen Sie mir, die neue Seite zu verstehen

Übersichtsseite

Die neue Seite "Testpläne" umfasst insgesamt 6 Abschnitte, von denen die ersten 4 neu sind, während die Diagramme & Erweiterbarkeitsabschnitte die vorhandenen Funktionen sind.

1. Testplan-Kopfzeile: Verwenden Sie dies, um einen Testplan aufzurufen, zu favorisieren, zu bearbeiten, zu kopieren oder zu klonen.
2. Testsammlungsstruktur: Verwenden Sie diese Struktur, um Testsammlungen hinzuzufügen, zu verwalten, zu exportieren oder zu bestellen. 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 zusammenstellen, hinzufügen und verwalten.
4. Registerkarte "Ausführen": Weisen Sie Tests dieser Registerkarte zu und führen Sie sie aus, oder suchen Sie ein Testergebnis, um es näher zu analysieren.
5. Registerkarte "Diagramm": Nachverfolgen der Testausführung und des Status über Diagramme, die auch an Dashboards angeheftet werden können.
6. Erweiterbarkeit: Unterstützt die aktuellen Erweiterungspunkte innerhalb des Produkts.

Lassen Sie uns einen Überblick über diese neuen Abschnitte verschaffen.

1. Testplan-Kopfzeile

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 klar angibt, ob der Testplan Aktuell oder Vergangen ist.
• Anzeigen der schnellen Zusammenfassung des Teststatusberichts mit einem Link zum Navigieren zum Bericht
• Zurück zur Seite "Alle/Meine Testpläne" navigieren

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. Weitere Details unten.
• Testplan bearbeiten: Mit dieser Option können Sie das Arbeitsaufgabenformular "Testplan" bearbeiten, um die Arbeitsaufgabenfelder zu verwalten.
• Testplaneinstellungen: Mit dieser Option können Sie die Testausführungseinstellungen konfigurieren (um Build- oder Freigabepipelinen zuzuordnen) und die Testergebniseinstellungen

Kopieren des Testplans (neue Funktion)

Wir empfehlen, einen neuen Testplan pro Sprint/Release zu erstellen. In der Regel kann 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 einfach zu gestalten, haben wir auf der neuen Seite eine Funktion "Testplan kopieren" aktiviert. Durch die Nutzung können Sie Testpläne kopieren oder klonen. Die zugrunde liegende REST-API wird hier erläutert, und mit der API können Sie ebenso einen Testplan projektsübergreifend kopieren/klonen.
Weitere Informationen zu Richtlinien für die Verwendung von Testplänen finden Sie hier .

2. Baumstruktur der Testsuiten

Aufgaben-

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

• Erweitern/Reduzieren: Mit diesen Symbolleistenoptionen können Sie die Hierarchiestruktur der Suite erweitern oder reduzieren.
• Testpunkte von untergeordneten Suiten anzeigen: Diese Symbolleistenoption ist nur sichtbar, wenn Sie sich auf der Registerkarte "Ausführen" befinden. Damit können Sie alle Testpunkte für die angegebene Suite und ihre untergeordneten Suiten in einer Ansicht anzeigen, um die Verwaltung der Testpunkte zu erleichtern, ohne zu den einzelnen Suiten nacheinander navigieren zu müssen.
• Test Suites organisieren: Sie können Test Suites per Drag & Drop verschieben, um entweder die Hierarchie der Test Suites neu zu ordnen oder sie innerhalb des Testplans von einer Hierarchie in eine andere zu verschieben.

Kontextmenüoptionen

Das Kontextmenü im Testsammlungen-Baum bietet die folgenden Optionen:

• Neue Suites erstellen: Sie können 3 verschiedene Arten von Suites wie folgt erstellen:
  • Verwenden Sie statische Suite oder Ordnersuite, um Ihre Tests zu organisieren.
  • Verwenden Sie die anforderungsbasierte Suite, um direkt mit den Anforderungen/Benutzergeschichten zu verknüpfen und für eine nahtlose Rückverfolgbarkeit zu sorgen.
  • Verwenden Sie einen abfragebasierten Ansatz, um Testfälle dynamisch zu organisieren, die bestimmten Abfragekriterien entsprechen.
• Konfigurationenzuweisen: Sie können Konfigurationen für die Suite zuweisen (Beispiel: Chrome, Firefox, EdgeChromium), und diese würden dann für alle vorhandenen Testfälle oder neue Testfälle gelten, die Sie später zu dieser Suite hinzufügen.
• Als PDF/E-Mail exportieren: Exportieren Sie die Testplaneigenschaften, Test suite-Eigenschaften sowie Details der Testfälle und Testpunkte als "E-Mail" oder "in pdf drucken".
• Arbeitsaufgabe "Testsuite öffnen": Mit dieser Option können Sie das Arbeitsaufgabenformular "Test suite" bearbeiten, um die Arbeitsaufgabenfelder zu verwalten.
• Tester zuweisen, um alle Tests auszuführen: Diese Option ist sehr nützlich für Benutzerakzeptanztests (User Acceptance Testing, UAT) Szenarien, in denen derselbe Test von mehreren Testern ausgeführt werden muss, im Allgemeinen zu verschiedenen Abteilungen gehören.
• Umbenennen/Löschen: Mit diesen Optionen können Sie den Namen der Suite verwalten oder die Suite und deren Inhalt aus dem Testplan entfernen.

3. Tabulator definieren

Mit der Registerkarte "Definieren" können Sie Testfälle für eine Testsuite zusammenfügen, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient zwar zum Zuweisen von Testpunkten und zum Ausführen dieser Punkte.

Die Registerkarte "Definieren" und bestimmte Vorgänge sind nur für Benutzer mit Basic + Test Plans Zugriffsebene oder gleichwertig verfügbar. Alles andere sollte von einem Benutzer mit der Zugriffsebene "Einfach" exercisierbar sein.

Aufgaben-

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

• Neuen Testfall mithilfe des Arbeitsaufgabenformularshinzufügen: Mit dieser Option können Sie mithilfe des Arbeitsaufgabenformulars einen neuen Testfall erstellen. Der erstellte Testfall wird automatisch der Suite hinzugefügt.
• Neuen Testfall mithilfe des Rastershinzufü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 Abfragehinzufügen: Mit dieser Option können Sie der Suite vorhandene Testfälle hinzufügen, indem Sie eine Abfrage angeben.
• Testfälle mittels Drag-and-Drop anordnen: Sie können Testfälle neu anordnen, indem Sie einen oder mehrere Testfälle innerhalb eines bestimmten Testfall-Sets per Drag-and-Drop verschieben. 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 von einer Testsuite in eine andere verschieben.
• Raster-anzeigen: Sie können den Rastermodus zusammen mit Testschritten zum Anzeigen/Bearbeiten von Testfällen verwenden.
• Vollbildansicht: Sie können den Inhalt der gesamten Registerkarte "Definieren" in einem Vollbildmodus anzeigen, indem Sie diese Option verwenden.
• Filterung: 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" mit "Spaltenoptionen" sichtbar sind. Die Liste der spalten, die für die Auswahl verfügbar sind, sind in erster Linie die Felder aus dem Arbeitsaufgabenformular für Testfälle.

Kontextmenüoptionen

definieren

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

• Testfall-Arbeitsaufgabe öffnen/bearbeiten: Mit dieser Option können Sie einen Testfall mithilfe des Formulars für Arbeitsaufgaben bearbeiten, indem Sie die Felder der Arbeitsaufgabe einschließlich der Testschritte ändern.
• Testfälle bearbeiten: Mit dieser Option können Sie die Arbeitsaufgabenfelder der Testfälle in Massenbearbeitung ändern. Sie können diese Option jedoch nicht zur Massenbearbeitung von Testschritten verwenden.
• Testfälle im Raster bearbeiten: Mit dieser Option können Sie die ausgewählten Testfälle, einschließlich testschritten, in der Rasteransicht massenweise bearbeiten.
• Konfigurationenzuweisen: Mit dieser Option können Sie die Konfigurationen auf Suiteebene mit Konfigurationen auf Testfallebene außer Kraft setzen.
• Testfälle entfernen: Mit dieser Option können Sie die Testfälle aus der angegebenen Suite entfernen. Es ändert jedoch nicht die zugrunde liegende Arbeitsaufgabe für Testfälle.
• Erstellen einer Kopie/eines Klons von Testfällen: Mit dieser Option können Sie eine Kopie/einen Klon ausgewählter Testfälle erstellen. Weitere Details finden Sie weiter unten.
• Verknüpfte Elemente anzeigen: Mit dieser Option können Sie die verknüpften Elemente für einen bestimmten Testfall betrachten. Weitere Details finden Sie weiter unten.

Testfälle kopieren/klonen (neue Funktion)

Für 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 Zieltestsuite 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.

Verknüpfte Elemente anzeigen (neue Funktion)

Die Rückverfolgbarkeit zwischen Testartefakten, Anforderungen und Fehlern ist ein wichtiger Wert für das Produkt "Testpläne". Mithilfe der Option "Verknüpfte Elemente anzeigen" können Sie ganz einfach alle verknüpften Anforderungen anzeigen, mit denen dieser Testfall verknüpft ist, mit allen Testsammlungen/Testplänen, in denen dieser Testfall verwendet wurde, und alle Fehler, die als Teil der Testausführung abgelegt wurden.

4. Registerkarte "Ausführen"

ausführen

Mit der Registerkarte "Definieren" können Sie Testfälle für eine Testsuite zusammenfügen, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient zwar zum Zuweisen von Testpunkten und zum Ausführen dieser Punkte.

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

Einer der Hauptvorteile der neuen Seite ist für Nutzer, die vor allem Testausführung/-nachverfolgung durchführen (und nur die Zugriffsebene 'Basis' benötigen), dass sie nicht von der Komplexität der Verwaltung der Suite überwältigt werden (die Registerkarte 'Definieren' ist für solche Nutzer ausgeblendet).

Die Registerkarte "Definieren" und bestimmte Vorgänge sind nur für Benutzer mit Basic+Testpläne Zugriffsebene oder gleichwertig verfügbar. Alles andere, einschließlich der Registerkarte "Ausführen", sollte von einem Benutzer mit der Zugriffsebene "Einfach" exercisierbar sein.

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 schnell markieren – bestanden, fehlgeschlagen, blockiert oder nicht anwendbar, ohne den Testfall über den Test Runner ausführen zu müssen. Das Ergebnis kann für einen oder mehrere Testpunkte in einem Schritt markiert werden.
• Testpunkte ausführen: Mit dieser Option können Sie die Testfälle ausführen, indem Sie jeden Testschritt einzeln durchlaufen und mit einem Testläufer bestanden/fehlschlagen. Abhängig von der Anwendung, die Sie testen, können Sie den "Web Runner" zum Testen einer "Webanwendung" oder des "Desktop-Runners" 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" mit "Spaltenoptionen" angezeigt werden. Die Liste der für die Auswahl verfügbaren Spalten sind Testpunkten zugeordnet, z. B. "Ausgeführt von", "Zugewiesener Tester", "Konfiguration" usw.
• Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte "Ausführen" im Vollbildmodus anzeigen.
• Filterung: Mithilfe der Filterleiste können Sie die Liste der Testpunkte mithilfe der Felder "Testfalltitel", "zugewiesen an", "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:

• Testergebnismarkieren: Wie oben können Sie das Ergebnis der Testpunkte schnell markieren – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend.
• Testpunkte ausführen: Gleiche Funktionalität wie oben, Sie können die Testfälle über den Test-Runner ausführen.
• Test auf aktivezurücksetzen: Mit dieser Option können Sie das Testergebnis auf "aktiv" zurücksetzen und dabei das letzte Ergebnis des Testpunkts ignorieren.
• Arbeitsaufgabenformular "Testfall öffnen/bearbeiten": Mit dieser Option können Sie einen Testfall bearbeiten, indem Sie das Arbeitsaufgabenformular nutzen, um die Felder der Arbeitsaufgabe, einschließlich der Testschritte, zu bearbeiten.
• Testerzuweisen: Mit dieser Option können Sie testern die Testpunkte für die Testausführung zuweisen.
• Testergebnis anzeigen: Mit dieser Option können Sie die neuesten Details des Testergebnisses anzeigen, einschließlich des Ergebnisses der einzelnen Testschritte, Kommentare, die hinzugefügt wurden, und gemeldete Fehler.
• Ausführungsverlauf anzeigen: Mit dieser Option können Sie den gesamten Ausführungsverlauf für den ausgewählten Testpunkt anzeigen. Es 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.

Testpläne Fortschrittsbericht

Dieser sofort einsatzbereite Bericht hilft Ihnen, die Ausführung und den Status eines oder mehrerer Testpläne in einem Projekt nachzuverfolgen. Besuchen Sie Testpläne > 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: bietet eine tägliche Momentaufnahme, um Ihnen eine Ausführungs- und Status-Trendlinie zu zeigen. Sie kann Daten für 14 Tage (Standard), 30 Tage oder einen benutzerdefinierten Bereich anzeigen.
3. Details: In diesem Abschnitt kannst du dir eine detaillierte Einsicht in jeden Testplan verschaffen und erhältst wichtige Analysen für jede Testsuite.

Artefakte

Anmerkung

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 den 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 mit Lizenzausdrücken oder eingebetteten Lizenzen dargestellt werden. Nun sehen Sie einen Link zu den Lizenzinformationen auf der Seite mit den Details 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 Oberfläche ist sowohl für Lizenzausdrücke als auch für eingebettete Lizenzen identisch, sodass Sie Lizenzdetails für Pakete anzeigen können, die in Azure Artifacts an einem Ort gespeichert sind (für Pakete, die Lizenzinformationen angeben und von Visual Studio unterstützt werden).

Einfache Authentifizierungsaufgaben

Sie können sich jetzt mit beliebten Paketmanagern aus Azure Pipelines mithilfe von leichtgewichtigen Authentifizierungsaufgaben authentifizieren. Dazu gehören NuGet, npm, PIP, Twine und Maven. Zuvor konnten Sie sich mit diesen Paketmanagern authentifizieren, indem Sie Aufgaben verwenden, die eine große Funktionalität bereitgestellt haben, einschließlich der Möglichkeit zum Veröffentlichen und Herunterladen von Paketen. Dies erforderte jedoch die Verwendung dieser Aufgaben für alle Aktivitäten, die mit den Paketmanagern interagierten. Wenn Sie ihre eigenen Skripts zum Ausführen von Aufgaben wie dem Veröffentlichen oder Herunterladen von Paketen ausgeführt haben, können Sie sie nicht in Ihrer Pipeline verwenden. Jetzt können Sie Skripts Ihres eigenen Designs in Ihrer Pipeline YAML verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben ausführen. Beispiel für npm:

Die Verwendung des Befehls "ci" und "veröffentlichen" in dieser Abbildung sind beliebig, Sie können alle Befehle verwenden, die von Azure Pipelines YAML unterstützt werden. Auf diese Weise können Sie die vollständige Kontrolle über befehlsaufrufe haben und die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration vereinfachen. Weitere Informationen finden Sie unter NuGet, npm, PIP, Twineund Maven Authentifizierungsaufgabendokumentation.

Verbesserungen der Ladezeit der Feedseite

Wir freuen uns, ihnen mitzuteilen, dass wir die Ladezeit der Feedseite verbessert haben. Im Durchschnitt haben sich die Ladezeiten der Feedseiten um 10%verringert. Die größten Feeds haben die größte Verbesserung der 99. Quantil-Feedseitenladezeit (Ladezeiten in den höchsten 99% aller Feeds) um 75%verringert.

Teilen Sie Ihre Pakete über öffentliche Feeds.

Sie können jetzt Ihre Pakete in öffentlichen Feeds erstellen und speichern. Pakete, die in öffentlichen Feeds gespeichert sind, sind für jeden im Internet ohne Authentifizierung 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 springen Sie direkt zu unserem Tutorial, um Pakete öffentlich zu teilen.

Konfigurieren von Upstreams in verschiedenen Sammlungen in einem AAD-Mandanten

Sie können jetzt einen Feed in einer anderen Sammlung hinzufügen, die Ihrem Azure Active Directory (AAD)-Mandanten zugeordnet ist, als upstream-Quelle zu Ihrem Artefaktefeed. Ihr Feed kann Pakete aus den Feeds suchen und verwenden, die als Upstreamquellen konfiguriert sind, sodass Pakete problemlos für Sammlungen freigegeben werden können, die Ihrem AAD-Mandanten zugeordnet sind. Erfahren Sie, wie Sie dies in den Dokumenten einrichten.

Verwendung des Python Credential Providers zur Authentifizierung von Pip und Twine mit Azure Artifacts-Feeds

Sie können jetzt den Python-Anmeldeinformationsanbieter (Artefakte-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 Bereitsteller von Anmeldeinformationen müssen Sie keine Konfigurationsdateien einrichten (pip.ini/pip.conf/.pypirc), Sie werden einfach durch einen Authentifizierungsprozess in Ihrem Webbrowser geführt, 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 von Azure Artifacts-Feeds bereitgestellt werden. Bisher wurden die meisten dieser Metadaten nicht für VS bereitgestellt.

Aktualisierte Funktion "Mit Feed verbinden"

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

Öffentliche Feeds sind jetzt allgemein mit upstream-Unterstützung verfügbar

Die öffentliche Vorschau öffentlicher Feeds hat große Akzeptanz und Feedback erhalten. In dieser Version haben wir zusätzliche Funktionen für die allgemeine Verfügbarkeit freigegeben. Jetzt können Sie einen öffentlichen Feed als Upstreamquelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl private als auch projektbezogene Feeds vor- und heraufführen können.

Erstellen Sie projektbezogene Feeds aus dem Portal

Wenn wir öffentliche Feeds veröffentlicht haben, haben wir auch projektbezogene Feedsveröffentlicht. Bisher konnten projektumfassende Feeds über REST-APIs erstellt oder durch Erstellen eines öffentlichen Feeds und anschließendes Umstellen des Projekts auf privat realisiert werden. Jetzt können Sie projektbezogene Feeds direkt im Portal aus einem beliebigen Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch sehen, welche Feeds auf Projekte und welche auf Sammlungen bezogen sind, in der Feed-Auswahl.

Npm-Leistungsverbesserungen

Wir haben Änderungen an unserem Kerndesign vorgenommen, um die Art und Weise zu verbessern, wie wir npm-Pakete in Azure Artifacts-Feeds speichern und bereitstellen. Dies hat uns geholfen, eine bis zu 10-fache Reduzierung der Latenz für einige der meistgenutzten APIs für npm zu erzielen.

Verbesserungen bei der Barrierefreiheit

Wir haben Korrekturen eingeführt, um Probleme mit der Zugänglichkeit auf unserer Feed-Seite zu beheben. Die Korrekturen umfassen Folgendes:

• Feed-Erlebnis erstellen
• Benutzeroberfläche für globale Feedeinstellungen
• Herstellen einer Verbindung mit feed-Erfahrung

Wiki

Umfangreiche Bearbeitung für Codewiki-Seiten

Zuvor wurden Sie beim Bearbeiten einer Codewiki-Seite zur Bearbeitung an den Azure Repos-Hub umgeleitet. Derzeit ist der Repo-Hub nicht für die Markdownbearbeitung optimiert.

Jetzt können Sie eine Codewiki-Seite im parallelen Editor innerhalb von Wiki bearbeiten. Auf diese Weise können Sie die Rich-Markdown-Symbolleiste verwenden, um Ihre Inhalte zu erstellen, sodass die Bearbeitungsoberfläche mit dem im Projektwiki identisch ist. Sie können weiterhin in Repos bearbeiten, indem Sie im Kontextmenü die Option In Repos bearbeiten auswählen.

Erstellen und Einbetten von Arbeitsaufgaben auf einer Wiki-Seite

Während wir Ihr Feedback gehört haben, haben wir gehört, dass Sie Wiki zum Erfassen von Brainstorming-Dokumenten, Planungsdokumenten, Ideen zu Features, Spezifikationsdokumenten, Besprechungsminuten verwenden. Jetzt können Sie Features und Benutzergeschichten ganz einfach direkt aus einem Planungsdokument erstellen, ohne die Wiki-Seite verlassen zu müssen.

Wenn Sie eine Arbeitsaufgabe erstellen möchten, wählen Sie den Text auf der Wiki-Seite aus, auf der Sie die Arbeitsaufgabe einbetten möchten, und wählen Sie Neue Arbeitsaufgabeaus. Dadurch sparen Sie Zeit, da Sie die Arbeitsaufgabe nicht zuerst erstellen müssen, wechseln Sie zu "Bearbeiten", und suchen Sie dann die Arbeitsaufgabe, um sie einzubetten. Außerdem wird der Kontextwechsel reduziert, da Sie den Wiki-Bereich nicht verlassen.

Weitere Informationen zum Erstellen und Einbetten einer Arbeitsaufgabe aus wiki finden Sie in unserer Dokumentation hier.

Kommentare auf Wiki-Seiten

Bisher haben Sie keine Möglichkeit, mit anderen Wiki-Benutzern innerhalb des Wikis zu interagieren. Dadurch wurde die Zusammenarbeit an Inhalten und das Beantworten von Fragen zu einer Herausforderung gemacht, da Unterhaltungen über E-Mail- oder Chatkanäle stattfinden mussten. Mit Kommentaren können Sie jetzt direkt innerhalb des Wikis mit anderen zusammenarbeiten. Sie können die @mention Benutzerfunktionen in Kommentaren nutzen, um die Aufmerksamkeit anderer Teammitglieder zu lenken. Dieses Feature wurde basierend auf dieses Vorschlagsticketpriorisiert. Weitere Informationen zu Kommentaren finden Sie in unserer Dokumentation hier.

Ausblenden von Ordnern und Dateien beginnend mit "." in Wiki-Baumstruktur

Bis jetzt zeigt die Wiki-Struktur alle Ordner und Dateien an, die mit einem Punkt (.) in der Wiki-Struktur beginnen. In Codewiki-Szenarien führte dies dazu, dass Ordner wie .vscode, die ausgeblendet werden sollen, in der Wiki-Struktur angezeigt werden. Jetzt bleiben alle Dateien und Ordner, die mit einem Punkt beginnen, in der Wiki-Struktur ausgeblendet, wodurch unnötiges Durcheinander reduziert wird.

Dieses Feature wurde basierend auf dieses Vorschlagsticketpriorisiert.

Kurze und lesbare Wiki-Seiten-URLs

Sie müssen keinen mehrzeiligen 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 einfacher zu lesen ist.

Die neue Struktur von 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 Willkommen bei Azure DevOps Wiki Seite:

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

Dies wurde basierend auf diesem Feature-Vorschlagsticket aus der Entwickler-Community priorisiert.

Synchroner Bildlauf beim Bearbeiten von Wiki-Seiten

Das Bearbeiten von Wiki-Seiten ist jetzt einfacher dank synchronem Bildlauf zwischen dem Editierbereich und dem Vorschaubereich. Beim Scrollen auf einer Seite wird automatisch auf der anderen Seite gescrollt, um die entsprechenden Abschnitte anzuzeigen. Sie können den synchronen Bildlauf mit der Umschaltfläche deaktivieren.

Anmerkung

Der Zustand der synchronen Bildlauf-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 in den letzten 30 Tagen auf die Seitenbesuchsinformationen 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 Einblicke wie am häufigsten angezeigten Seitenzu erhalten.

Außerdem wird eine Anzahl aggregierter Seitenbesuche für die letzten 30 Tage auf jeder Seite angezeigt.

Anmerkung

Ein Seitenbesuch wird als Seitenansicht durch einen bestimmten Benutzer in einem Intervall von 15 Minuten definiert.

Berichterstattung

Berichte zu Pipelinefehlern und Dauer

Metriken und Erkenntnisse helfen Ihnen dabei, 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 bieten.

1. Der Bericht über Pipelinefehler zeigt die Erfolgsrate der Builds und den Fehlertrend an. Darüber hinaus zeigt sie auch den Vorgangsfehlertrend an, um Erkenntnisse darüber zu liefern, welche Aufgabe in der Pipeline zur maximalen Anzahl von Fehlern beiträgt.

2. Der Bericht "Pipelinedauer" zeigt den Trend der Zeit, die für die Ausführung einer Pipeline erforderlich ist. Außerdem wird gezeigt, welche Vorgänge in der Pipeline die meiste Zeit in Anspruch nehmen.

Verbesserung des Abfrageergebnisse-Widgets

Das Abfrageergebnisse-Widget ist eines unserer beliebtesten Widgets und 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 aufgenommen:

• 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ößenvon 1x1 bis 10x10.
• Wenn Sie die Größe einer Spalte ändern, wird die Spaltenbreitegespeichert.
• Sie können das Widget auf die Vollbildansichterweitern. Wenn sie erweitert wird, werden alle Spalten angezeigt, die von der Abfrage zurückgegeben werden.

Filterungserweiterungen für Lead- und Zykluszeit-Widgets

Lead- und Zykluszeit werden von Teams verwendet, um zu sehen, wie lange es dauert, bis die Arbeit durch ihre Entwicklungspipeline fließt und letztendlich ihren Kunden Einen Mehrwert bietet.

Bis jetzt haben die Lead- und Zykluszeit-Widgets noch nicht erweiterte Filterkriterien unterstützt, um Fragen zu stellen wie: "Wie lange braucht mein Team, um Aufgaben mit höherer Priorität zu schließen?"

Mit diesem Update können Fragen wie diese durch Filtern in der Board-Swimlane beantwortet werden.

Darüber hinaus haben wir Arbeitsaufgabenfilter eingefügt, um die Arbeitsaufgaben zu begrenzen, die im Diagramm angezeigt werden.

Inline-Sprint-Burndown mithilfe von Story-Punkten

Ihr Sprint-Burndown kann jetzt nach Benutzerstories abgebaut werden. Dies adressiert Ihr Feedback aus der Developer Community.

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

1. Artikel-Backlog auswählen
2. Wählen Sie aus, um auf Summe von Story-Punkten abzubauen

Ein Sprint-Burndown-Widget mit allem, worum Sie gebeten haben

Das neue Sprint Burndown-Widget unterstützt den Abbau von Story Points, das Zählen von Aufgaben oder das Summieren benutzerdefinierter Felder. Sie können sogar einen Sprint-Burndown für Features oder Epics erstellen. Das Widget zeigt den durchschnittlichen Burndown, % vollständig und die 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 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 die Konfiguration für das vorhandene Sprint Burndown-Widget bearbeiten und das Kontrollkästchen Neue Version jetzt testen.

Anmerkung

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

Miniaturansicht des Inline-Sprint-Diagramms

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

Wenn Sie auf die Miniaturansicht klicken, wird sofort eine größere Version des Diagramms mit einer Option angezeigt, um den vollständigen Bericht auf der Registerkarte "Analyse" anzuzeigen. Alle Änderungen, die am vollständigen Bericht vorgenommen wurden, werden in dem diagramm widergespiegelt, das in der Kopfzeile angezeigt wird. Daher können Sie es jetzt so konfigurieren, dass der Burndown anhand von Stories, Storypunkten oder der Anzahl der Aufgaben erfolgt, anstatt nur basierend auf der verbleibenden Arbeitsmenge.

Erstellen eines Dashboards ohne Team

Sie können jetzt ein Dashboard erstellen, ohne es einem Team zuzuordnen. Wählen Sie beim Erstellen eines Dashboards den Projektdashboard- Typ aus.

Ein Projektdashboard ist wie ein Teamdashboard, mit der Ausnahme, dass es keinem Team zugeordnet ist, 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.

Anmerkung

Bei benutzerdefinierten oder Drittanbieter-Widgets übergibt ein Project-Dashboard den Kontext des Standardteams an diese Widgets. Wenn Sie über ein benutzerdefiniertes Widget verfügen, das auf Teamkontext basiert, sollten Sie die Konfiguration aktualisieren, damit Sie ein Team auswählen können.

---

Feedback

Wir würden uns freuen, von Ihnen zu hören! Sie können ein Problem melden oder eine Idee vorschlagen und es in der Developer Community- nachverfolgen sowie Ratschläge bei Stack Overflow-einholen.

---

Seitenanfang