Azure DevOps Server 2020 Versionshinweise

| 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 Anforderungen. 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 früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2019 durchführen. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps lokal.

---

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

Azure DevOps Server 2020 führt ein neues Pipelineausführungsmodell (Build)-Aufbewahrungsmodell ein, das auf Projektebeneneinstellungen basiert.

Azure DevOps Server 2020 behandelt die Buildaufbewahrung unterschiedlich, 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 von einer Version aufbewahrt wurden, werden nach dem Upgrade nicht gelöscht.

Lesen Sie unseren Blogbeitrag, um weitere Informationen zum sicheren Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020 zu erhalten.

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 der Identitätsauswahl des Sicherheitsdialogfelds angezeigt werden.
• Behebung eines Problems mit "Vom Mitglied des Gruppenfilters angefordert" in den Web-Hook-Einstellungen.
• Beheben Sie den Fehler "Gated Check-In-Builds", wenn die Organisationseinstellungen für Pipelines den Autorisierungsbereich für die Auftragsautorisierung auf das aktuelle Projekt für Nicht-Release-Pipelines konfiguriert haben.

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

Azure DevOps Server 2020.0.2 ist ein Rollup von Fehlerkorrekturen. 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.

Hinweis

Das Datenmigrationstool steht für Azure DevOps Server 2020.0.2 ungefähr drei Wochen nach dieser Version zur Verfügung. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Diese Version enthält Korrekturen für Folgendes:

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

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

Azure DevOps Server 2020.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.

• Email Benachrichtigungen wurden beim Verwenden des Steuerelements @mention in einem Arbeitselement nicht gesendet.
• Beheben Sie den TF400813-Fehler beim Wechseln von Konten. Dieser Fehler beim Upgrade von TFS 2018 auf Azure DevOps Server 2020.0.1.
• Behebung des Problems mit der Zusammenfassungsseite "Project Overview", die nicht geladen werden kann.
• Verbesserung der Active Directory-Benutzersynchronisierung.
• Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.

Installationsschritte

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

Hinweis

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

1. Aktualisieren Sie den Server mit Patch 9..
2. Überprüfen Sie den Registrierungswert unter HKLM:\Software\Elasticsearch\Version. Wenn der Registrierungswert nicht vorhanden ist, fügen Sie einen Zeichenfolgenwert hinzu, und legen Sie die Version auf 5.4.1 fest (Name = Version, Wert = 5.4.1).
3. Kopieren Sie den Inhalt des Ordners „zip“ unter C:\Program Files\{TFS Version Folder}\Search\zip in den Remotedateiordner von Elasticsearch.
4. Führen Sie Configure-TFSSearch.ps1 -Operation update auf dem Elasticsearch-Servercomputer aus.

SHA-256-Hash: B0C05A972C73F253154AEEB7605605EF2E596A96A96A96AE942D7A9DDD81545E

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 Arbeitsaufgabenlayoutzustände.
• 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".
• Problem mit dem Testplan-Widget beheben. Der Testausführungsbericht zeigt einen falschen Benutzer für Ergebnisse an.
• Behebung des Problems mit der Zusammenfassungsseite "Project Overview", die nicht geladen werden kann.
• Behebung des 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.

• Beheben des Download-/Uploadfehlers von Artefakten.
• Problem mit inkonsistenten Testergebnissen beheben.

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.

• Beheben sie den Fehler bei der Builddefinitions-UI.
• Der Browserverlauf wurde geändert, um Dateien anstelle des Stamm-Repositorys anzuzeigen.
• Problem mit E-Mail-Zustellungsaufträgen für einige Arbeitsaufgabentypen behoben.

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.

• Problem mit dem Datenimport beheben. Der Datenimport dauerte lange zeit 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 Datenimportprozess zu beschleunigen.

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

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

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

Wenn Sie Azure DevOps Server 2020.0.1 haben, sollten Sie Azure DevOps Server 2020.0.1 Patch 3 installieren.

Überprüfen der Installation

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

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

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

Hinweis

Wenn Sie Azure DevOps Server 2020 haben, 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 : Veröffentlichung von Informationen
• CVE-2021-28459: Rechteerweiterung

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

Allgemeine Patchinstallation

Wenn Sie Azure DevOps Server 2020.0.1 haben, sollten Sie Azure DevOps Server 2020.0.1 Patch 2 installieren.

Überprüfen der Installation

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

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

AzureResourceGroupDeploymentV2-Aufgabeninstallation

Hinweis

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

Installieren

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

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

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

AzureResourceManagerTemplateDeploymentV3-Taskinstallation

Hinweis

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

Installieren

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

2. Laden Sie Node.js 14.15.1 und npm (im Node.js Download enthalten) entsprechend ihren Computern herunter und installieren Sie sie.

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

npm install -g tfx-cli

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

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

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

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

• Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht
• Schließen Sie Korrekturen ein, die mit Azure DevOps Server 2020 Patch 2 verö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 Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht

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

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

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

• Beheben eines Upgradeproblems 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. Löst das in diesem Entwicklercommunity Feedbackticket gemeldete Problem aus.
• Wartungsfehler aufgrund fehlender Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Löst das in diesem Entwicklercommunity Feedbackticket gemeldete Problem aus.
• Fehler bei ungültigen Spaltennamen in Analytics beim Upgrade auf Azure DevOps Server 2020 beheben. Löst das in diesem Entwicklercommunity Feedbackticket gemeldete Problem aus.
• Gespeicherte XSS beim Anzeigen von Testfallschritten in Testfallergebnissen.
• Upgradeschrittfehler beim Migrieren von Punktergebnissen 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 enthaltene Builds werden nach der Migration zu Azure DevOps Server 2020 sofort gelöscht.
• Ausnahme des Datenanbieters beheben

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

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

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

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

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

Hinweis

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 auf 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 getroffen haben, indem Sie in <Install Dir>\Version Control Proxy\Web Services\binund <Install Dir>\Tools<Install Dir>\Application Tier\TFSJobAgent in Ordnern suchenMicrosoft.TeamFoundation.Git.dll. Wenn die Datei fehlt, können Sie eine Reparatur ausführen, um die fehlenden Dateien wiederherzustellen.

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

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

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

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

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

Nachdem Sie ein Upgrade von Azure DevOps Server 2019 Update 1.1 auf Azure DevOps Server 2020 RC1 durchgeführt haben, konnten Sie keine Dateien in der Benutzeroberfläche "Repos", "Pipelines" und "Wiki" anzeigen. Es wurde eine Fehlermeldung angezeigt, die angibt, dass ein unerwarteter Fehler innerhalb dieses Bereichs der Seite aufgetreten ist. Sie können versuchen, diese Komponente neu zu laden oder die gesamte Seite zu aktualisieren. Mit dieser Version haben wir dieses Problem behoben. Weitere Informationen finden Sie im Blogbeitrag.

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

Zusammenfassung der Neuerungen in Azure DevOps Server 2020

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

• Mehrstufige Pipelines
• Kontinuierliche Bereitstellung in YAML
• Nachverfolgen des Fortschritts von übergeordneten Elementen mithilfe des Rollups auf Boards-Backlog
• Hinzufügen des Filters "Übergeordnete Arbeitsaufgabe" zum Task board und sprint backlog
• Neue Web-Benutzeroberfläche für Azure Repos Zielseiten
• Domänenübergreifende Verzweigungsrichtlinienverwaltung
• Seite "Neuer Testplan"
• Umfassende 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:

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

---

Allgemein

Allgemeine Verfügbarkeit von Azure DevOps

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 dabei hilft, die Erweiterung zu verbessern und weitere Befehle hinzuzufügen. Wir freuen uns jetzt, bekannt zu geben, dass die Erweiterung allgemein verfügbar ist.

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

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

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

Boards

Hinzufügen des Filters "Übergeordnetes Arbeitselement" zur Taskboard- und Sprint-Backlog

Wir haben sowohl dem Sprintboard als auch dem Sprint-Backlog einen neuen Filter hinzugefügt. Dadurch können Sie Anforderungsrücklogelemente (erste Spalte links) nach ihrem übergeordneten Element filtern. Beispielsweise haben wir im folgenden Screenshot die Ansicht gefiltert, um nur Benutzergeschichten anzuzeigen, in denen das übergeordnete Element "Mein großes Feature" ist.

Verbessern der Fehlerbehandlungserfahrung – erforderliche Felder auf Fehler/Aufgabe

Im Verlauf des Kanban-Board, wenn Sie ein Arbeitselement von einer Spalte in eine andere verschoben haben, in der der Zustand ausgelöste Feldregeln geändert wird, zeigt die Karte nur eine rote Fehlermeldung an, die Sie dazu erzwingen, das Arbeitselement zu öffnen, um die Ursache zu verstehen. In Sprint 170 haben wir die Benutzeroberfläche verbessert, sodass Sie jetzt auf die rote Fehlermeldung klicken können, um die Details des Fehlers anzuzeigen, ohne das Arbeitselement selbst zu öffnen.

Arbeitselement live neu laden

Bei der Aktualisierung eines Arbeitselements und eines zweiten Teammitglieds wurden Änderungen an derselben Arbeitsaufgabe vorgenommen, würde der zweite Benutzer ihre Änderungen verlieren. Wenn Sie nun beide unterschiedliche Felder bearbeiten, werden Liveupdates der Änderungen angezeigt, die an das Arbeitselement vorgenommen wurden.

Verwalten von Iterations- und Bereichspfaden aus der Befehlszeile

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

Übergeordnete Arbeitselementspalte als Spaltenoption

Sie haben jetzt die Möglichkeit, das übergeordnete Element aller Arbeitselemente in Ihrem Produktbacklog oder Sprint-Backlog anzuzeigen. Um dieses Feature zu aktivieren, wechseln Sie zu Spaltenoptionen im gewünschten Backlog, und fügen Sie dann die übergeordnete Spalte hinzu.

Ändern des prozesses, der von einem Projekt verwendet wird

Ihre Tools sollten sich ändern, da Ihr Team es tut, können Sie jetzt Ihre Projekte von jeder out-of-the-box-Prozessvorlage auf einen beliebigen anderen out-of-the-box-Prozess umstellen. Sie können ihr Projekt z. B. mithilfe von Agile in Scrum oder Basic in Agile ändern. Hier finden Sie eine vollständige schrittweise Dokumentation.

Benutzerdefinierte Felder aus layout ausblenden

Sie können nun benutzerdefinierte Felder beim Anpassen des Prozesses aus dem Formularlayout ausblenden. Das Feld ist weiterhin über Abfragen und REST-APIs verfügbar. Dies ist praktisch, um zusätzliche Felder zu verfolgen, wenn Sie mit anderen Systemen integrieren.

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

Sie können nicht beheben, was Sie nicht sehen können. Daher möchten Sie den Zustand und die Gesundheit ihrer Arbeitsprozesse in enger Augen halten. 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 Geschwindigkeit. Sie können die Berichte auf der Registerkarte "Neue Analyse" sehen.

Metriken wie Sprint Burndown, Arbeitsfluss und Teamgeschwindigkeit bieten Ihnen die Sichtbarkeit des Fortschritts Ihres Teams und helfen Ihnen dabei, Fragen wie z. B. folgendes zu beantworten:

• Wie viel Arbeit haben wir in diesem Sprint verlassen? Sind wir auf dem Weg, es abzuschließen?
• Welche Schritte des Entwicklungsprozesses nehmen die längste Zeit? Können wir etwas tun?
• Basierend auf früheren Iterationen sollten wir für den nächsten Sprint planen?

Hinweis

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

Die neuen Berichte sind vollständig interaktiv und ermöglichen Es Ihnen, sie für Ihre Anforderungen anzupassen. Sie können die neuen Berichte auf der Registerkarte "Analyse " in jedem Hub finden.

• Das Burndown-Diagramm finden Sie unter dem Sprints-Hub .

  

• Die CFD- und Geschwindigkeitsberichte können auf der Registerkarte "Analyse " unter "Boards " und "Backlogs " zugegriffen werden, indem Sie auf die relevante Karte klicken.

  

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

• Der Sprint Burndown und die Geschwindigkeitsberichte können festgelegt werden, um die Anzahl der Arbeitselemente oder die Summe der verbleibenden Arbeit zu verwenden.
• Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne dass sich die Projekttermine auswirken. Wenn Ihr Team in der Regel den ersten Tag jeder Sprintplanung verbringt, können Sie nun mit dem Diagramm übereinstimmen, um das zu widerspiegeln.
• Das Burndown-Diagramm verfügt jetzt über ein Wasserzeichen mit Wochenenden.
• Mit dem CFD-Bericht können Sie Boardspalten wie Design entfernen, um mehr Fokus auf den Fluss zu erhalten, auf den die Teams Kontrolle haben.

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

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

Anpassen von Taskboardspalten

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

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

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

Umschalten zum Anzeigen oder Ausblenden abgeschlossener untergeordneter Arbeitselemente im Backlog

Häufig möchten Sie beim Verfeinern des Backlogs nur Elemente anzeigen, die nicht abgeschlossen wurden. Jetzt haben Sie die Möglichkeit, abgeschlossene untergeordnete Elemente im Backlog anzuzeigen oder auszublenden.

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

Die neuesten Tags, die beim Kennzeichnen einer Arbeitsaufgabe angezeigt werden

Wenn Sie eine Arbeitsaufgabe markieren, wird die Option für die automatische Fertigstellung jetzt bis zu fünf Ihrer zuletzt verwendeten Tags angezeigt. Dadurch wird es einfacher, die richtigen Informationen zu Ihren Arbeitselementen hinzuzufügen.

Schreibgeschützte und erforderliche Regeln für die Gruppenmitgliedschaft

Mithilfe von Arbeitselementregeln können Sie bestimmte Aktionen für Arbeitselementfelder festlegen, um ihr Verhalten zu automatisieren. Sie können eine Regel erstellen, um ein Feld auf schreibgeschützt oder erforderlich basierend auf der Gruppenmitgliedschaft festzulegen. Sie können beispielsweise Produktbesitzern die Möglichkeit gewähren, die Priorität Ihrer Features festzulegen, während sie für alle anderen Benutzer schreibgeschützt ist.

Anpassen von Systemauswahlwerten

Sie können jetzt die Werte für jede Systemauswahlliste (außer dem Grundfeld) anpassen, z. B. Schweregrad, Aktivität, Priorität usw. Die Auswahllistenanpassungen sind benutzerdefinierter Bereich, sodass Sie unterschiedliche Werte für dasselbe Feld für jeden Arbeitselementtyp verwalten können.

URL-Parameter für neue Arbeitsaufgabe

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

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

Erwähnen von Personen, Arbeitselementen und PRs in Textfeldern

Während wir Ihr Feedback hören, haben wir gehört, dass Sie die Möglichkeit haben, Personen, Arbeitsaufgaben und PRs im Arbeitsaufgabenbeschreibungsbereich (und andere HTML-Felder) für die Arbeitsaufgabe und nicht nur in Kommentaren zu erwähnen. Manchmal arbeiten Sie mit jemandem an einer Arbeitsaufgabe zusammen oder möchten eine PR in Ihrer Arbeitsaufgabenbeschreibung hervorheben, aber sie haben keine Möglichkeit, diese Informationen hinzuzufügen. Jetzt können Sie Personen, Arbeitselemente und PRs in allen langen Textfeldern für die Arbeitsaufgabe erwähnen.

Hier sehen Sie ein Beispiel.

• Geben Sie zum Verwenden von Personen erwähnungen das @ Zeichen und den Namen der Person ein, die Sie erwähnen möchten. @mentions in Arbeitsaufgabenfeldern werden E-Mail-Benachrichtigungen wie für Kommentare generiert.
• Geben Sie das # Zeichen gefolgt von der Arbeitselement-ID oder dem Titel ein, um Arbeitsaufgaben-Erwähnungen zu verwenden. #mentions erstellt einen Link zwischen den beiden Arbeitselementen.
• Um PR-Erwähnungen zu verwenden, fügen Sie eine ! gefolgt von Ihrer PR-ID oder Ihrem Namen hinzu.

Reaktionen auf Diskussionskommentare

Eines unserer Hauptziele besteht darin, die Arbeitsaufgaben für Teams besser zusammenarbeiten zu lassen. Kürzlich haben wir eine Umfrage auf Twitter durchgeführt, um herauszufinden, welche Funktionen für die Zusammenarbeit Sie in Diskussionen über die Arbeitsaufgabe wünschen. Die Reaktion auf Kommentare hat die Umfrage gewonnen, so dass wir sie hinzufügen! Hier sind die Ergebnisse der Twitter-Umfrage.

Sie können Reaktionen auf jeden 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 allen 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 sehen, wie eine Reaktion hinzugefügt wird, sowie wie die Reaktionen auf einen Kommentar aussehen.

Anheften Azure Boards Berichte an das Dashboard

Im Sprint 155 Update haben wir aktualisierte Versionen der CFD- und Geschwindigkeitsberichte aufgenommen. 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 auf den Bericht, wählen Sie die Auslassungspunkte "..." aus. menü, und Kopieren in Dashboard.

Nachverfolgen des Fortschritts von übergeordneten Elementen mithilfe des Rollups auf Boards-Backlog

Rollupspalten zeigen Statusindikatoren und/oder Summen numerischer Felder oder absteigender Elemente in einer Hierarchie an. Absteigende Elemente entsprechen allen untergeordneten Elementen in der Hierarchie. Mindestens eine Rollupspalte kann einem Produkt- oder Portfolio-Backlog hinzugefügt werden.

Hier zeigen wir beispielsweise Den Fortschritt nach Arbeitselementen an, die Statusindikatoren für aufsteigende Arbeitselemente basierend auf dem Prozentsatz der absteigenden Elemente anzeigen, die geschlossen wurden. Absteigende Elemente für Epics umfassen alle untergeordneten Features und deren untergeordnete oder untergeordnete Arbeitselemente. Absteigende Elemente für Features umfassen alle untergeordneten Benutzergeschichten und ihre untergeordneten Arbeitselemente.

Liveupdates des 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 nicht mehr F5 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 Feldprozessvorlage sind, können Sie ihre eigene wie folgt konfigurieren:

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

   

2. Wählen Sie zwischen Statusleiste und Summe aus.
3. Wählen Sie einen Arbeitselementtyp oder eine Backlog-Ebene aus (in der Regel werden mehrere Arbeitsaufgabentypen aggregiert).
4. Wählen Sie den Aggregationstyp aus. Anzahl der Arbeitselemente oder Summen. Für Summe müssen Sie das Feld auswählen, das zusammengefasst werden soll.
5. Die Schaltfläche 'OK ' bringt Sie zurück zum Spaltenoptionenbereich, in dem Sie Ihre neue benutzerdefinierte Spalte neu anordnen können.

Beachten Sie, dass Sie Ihre benutzerdefinierte Spalte nach dem Klicken auf "OK" nicht bearbeiten können. 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 Arbeitselementformular 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.

Einstellungen für benutzerdefinierte Arbeitsaufgabenbenachrichtigungen

Es ist unglaublich wichtig, auf dem neuesten Stand zu arbeitsrelevanten Arbeitselementen für Sie oder Ihr Team zu bleiben. Es hilft Teams, mit Projekten zusammenzuarbeiten und auf dem Weg zu bleiben und sicherzustellen, dass alle richtigen Parteien beteiligt sind. Unterschiedliche Stakeholder haben jedoch unterschiedliche Investitionen in unterschiedliche Bemühungen, und wir glauben, dass sie sich in Ihrer Fähigkeit widerspiegeln sollten, den Status eines Arbeitselements zu verfolgen.

Wenn Sie zuvor einem Arbeitselement folgen und Benachrichtigungen zu änderungen erhalten möchten, erhalten Sie E-Mail-Benachrichtigungen für alle Änderungen, die an der Arbeitsaufgabe vorgenommen wurden. Nach der Prüfung Ihres Feedbacks machen wir ein Arbeitselement flexibler für alle Beteiligten. Nun wird neben der Schaltfläche " Folgen " in der oberen rechten Ecke der Arbeitsaufgabe eine neue Einstellungsschaltfläche angezeigt. Dadurch gelangen Sie zu einem Popup, mit dem Sie Die folgenden Optionen konfigurieren können.

In den Benachrichtigungseinstellungen können Sie aus drei Benachrichtigungsoptionen auswählen. Zunächst können Sie vollständig abgemeldet werden. Zweitens können Sie vollständig abonniert werden, wo Sie Benachrichtigungen für alle Änderungen der Arbeitsaufgabe erhalten. Schließlich können Sie auswählen, dass Sie für einige der wichtigsten Änderungen der Arbeitsaufgabe benachrichtigt werden. Sie können nur eine oder alle drei Optionen auswählen. Dadurch können Teammitglieder Arbeitsaufgaben auf höherer Ebene verfolgen und nicht von jeder einzelnen Änderung ablenken, die vorgenommen wird. Mit diesem Feature vermeiden wir unnötige E-Mails und ermöglichen Es Ihnen, sich auf die wichtigen Aufgaben zu konzentrieren.

Verknüpfen von Arbeitselementen mit Bereitstellungen

Wir freuen uns, die Bereitstellungssteuerung für das Arbeitselementformular freizugeben. Dieses Steuerelement verknüpft Ihre Arbeitselemente mit einer Version und ermöglicht es Ihnen, ganz einfach nachzuverfolgen, wo Ihre Arbeitsaufgabe bereitgestellt wurde. Weitere Informationen finden Sie hier in der Dokumentation.

Importieren von Arbeitselementen aus einer CSV-Datei

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

Hinzufügen eines übergeordneten Felds zu Arbeitselementkarten

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

Hinzufügen eines übergeordneten Felds zum Backlog und Abfragen

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

Repos

Codeabdeckungsmetriken und Verzweigungsrichtlinie für Pullanforderungen

Sie können jetzt Codeabdeckungsmetriken für Änderungen in der Pull-Anforderungsansicht (PR) anzeigen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen über automatisierte Tests angemessen getestet haben. Der Abdeckungsstatus wird in der PR-Übersicht als Kommentar 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 Repobesitzer jetzt Codeabdeckungsrichtlinien festlegen und verhindern, dass große, nicht getestete Änderungen in eine Verzweigung zusammengeführt werden. Die gewünschten Abdeckungsschwellenwerte können in einer azurepipelines-coverage.yml Einstellungsdatei definiert werden, die im Stammverzeichnis des Repositorys und der Abdeckungsrichtlinie eingecheckt ist, mithilfe der vorhandenen Konfiguration einer Verzweigungsrichtlinie für zusätzliche Dienste in Azure Repos definiert werden.

Filtern von Kommentarbenachrichtigungen aus Pullanforderungen

Kommentare in Pullanforderungen können häufig aufgrund von Benachrichtigungen viel Rauschen generieren. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie nach Kommentaralter, Kommentarer, gelöschtem Kommentar, erwähnten Benutzern, Pullanforderungsautor, Zielzweig und Threadteilnehmern abonnieren. Sie können diese Benachrichtigungsabonnements erstellen, indem Sie auf das Benutzersymbol in der oberen rechten Ecke klicken und zu den Benutzereinstellungen navigieren.

Diensthaken für Pullanforderungskommentare

Sie können jetzt Dienst-Hooks für Kommentare in einer Pullanforderung 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 auf ein Repository basierend auf Dateitypen und Pfaden übertragen werden. Die Dateinamenüberprüfungsrichtlinie blockiert Pushs, die dem bereitgestellten Muster entsprechen.

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

Sie können nun Arbeitsaufgaben über Commits auflösen, die an die Standardverzweigung vorgenommen wurden, indem Sie Schlüsselwörter wie Fix, Korrekturen oder Feste verwenden. Sie können z. B. schreiben - "diese Änderung behoben #476" in Ihrer Commitnachricht und Arbeitsaufgabe #476 wird abgeschlossen, wenn der Commit pusht oder in die Standardverzweigung zusammengeführt wird. Weitere Details finden Sie in der Dokumentation hier.

Granularität für automatische Prüfer

Zuvor wurde beim Hinzufügen von Prüfern auf Gruppenebene zu einer Pullanforderung nur eine Genehmigung aus der Gruppe benötigt, die hinzugefügt wurde. Jetzt können Sie Richtlinien festlegen, die mehr als einen Prüfer aus einem Team erfordern, um eine Pullanforderung zu genehmigen, wenn automatische Prüfer hinzugefügt werden. Darüber hinaus können Sie eine Richtlinie hinzufügen, um die Genehmigung ihrer eigenen Änderungen zu verhindern.

Verwenden der dienstkontobasierten Authentifizierung zum Herstellen einer Verbindung mit AKS

Zuvor haben wir beim Konfigurieren von Azure-Pipelines aus dem AKS Deployment Center eine Azure Resource Manager Connection 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, damit sie nur Zugriff auf den Namespace hat, der der Pipeline zugeordnet ist.

Vorschau von Markdown-Dateien in Pullanforderung parallelen Diff

Sie können nun eine Vorschau anzeigen, wie eine Markdowndatei mithilfe der neuen Schaltfläche "Vorschau " aussehen wird. Darüber hinaus können Sie den vollständigen Inhalt einer Datei aus dem querseitigen Diff anzeigen, indem Sie die Schaltfläche "Ansicht " auswählen.

Ablauf der Buildrichtlinie für manuelle Builds

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

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

Administratoren können nun eine Pushrichtlinie festlegen, um zu verhindern, dass Commits an ein Repository übertragen werden, für das die E-Mail des Commitautors nicht mit dem bereitgestellten Muster übereinstimmt.

Dieses Feature wurde basierend auf einem Vorschlag der Entwicklercommunity priorisiert, um eine ähnliche Erfahrung zu liefern. Wir werden weiterhin das Ticket 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 als überprüft in einer Pullanforderung markieren.

Sie können eine Datei mithilfe des Dropdownmenüs neben einem Dateinamen markieren oder auf den Dateinamen zeigen und auf den Dateinamen klicken.

Hinweis

Dieses Feature soll nur den Fortschritt nachverfolgen, während Sie eine Pullanforderung überprüfen. Es stellt keine Abstimmung über Pullanfragen dar, sodass diese Markierungen nur für den Prüfer sichtbar sind.

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

Neue Web-Ui für Azure Repos Startseiten

Sie können jetzt unsere neuen modernen, schnellen und mobilen Startseiten in Azure Repos ausprobieren. Diese Seiten sind als Neue Repos-Startseiten verfügbar. Zielseiten enthalten alle Seiten mit Ausnahme von Pullanforderungsdetails, Commitdetails und Verzweigungsvergleich.

Web

Mobil

Domänenübergreifende Verzweigungsrichtlinienverwaltung

Verzweigungsrichtlinien sind eine 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 keine Benutzeroberfläche dafür. Jetzt können Administratoren Richtlinien für eine bestimmte Verzweigung oder die Standardverzweigung für alle Repositorys in ihrem Projekt festlegen. Beispielsweise könnte ein Administrator zwei Mindestprüfer für alle Pullanforderungen erfordern, die in jedem Hauptzweig in jedem Repository in ihrem Projekt vorgenommen wurden. Sie finden das Feature " Verzweigungsschutz hinzufügen " in den Einstellungen für Repos-Projekt.

Neue Webplattform-Konvertierungs-Landingpages

Wir haben die Benutzeroberfläche von Repos-Startseiten aktualisiert, um es modern, schnell und mobil zu gestalten. Hier sind zwei Beispiele für die Seiten, die aktualisiert wurden, wir werden weitere Seiten in zukünftigen Updates aktualisieren.

Weberfahrung:

Mobile Erfahrung:

Unterstützung für Die Sprache Kotlin

Wir freuen uns, bekanntzugeben, dass wir jetzt Kotlin-Sprachmarkierung im Datei-Editor unterstützen. Die Hervorhebung verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen dabei, schnell nach Fehlern zu suchen. Wir haben dieses Feature basierend auf einem Vorschlag aus dem Entwicklercommunity priorisiert.

Benutzerdefiniertes Benachrichtigungsabonnement für Entwürfe von Pullanforderungen

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

Verbesserte PR-Aktionsfähigkeit

Wenn Sie viele Pull-Anforderungen zum Überprüfen haben, können Sie wissen, wo Sie zuerst Maßnahmen ergreifen sollten, schwierig sein. Um die Aktionsfähigkeit der Pull-Anforderung zu verbessern, können Sie jetzt mehrere benutzerdefinierte Abfragen auf der Pull-Anforderungsliste mit mehreren neuen Optionen erstellen, die gefiltert werden können, z. B. Entwurfszustand. Diese Abfragen erstellen separate und kollapsible Abschnitte auf Ihrer Pull-Anforderungsseite zusätzlich zu "Erstellt von mir" und "Zugewiesen für mich". Sie können auch ablehnen, eine Pullanfrage zu überprüfen, der Sie über das Abstimmungsmenü oder das Kontextmenü auf der Pull-Anforderungsliste hinzugefügt wurden. In den benutzerdefinierten Abschnitten werden jetzt separate Registerkarten für Pullanforderungen angezeigt, die Sie eine Überprüfung bereitgestellt oder abgelehnt haben. Diese benutzerdefinierten Abfragen funktionieren über Repositorys auf der Registerkarte "Meine Pullanforderungen" der Startseite der Auflistung. Wenn Sie zu einer Pullanfrage zurückkehren möchten, können Sie sie kennzeichnen und sie oben in Der Liste angezeigt. Schließlich werden Pull-Anforderungen, die auf automatisch abgeschlossen festgelegt wurden, mit einer Pille gekennzeichnet, die "Automatisch abgeschlossen" in der Liste sagt.

Pipelines

Mehrstufige Pipelines

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Pipelines zu verwalten. Diese Updates machen die Pipelines modern und konsistent mit der Richtung von Azure DevOps. Darüber hinaus bringen diese Updates klassische Buildpipelinen und mehrstufige YAML-Pipelines in eine einzige Erfahrung zusammen. Es ist mobil freundlich und bringt verschiedene Verbesserungen dazu, wie Sie Ihre Pipelines verwalten. Sie können Details zur Pipeline ausführen, Details, Pipelineanalysen, Auftragsdetails, Protokolle und vieles mehr ausführen.

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

• Anzeigen und Verwalten mehrerer Phasen
• Ausführen der Genehmigungspipeline
• Scrollen Sie zurück in Protokollen, während eine Pipeline noch in Bearbeitung ist
• Per-Branch-Integrität 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 ausgeführt werden. YAML CD-Features führen mehrere neue erweiterte Features ein, die für alle Sammlungen mit mehrstufigen YAML-Pipelines verfügbar sind. Einige der Highlights sind unter anderem:

• Mehrstufige YAML-Pipelines (für CI und CD)
• Genehmigungen und Überprüfungen von Ressourcen
• Umgebungen und Bereitstellungsstrategien
• Kubernetes und Virtuelle Computerressourcen 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, lesen Sie die Dokumentation oder den Blog zum Erstellen von MEHRstufigen CI/CD-Pipelines.

Verwalten von Pipelinevariablen im YAML-Editor

Wir haben die Erfahrung zum Verwalten 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 aus dem Release-Hub

Das Handeln auf ausstehende Genehmigungen wurde einfacher gemacht. Zuvor war es möglich, eine Version auf der Detailseite der Version zu genehmigen. Sie können jetzt Versionen direkt über den Release-Hub genehmigen.

Verbesserungen bei den ersten Schritten mit Pipelines

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

Schließlich haben wir mehr Kontrolle beim Einchecken in die azure-pipelines.yml Datei auf einen anderen Zweig, da Sie das Erstellen einer Pullanforderung aus diesem Zweig überspringen können.

Vorschau vollständig analysiertes YAML-Dokument ohne Festlegen oder Ausführen der Pipeline

Wir haben eine Vorschau hinzugefügt , aber nicht den Modus für YAML-Pipelines ausgeführt. Jetzt können Sie eine YAML-Pipeline ausprobieren, ohne sie zu einem Repo zu verpflichten oder es auszuführen. Angesichts einer vorhandenen Pipeline und einer optionalen neuen YAML-Nutzlast erhalten Sie diese neue API die vollständige YAML-Pipeline zurück. In zukünftigen Updates wird diese API in einem neuen Editorfeature verwendet.

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

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

Die Antwort enthält die gerenderte YAML.

Cron-Terminpläne in YAML

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

1. Config as code: You can track the schedules with your pipeline as part of code.
2. Ausdrucksfähig: Sie haben mehr Ausdrucksfähigkeit beim Definieren von Terminplänen als das, was Sie mit der Benutzeroberfläche haben können. Beispielsweise ist es einfacher, einen einzelnen Zeitplan anzugeben, der jede Stunde eine Ausführung startet.
3. Branchenstandard: Viele Entwickler und Administratoren sind bereits mit der Cronsyntax 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-Terminplänen zu diagnostizieren. Die geplante Ausführung im Menü "Pipeline ausführen" gibt Ihnen eine Vorschau auf die bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Ihnen bei der Diagnose von Fehlern mit Ihren Cron-Terminplänen zu helfen.

Aktualisierungen der Benutzeroberfläche für Dienstverbindungen

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

Zusammen mit der Aktualisierung der Benutzeroberfläche haben wir auch zwei Funktionen hinzugefügt, die für die Verwendung von Serviceverbindungen in YAML-Pipelines wichtig sind: Pipelineberechtigungen und Genehmigungen und Überprüfungen.

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

Hinweis

Wir planen, die gemeinsame Freigabe von Dienstverbindungen als neue Funktion einzuführen. Weitere Details zu der Freigabeerfahrung und den Sicherheitsrollen finden Sie hier.

Überspringen von Phasen in einer YAML-Pipeline

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

Der aktualisierte Ausführungspipelinebereich stellt eine Liste der Phasen aus der YAML-Datei dar, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Sie müssen beim Überspringen von Phasen Vorsicht üben. Wenn Ihre erste Phase beispielsweise bestimmte Artefakte erzeugt, die für nachfolgende Phasen benötigt werden, sollten Sie die erste Phase nicht überspringen. Im Ausführungsbereich wird eine generische Warnung angezeigt, wenn Sie Phasen überspringen, die nachgelagerte Abhängigkeiten aufweisen. Es ist ihnen überlassen, ob diese Abhängigkeiten echte Artefakteabhängigkeiten sind oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.

Das Überspringen einer Phase entspricht der Neuverkabelung der Abhängigkeiten zwischen Phasen. Alle unmittelbar nachgelagerten Abhängigkeiten der übersprungenen Phase sind abhängig von dem vorgeschalteten übergeordneten Element der übersprungenen Phase. Wenn die Ausführung fehlschlägt, und wenn Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, weist dieser Versuch auch das gleiche Absprungverhalten auf. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.

Dienstverbindungen neue Benutzeroberfläche als Standardumgebung

Es gibt eine neue Benutzeroberfläche für Dienstverbindungen. Diese neue Benutzeroberfläche basiert auf modernen Entwurfsstandards und bietet verschiedene kritische Features, um mehrstufige YAML-CD-Pipelines wie Genehmigungen, Autorisierungen und projektübergreifende Freigabe zu unterstützen.

Weitere Informationen zu Dienstverbindungen finden Sie hier.

Pipeline-Ressourcenversionsauswahl im Dialogfeld "Ausführen"

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

az CLI-Verbesserungen für Azure-Pipelines

Befehle für die Pipelinevariablengruppe und variable Verwaltung

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 Befehlen zur Variablenverwaltung der Pipelinevariablen und Variablenverwaltung können Sie nun die Einrichtung und Verwaltung von Pipelinevariablen und Variablengruppen ausführen, die wiederum versionsgesteuert werden können, sodass Sie die Anweisungen einfach freigeben können, um Pipelines von einem Projekt zu einem anderen zu verschieben und einzurichten.

Ausführen der Pipeline für eine PR-Verzweigung

Beim Erstellen einer PR kann es schwierig sein, zu überprüfen, ob die Änderungen die Pipeline unterbrechen können, die auf dem Zielzweig ausgeführt wird. Mit der Funktion zum Auslösen einer Pipelineausführung oder Warteschlange eines Builds für einen PR-Zweig können Sie die Änderungen jetzt überprüfen und visualisieren, indem Sie sie gegen die Zielpipeline ausführen. Weitere Informationen finden Sie in az-Pipelines, die ausgeführt werden und az-Pipelines erstellen .

Überspringen der ersten Pipelineausführung

Beim Erstellen von Pipelines möchten Sie manchmal eine YAML-Datei erstellen und festlegen und die Pipeline nicht auslösen, da es aufgrund einer Vielzahl von Gründen zu einer fehlerhaften Ausführung führen kann - Infrastruktur ist nicht bereit oder muss variable/variable Gruppen usw. erstellen und aktualisieren. Mit Azure DevOps CLI können Sie jetzt die erste automatisierte Pipeline überspringen, die auf dem Erstellen einer Pipeline ausgeführt wird, indem Sie den Parameter "-skip-first-run" einschließen. Weitere Informationen finden Sie in der Az-Pipeline zum Erstellen von Befehlsdokumentationen .

Verbesserung des Dienstendpunktbefehls

Dienstendpunkt-CLI-Befehle unterstützt nur azure rm und github-Dienstendpunkt einrichten und verwalten. Mit dieser Version können Sie jedoch alle Dienstendpunkte erstellen, indem Sie die Konfiguration über die Datei bereitstellen und optimierte Befehle bereitstellen – az devops service-endpoint github und az devops service-endpoint azurerm, die unterstützung für das Erstellen von Dienstendpunkten dieser Typen bieten. Weitere Informationen finden Sie in der Befehlsdokumentation .

Bereitstellungsaufträge

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

Wir haben auch Unterstützung für zusätzliche Eigenschaften zum Bereitstellungsauftrag 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 der Auftrag automatisch abgebrochen wird
• cancelTimeoutInMinutes – wie viel Zeit zum "Ausführen immer, wenn abgebrochene Vorgänge" ausgeführt werden soll, bevor sie beendet werden
• Bedingung - Ausführen des Auftrags bedingt
• Variablen - Hardcoded-Werte können direkt oder variable Gruppen hinzugefügt werden, variable Gruppe, die von einem Azure-Schlüsseltresor unterstützt wird, oder Sie können auf eine Reihe von Variablen verweisen, die in einer Datei definiert sind.
• continueOnError – wenn zukünftige Aufträge auch dann ausgeführt werden sollten, wenn dieser Bereitstellungsauftrag fehlschlägt; Standardwerte für "false"

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

Anzeigen von Informationen zu zugeordneten CD-Pipelines in CI-Pipelines

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

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

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

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

Hinweis

Heute unterstützt GitHub-Pakete nur PAT-basierte Authentifizierung, was bedeutet, dass die GitHub-Dienstverbindung in der Paketressource vom Typ PAT sein sollte. Sobald diese Einschränkung aufgehoben wurde, unterstützen wir andere Authentifizierungstypen.

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

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

Azure Kubernetes Service Clusterlink in Kubernetes-Ressourcenansicht

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

Freigeben von Ordnerfiltern in Benachrichtigungsabonnements

Ordner ermöglichen das Organisieren von Pipelines für einfachere Erkennung und Sicherheitssteuerung. Häufig möchten Sie benutzerdefinierte E-Mail-Benachrichtigungen für alle Releasepipelinen konfigurieren, die von allen Pipelines unter einem Ordner dargestellt werden. Zuvor mussten Sie mehrere Abonnements konfigurieren oder komplexe Abfrage in den Abonnements haben, um fokussierte E-Mails abzurufen. Mit diesem Update können Sie nun eine Releaseordnerklausel zur abgeschlossenen Und Genehmigung ausstehender Ereignisse hinzufügen und die Abonnements vereinfachen.

Verknüpfen von Arbeitselementen mit mehrstufigen YAML-Pipelines

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

Abbrechen der Phase in einer mehrstufigen YAML-Pipeline

Wenn Sie eine YAML-Pipeline in mehreren Phasen ausführen, können Sie die Ausführung einer Phase jetzt 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.

Fehler beim Wiederholen von Phasen

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

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

Dies kann Ihnen helfen, Zeit auf verschiedene Arten zu sparen. Wenn Sie beispielsweise mehrere Aufträge in einer Phase ausführen, möchten Sie möglicherweise jede Phase Tests auf einer anderen Plattform ausführen. Wenn die Tests auf einer Plattform fehlschlagen, während andere übergeben werden, können Sie Zeit sparen, indem Sie die ausgeführten Aufträge nicht erneut ausführen. Ein weiteres Beispiel ist möglicherweise aufgrund einer flakigen Netzwerkverbindung fehlgeschlagen. Wenn Sie diese Phase wiederholen, können Sie Zeit sparen, indem Sie keinen anderen Build erstellen müssen.

Es gibt einige bekannte Lücken in diesem Feature. Sie können beispielsweise 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 Genehmigungen enthalten. Infrastrukturbesitzer können ihre Umgebungen schützen und manuelle Genehmigungen vor einer Phase in jeder Pipeline durchführen, die sie bereitstellen. Mit vollständiger Trennung von Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie sicher, dass die bereitstellung in einer bestimmten Pipeline manuell abgemeldet wird und die zentrale Kontrolle über die Anwendung der gleichen Prüfungen auf alle Bereitstellungen auf die Umgebung verfügt.

Die Pipeline führt die Bereitstellung in Dev aus, um die Genehmigung am Anfang der Phase zu beenden.

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

Zuvor waren die Timeoutlimits für die Veröffentlichungspipeline drei Tage. Mit diesem Update wurde das Timeoutlimit auf 15 Tage erhöht, um Gates mit längeren Daueren zuzulassen. Wir haben auch die Häufigkeit des Tors auf 30 Minuten erhöht.

Neue Buildimagevorlage für Dockerfile

Beim Erstellen einer neuen Pipeline für eine Dockerfile-Datei in der neuen Pipelineerstellung empfiehlt sich die Vorlage, das Image an eine Azure Container Registry zu verschieben und in eine Azure Kubernetes Service bereitzustellen. Wir haben eine neue Vorlage hinzugefügt, mit der Sie ein Image mithilfe des Agents erstellen können, ohne dass Sie an eine Containerregistrierung pushen müssen.

Neue Aufgabe zum Konfigurieren Azure App Service App-Einstellungen

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

Azure App Service unterstützt jetzt "Swap with preview"

Azure App Service unterstützt jetzt swap with preview on its deployment slots. Dies ist eine gute Möglichkeit, die App mit Produktionskonfiguration zu überprüfen, bevor die App tatsächlich von einem Staging-Slot in einen Produktionsplatz ausgetauscht wird. Dies würde auch sicherstellen, dass der Ziel-/Produktionsplatz keine Ausfallzeiten erlebt.

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

• Start Swap with Preview – Initiiert einen Swap mit einer Vorschau (Multi-Phase Swap) und wendet Zielplatz (z. B. die Produktionsplatzkonfiguration) auf den Quellplatz an.
• Vollständiges Swap with Preview – Wenn Sie bereit sind, den ausstehenden Swap abzuschließen, wählen Sie die Aktion "Fertiger Swap mit Vorschau" aus.
• Abbrechen des Swaps mit Vorschau – Um einen ausstehenden Swap abzubrechen, wählen Sie "Swap mit Vorschau abbrechen" aus.

Stufenebenenfilter 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 Versionspipelineebene verfügbar. Sie wurden nun auch auf Stufe ebene hinzugefügt.

Verbesserungen an Genehmigungen in YAML-Pipelines

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

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

Unterstützung für Containerstrukturtests in Azure Pipelines

Die Nutzung von Containern in Anwendungen wird erhöht und somit der Bedarf an robusten Tests und Überprüfungen. 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 Entscheidungen zu treffen. Testdaten stehen in der Pipeline mit einer Fehlermeldung zur Verfügung, um Ihnen bei der verbesserung der Problembehandlung zu helfen.

Geben Sie die Konfigurationsdatei und Bilddetails ein.

Testdaten und Zusammenfassung

Pipelinedekortoren für Releasepipelinen

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

Wir unterstützen Dekoratoren für Builds und YAML-Pipelines mit Kunden, mit denen sie die Schritte in ihren Aufträgen zentral steuern können. Wir erweitern nun auch die Unterstützung für Releasepipelinen. Sie können Erweiterungen erstellen, um Schritte für den neuen Beitragspunkt hinzuzufügen, und sie werden allen Agentaufträgen in Release-Pipelines hinzugefügt.

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

Zuvor unterstützten wir Bereitstellungen nur auf Ressourcengruppenebene. Mit diesem Update haben wir Unterstützung hinzugefügt, um ARM-Vorlagen sowohl auf abonnement- als auch auf Verwaltungsgruppenebene bereitzustellen. Dies hilft Ihnen beim Bereitstellen einer Gruppe von Ressourcen zusammen, platzieren sie jedoch in verschiedenen Ressourcengruppen oder Abonnements. Bereitstellen des virtuellen Sicherungscomputers für Azure Site Recovery beispielsweise für eine separate Ressourcengruppe und einen separaten Speicherort.

CD-Funktionen für Ihre mehrstufigen YAML-Pipelines

Sie können jetzt Artefakte nutzen, die von Ihrer CI-Pipeline veröffentlicht werden und Pipeline-Abschlussauslöser aktivieren. In mehrstufigen YAML-Pipelines werden wir als Ressource eingeführt pipelines . In Ihrem YAML können Sie jetzt auf eine andere Pipeline verweisen und auch CD-Trigger aktivieren.

Nachfolgend finden Sie das detaillierte YAML-Schema für Pipelines-Ressourcen.

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

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

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

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

Orchestrate canary deployment strategy on environment for Kubernetes

Einer der wichtigsten Vorteile der kontinuierlichen Übermittlung von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu verschieben. Dadurch können Sie schnell auf Änderungen in geschäftsspezifischen Anforderungen reagieren. Die Umgebung wurde als erstklassiges Konzept eingeführt, das die Orchestrierung von Bereitstellungsstrategien ermöglicht und Veröffentlichungen ohne Ausfallzeiten erleichtert. Zuvor haben wir die RunOnce-Strategie unterstützt, die die Schritte einmal sequenziell ausgeführt hat. Mit Unterstützung für die Kanarische Strategie in mehrstufigen Pipelines können Sie nun das Risiko verringern, indem Sie die Änderung langsam in eine kleine Teilmenge einführen. Wenn Sie mehr Vertrauen in die neue Version erhalten, können Sie mit der Einführung in weitere Server in Ihrer Infrastruktur beginnen und weitere Benutzer an sie weiterleiten.

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 Kanarische Strategie für Kuberenetes wird zuerst die Änderungen mit 10 % Pods bereitstellen, gefolgt von 20 % während der Überwachung der Gesundheit während postRouteTraffic. Wenn alles gut geht, wird es auf 100 % gefördert.

Wir suchen nach frühem Feedback zur Unterstützung der VM-Ressource in Umgebungen und führen eine Rollenbereitstellungsstrategie für mehrere Computer aus. Wenden Sie sich an uns , um sich anzumelden.

Genehmigungsrichtlinien für YAML-Pipelines

In YAML-Pipelines folgen wir einer ressourcenbesitzergesteuerten Genehmigungskonfiguration. Ressourcenbesitzer konfigurieren Genehmigungen für die Ressource und alle Pipelines, die die Ressource für Genehmigungen verwenden, bevor der Beginn der Phase, in der die Ressource verwendet wird, verwendet wird. Es ist üblich, dass SOX-basierte Anwendungsbesitzer die Anforderung der Bereitstellung einschränken, ihre eigenen Bereitstellungen zu genehmigen.

Sie können jetzt erweiterte Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien wie Anforderungsgeber nicht genehmigen zu können, eine Genehmigung aus einer Teilmenge von Benutzern und Genehmigungstimeout erforderlich.

ACR als erstklassige Pipelineressource

Wenn Sie ein Containerimage verwenden müssen, das in ACR (Azure Container Registry) als Teil Ihrer Pipeline veröffentlicht wird und Ihre Pipeline ausgelöst werden muss, wenn ein neues Bild veröffentlicht wurde, können Sie die ACR-Containerressource verwenden.

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

Darüber hinaus kann auf ACR-Bildmetadaten mit vordefinierten Variablen zugegriffen werden. Die folgende Liste enthält die verfügbaren ACR-Variablen, um eine ACR-Containerressource in Ihrer Pipeline zu definieren.

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

Verbesserungen zum Bewerten von Artefakten überprüft die Richtlinie in Pipelines

Wir haben die Bewertungsartefakteüberprüfung erweitert, um Richtlinien aus einer Liste von außerhalb der Feldrichtliniendefinitionen zu vereinfachen. Die Richtliniendefinition wird automatisch generiert und zur Überprüfungskonfiguration hinzugefügt, die bei Bedarf aktualisiert werden kann.

Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag

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

Beim Ausführen von Bereitstellungsstrategien können Sie über die folgende Syntax auf Ausgabevariablen zugreifen.

• Für die RunOnce-Strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Für die Kanarische Strategie: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Für die Rollstrategie : $[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 Multiauftragsausgabevariable

Vermeiden des Rollbacks kritischer Änderungen

In klassischen Releasepipelinen ist es üblich, auf geplante Bereitstellungen für regelmäßige Updates zu basieren. Wenn Sie jedoch über einen kritischen Fix verfügen, können Sie auswählen, dass Sie eine manuelle Bereitstellung außerhalb der Band starten. Bei diesem Vorgang bleiben ältere Versionen weiterhin geplant. Dies stellte eine Herausforderung dar, da die manuelle Bereitstellung zurückgesetzt werden würde, wenn die Bereitstellungen pro Zeitplan fortgesetzt wurden. Viele von Ihnen haben dieses Problem gemeldet und wir haben es jetzt behoben. Mit dem Fix werden alle älteren geplanten Bereitstellungen an der Umgebung abgebrochen, wenn Sie eine Bereitstellung manuell starten. Dies gilt nur, wenn die Warteschlangenoption als "Neueste Bereitstellen und Abbrechen anderer" ausgewählt ist.

Vereinfachte Ressourcenberechtigung in YAML-Pipelines

Eine Ressource ist etwas, das von einer Pipeline verwendet wird, die außerhalb der Pipeline liegt. Ressourcen müssen autorisiert werden, bevor sie verwendet werden können. Zuvor konnte die Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline mit einem Ressourcenberechtigungsfehler fehlgeschlagen sein. Sie mussten die Ressourcen aus der Zusammenfassungsseite der fehlgeschlagenen Ausführung autorisieren. Darüber hinaus konnte die Pipeline nicht ausgeführt werden, wenn eine Variable verwendet wurde, die auf eine nicht autorisierte Ressource verweist.

Wir machen es jetzt einfacher, Ressourcenberechtigungen zu verwalten. Anstatt die Ausführung zu scheitern, wartet die Ausführung auf Berechtigungen für die Ressourcen am Anfang der Phase, in der die Ressource verwendet wird. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource auf der Seite "Sicherheit" autorisieren.

Überprüfen des Artefaktes

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

Aktualisierungen zur ARM-Vorlagenbereitstellungsaufgabe

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

ReviewApp in Umgebung

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

Im Folgenden handelt es sich um einen Beispiel-YAML-Codeausschnitt mit 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: MasterNamespace

Sammeln von automatischen und benutzerspezifischen Metadaten aus der Pipeline

Jetzt können Sie die automatische und benutzerspezifische Metadatensammlung aus Pipelineaufgaben aktivieren. Mithilfe von Metadaten können Sie Artefakterichtlinien in einer Umgebung erzwingen, indem Sie die Bewertungsartefaktprüfung verwenden.

VM-Bereitstellungen mit Umgebungen

Eine der am häufigsten angeforderten Features in Umgebungen war VM-Bereitstellungen. Mit diesem Update aktivieren wir die Virtuelle Computerressource in Umgebungen. Sie können jetzt Bereitstellungen auf mehreren Computern koordinieren und Rollupdates mithilfe von YAML-Pipelines ausführen. Sie können den Agent auch auf jedem Ihrer Zielserver direkt installieren und die Rollbereitstellung auf diesen Servern steuern. Darüber hinaus können Sie den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.

Eine Rollbereitstellung ersetzt Instanzen der vorherigen Version einer Anwendung durch Instanzen der neuen Version der Anwendung in einer Reihe von Computern (Rollsatz) in jeder Iteration.

Unter der Einführung von Bereitstellungsupdates werden beispielsweise bis zu fünf Ziele in jeder Iteration aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl stellt die Anzahl der Ziele fest, die jederzeit verfügbar bleiben müssen, ohne die Ziele, die bereitgestellt werden. Hiermit werden auch die Erfolgs- und Fehlerbedingungen während der Bereitstellung bestimmt.

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

Hinweis

Mit diesem Update werden alle verfügbaren Artefakte aus der aktuellen Pipeline und aus den zugehörigen Pipelineressourcen nur in deploy Lifecycle-Hook heruntergeladen. Sie können jedoch auswählen, dass Sie herunterladen können, indem Sie die Aufgabe "Pipeline-Artefakte herunterladen" angeben. Es gibt einige bekannte Lücken in diesem Feature. Wenn Sie beispielsweise eine Phase wiederholen, wird die Bereitstellung auf allen VMs erneut ausgeführt, nicht nur fehlgeschlagene Ziele. 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 mit manuellen Genehmigungen für einige Zeit gesteuert werden. Mit den neuesten Verbesserungen haben Sie jetzt zusätzliche Kontrolle über Ihre Bereitstellungen. Zusätzlich zu Genehmigungen können Ressourcenbesitzer jetzt automatisch 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 darauf zu warten, dass sie abgeschlossen sind. Mithilfe der zusätzlichen Prü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 ausführt. Die Auswertung jeder Überprüfung kann regelmäßig basierend auf dem angegebenen Wiederholungsintervall für die Überprüfung wiederholt werden. Die folgenden zusätzlichen Prüfungen sind jetzt verfügbar:

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

Genehmigungsbenachrichtigung

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

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

Konfigurieren von Bereitstellungsstrategien aus Azure-Portal

Mit dieser Funktion haben wir es Ihnen erleichtert, Pipelines zu konfigurieren, die die Bereitstellungsstrategie Ihrer Wahl verwenden, z. B. Rolling,Canary oder Blue-Green. Mithilfe dieser out-of-box-Strategien können Sie Updates auf sichere Weise bereitstellen und die zugehörigen Bereitstellungsrisiken verringern. Um darauf zuzugreifen, klicken Sie auf die Einstellung "Fortlaufende Übermittlung" auf 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 Paket veröffentlicht, das bereitgestellt werden soll, und die Bereitstellungsstrategie Ihrer Wahl. Im Voraus wird eine voll funktionsfähige Pipeline konfiguriert, die das ausgewählte Paket auf diesem virtuellen Computer bereitstellt.

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

Laufzeitparameter

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

• Geben Sie verschiedene Werte für Skripts und Aufgaben zur Laufzeit an
• Steuerelementparametertypen, zulässige Bereiche und Standardeinstellungen
• Dynamisches Auswählen von Aufträgen und Phasen mit Vorlagenausdruck

Weitere Informationen zu Laufzeitparametern finden Sie hier in der Dokumentation.

Verwenden des Erweiterungsworts in Pipelines

Derzeit können Pipelines in Vorlagen integriert werden, um die Wiederverwendung zu fördern und die Kesselplatte zu verringern. Die Gesamtstruktur der Pipeline wurde noch von der Stamm-YAML-Datei definiert. Mit diesem Update haben wir eine strukturiertere Methode zur Verwendung von Pipelinevorlagen hinzugefügt. Eine Stamm-YAML-Datei kann nun das Schlüsselwort verwenden, um anzugeben, dass die Hauptpipelinestruktur 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. Wir haben auch erweiterte Pipelineparameter mit Datentypen erweitert, um die Hooks zu löschen, die Sie bereitstellen können.

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

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

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

Steuern von Variablen, die in der Warteschlangenzeit außer Kraft gesetzt werden können

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

Wir haben eine neue Auflistungseinstellung hinzugefügt, die den _settable at queue time_ Parameter 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 vom Autor nicht als gekennzeichnet _settable at queue time_ist.

Hinweis

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

Neue vordefinierte Variablen in der YAML-Pipeline

Variablen bieten Ihnen eine bequeme Möglichkeit, wichtige Datenbits in verschiedene Teile Ihrer Pipeline zu erhalten. Mit diesem Update haben wir einige vordefinierte Variablen zu einem Bereitstellungsauftrag hinzugefügt. Diese Variablen werden automatisch vom System festgelegt, die auf den spezifischen Bereitstellungsauftrag ausgerichtet sind und schreibgeschützt sind.

• Environment.Id – Die ID der Umgebung.
• Environment.Name – Der Name der Umgebung, die von dem Bereitstellungsauftrag gezielt ist.
• Environment.ResourceId – Die ID der Ressource in der Umgebung, die von dem Bereitstellungsauftrag ausgerichtet ist.
• Environment.ResourceName – Der Name der Ressource in der Umgebung, die von dem Bereitstellungsauftrag ausgerichtet ist.

Auschecken mehrerer Repositorys

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

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

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

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

Der dritte Schritt zeigt zwei Verzeichnisse, MyCode und Tools im Quellenverzeichnis an.

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

Abrufen von Details zur Laufzeit zu mehreren Repositorys

Wenn eine Pipeline ausgeführt wird, fügt Azure Pipelines Informationen zum Repository, verzweigt und commit hinzu, der die Ausführung ausgelöst hat. Nachdem YAML-Pipelines das Auschecken mehrerer Repositorys unterstützen, möchten Sie möglicherweise auch das Repository, die Verzweigung und den Commit kennen, der für andere Repositorys ausgecheckt wurde. Diese Daten sind über einen Laufzeitausdruck verfügbar, der jetzt einer Variablen zugeordnet werden kann. 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 mit 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-Auflistung und verfügt über Anmeldeinformationen, die auf das Repository in einem anderen Projekt zugreifen können. Sowohl Repos als selfotherrepoauch , werden ausgecheckt.

Wichtig

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

Pipelineressourcenmetadaten als vordefinierte Variablen

Wir haben vordefinierte Variablen für YAML-Pipelinesressourcen 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

Kustomize (Teil von Kubernetes sig-cli) ermöglicht Es Ihnen, unformatierte, vorlagenfreie YAML-Dateien für mehrere Zwecke anzupassen und die ursprüngliche YAML unberührt zu lassen. Eine Option für kustomize wurde unter Backaktion von KubernetesManifest-Aufgabe 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-Verfassen-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 Clusteradministratoranmeldeinformationen in der HelmDeploy-Aufgabe

Zuvor verwendet die HelmDeploy-Aufgabe die Clusterbenutzeranmeldeinformationen für Bereitstellungen. 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.

Eingabe von Argumenten in Docker Verfassen-Aufgabe

Ein neues Feld wurde in der Docker-Verfassenaufgabe eingeführt, damit Sie Argumente wie z --no-cache. B. hinzufü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 eine bessere Kontrolle über die Freigabeerstellung mithilfe des Tagmusterfelds haben, indem Sie einen regulären Tagausdruck angeben und die Veröffentlichung nur erstellt werden, wenn der auslösende Commit mit einer übereinstimmenden Zeichenfolge markiert ist.

Wir haben auch Funktionen hinzugefügt, um die Erstellung und Formatierung von Changelog anzupassen. Im neuen Abschnitt für die Änderungsprotokollkonfiguration können Sie jetzt die Version angeben, mit der die aktuelle Version verglichen werden soll. Der Vergleich mit der Veröffentlichung kann die letzte Vollversion sein (schließt Vorabversionen aus, letzte Nicht-Entwurfsversion oder eine vorherige Version, die mit Ihrem bereitgestellten Releasetag übereinstimmen. Darüber hinaus stellt der Vorgang das Changelog-Typfeld bereit, um den Changelog zu formatieren. Basierend auf der Auswahl zeigt der Änderungsprotokoll entweder eine Liste von Commits oder eine Liste von Problemen/PRs basierend auf Bezeichnungen an.

Installationsprogrammaufgabe "Richtlinien-Agent öffnen"

Open Policy Agent ist ein Open Source, allgemeines Richtlinienmodul, das eine einheitliche, kontextorientierte Richtlinienerzwingung ermöglicht. Wir haben die Installationsprogrammaufgabe "Open Policy Agent" hinzugefügt. Es ist besonders nützlich für die In-Pipeline-Richtlinienerzwingung in Bezug auf Die Infrastruktur als Codeanbieter.

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

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

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

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

Service Mesh Interface-basierte Canary-Bereitstellungen in KubernetesManifest-Aufgabe

Zuvor, als die Canary-Strategie in der KubernetesManifest-Aufgabe angegeben wurde, würde die Aufgabe Basis- und Kanarische Workloads erstellen, deren Replikate einen Prozentsatz der Replikate entsprechen, die für stabile Workloads verwendet werden. Dies war nicht genau identisch mit dem Teilen des Datenverkehrs bis zum gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir Unterstützung für service Mesh Interface basierende Canary-Bereitstellungen zur KubernetesManifest-Aufgabe hinzugefügt.

Die Abstraktion der Service Mesh-Schnittstelle ermöglicht die Plug-and-Play-Konfiguration mit Dienstanbietern wie Linkerd und Istio. Jetzt nimmt die KubernetesManifest-Aufgabe die harte Arbeit der Zuordnung von SMI-TrafficSplit-Objekten zu den stabilen, basisbasierten und kanarischen Diensten während des Lebenszyklus der Bereitstellungsstrategie ab. Der gewünschte Prozentsatz der Datenverkehrsteilung zwischen stabilen, Basisplan und Canary ist genauer, da der prozentsatzige Datenverkehrsteil auf den Anforderungen in der Dienstgitterebene gesteuert wird.

Nachfolgend sehen Sie ein Beispiel für die Durchführung von SMI-basierten Canarybereitstellungen auf rollierende 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-Dateikopieaufgabe kann in einer Build- oder Releasepipeline verwendet werden, um Dateien in Microsoft-Speicher-Blobs oder virtuelle Computer (VMs) zu kopieren. Die Aufgabe verwendet AzCopy, das Befehlszeilenprogramm für schnelles 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 AzCopy ist.

Der azcopy copy Befehl unterstützt nur die argumente , die damit verknüpft sind. Aufgrund der Änderung der Syntax von AzCopy sind einige der vorhandenen Funktionen in AzCopy V10 nicht verfügbar. Dazu zählen unter anderem folgende Einstellungen:

• Angeben des Protokollspeicherorts
• Bereinigen von Protokoll- und Plandateien nach der Kopie
• Kopie fortsetzen, wenn der Auftrag fehlschlägt

Die in dieser Version des Vorgangs unterstützten zusätzlichen Funktionen sind:

• Wildcardsymbole im Dateinamen/Pfad der Quelle
• Ableiten des Inhaltstyps basierend auf der Dateierweiterung, wenn keine Argumente bereitgestellt werden
• Definieren der Protokollverwendlichkeit 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 zum Rückruf in Azure DevOps verwendet. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode, Uploadprotokolle, Testergebnisse, Artefakte oder REST-Aufrufe in Azure DevOps abzurufen. 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 Buildpipelinen zu sein. Sie haben jedoch nicht über dieses Steuerelement für klassische Release- oder YAML-Pipelines verfügt. Mit diesem Update wird eine Sammlungseinstellung eingeführt, um jeden Auftrag zu erzwingen, um ein projektbezogenes Token zu erhalten, unabhängig davon, was in der Pipeline konfiguriert ist. Wir haben auch die Einstellung auf Projektebene hinzugefügt. Jetzt ist jedes neue Projekt und jede von Ihnen erstellte Auflistung automatisch aktiviert.

  Hinweis

  Die Auflistungseinstellung überschreibt die Projekteinstellung.

  Wenn Sie diese Einstellung in vorhandenen Projekten und Sammlungen aktivieren, kann es vorkommen, dass bestimmte Pipelines fehlschlagen, wenn Ihre Pipelines auf Ressourcen zugreifen, die sich außerhalb des Teamprojekts befinden, indem Sie Zugriffstoken verwenden. Um Pipelinefehler zu mindern, können Sie dem Project Build Service Account explizit Zugriff auf die gewünschte Ressource erteilen. Es wird dringend empfohlen, diese Sicherheitseinstellungen zu aktivieren.

• Einschränken des Erstellungsdienstzugriffs

  Um die Pipelinesicherheit zu verbessern, indem sie den Umfang des Zugriffstokens einschränken, kann Azure Pipelines jetzt den Repositoryzugriff auf nur die für eine YAML-basierte Pipeline erforderliche Repos einschränken. Dies bedeutet, dass das Zugriffstoken der Pipelines nur in der Lage wäre, die in der Pipeline verwendeten Repo(n) anzuzeigen. 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 sie in den Einstellungen für Die Pipelineseinstellungen>> für Sammlungen aktivieren. Wenn Sie dieses Feature verwenden, 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.

• Entfernen bestimmter Berechtigungen für das Zugriffstoken

  Standardmäßig erteilen 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 es dem Project Build Service-Konto oder dem Projektsammlungs-Builddienstkonto explizit gewähren, je nachdem, welche Token Sie verwenden.

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.

Schrittadressierung und Befehlsisolation

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

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

Im Folgenden finden Sie ein umfassendes Beispiel, in dem Sie Schritte für den Host in einem Auftragscontainer und in einem anderen Container ausführen:

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 aufnehmen. Mit diesem Update wird die Sicherheit um Pipelinevariablen verstärkt, um System- und Warteschlangenzeitvariablen schreibgeschützt zu machen. Darüber hinaus können Sie eine YAML-Variable schreibgeschützt erstellen, 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. Zuvor konnte die Dienstverbindungssicherheit nur über vordefinierte Azure DevOps-Gruppen wie Endpunktadministratoren und Endpunktersteller verwaltet werden.

Als Teil dieser Arbeit haben wir die neuen Rollen "Reader", "Benutzer", "Ersteller" und "Administrator" eingeführt. Sie können diese Rollen über die Seite "Dienstverbindungen" in Ihrem Projekt festlegen und diese werden von den einzelnen Verbindungen geerbt. 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.

Weitere Informationen zur Sicherheit von Dienstverbindungen finden Sie hier.

Projektübergreifende Freigabe von Dienstverbindungen

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

Weitere Informationen zur Freigabe von Dienstverbindungen finden Sie hier.

Ablaufverfolgung für Pipelines und ACR-Ressourcen

Wir stellen eine vollständige E2E-Ablaufverfolgung 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 auf die Commits, Arbeitselemente und Artefakte zurückverfolgen.

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

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

  

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

  

• Die Arbeitselemente , die jeder Ressource zugeordnet sind, die von der Pipeline verbraucht werden.

• Die Artefakte , die von der Ausführung verwendet werden können.

  

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

Unterstützung für große Testanlagen

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

Möglicherweise wird die VSTest-Aufgabe oder der Vorgang "Testergebnisse veröffentlichen" angezeigt, der einen Fehler von 403 oder 407 in den Protokollen zurückgibt. 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 Anforderungen auf https://*.vstmrblob.vsassets.io. Hier finden Sie Informationen zur Problembehandlung in der Dokumentation. ​

Hinweis

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

Anzeigen korrekter Poolinformationen für jeden Auftrag

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

CI-Trigger für neue Zweigstellen

Es war eine lange ausstehende Anforderung, CI-Builds nicht auszulösen, wenn eine neue Verzweigung erstellt wird und wenn diese Verzweigung keine Änderungen hat. Betrachten Sie die folgenden Beispiele:

• Sie verwenden die Webschnittstelle, um eine neue Verzweigung basierend auf einer vorhandenen Verzweigung zu erstellen. Dies würde sofort einen neuen CI-Build auslösen, wenn ihr Verzweigungsfilter mit dem Namen der neuen Verzweigung übereinstimmt. Dies ist nicht erwünscht, da der Inhalt der neuen Verzweigung im Vergleich zu der vorhandenen Verzweigung identisch ist.
• Sie haben ein Repository mit zwei Ordnern – App und Dokumente. Sie richten einen Pfadfilter für CI ein, um "app" übereinzugleichen. Mit anderen Worten, Sie möchten keinen neuen Build erstellen, wenn eine Änderung an Dokumente verschoben wurde. Sie erstellen lokal eine neue Verzweigung, nehmen einige Änderungen an Dokumenten vor, und pushen Sie diese Verzweigung dann an den Server. Wir haben verwendet, um einen neuen CI-Build auszulösen. Dies ist nicht erwünscht, da Sie explizit aufgefordert haben, nicht nach Änderungen im Dokumentordner zu suchen. Aufgrund der Art und Weise, wie wir ein neues Verzweigungsereignis behandelt haben, scheint es jedoch, als ob auch eine Änderung am App-Ordner vorgenommen wurde.

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

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

Ausgabevariablen können jetzt in Phasen einer YAML-basierten Pipeline 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 seine Aufträge sind ebenfalls verfügbar.

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

Hinweis

Standardmäßig hängt jede Phase in einer Pipeline von der ersten 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 Stufe 1 benötigt, muss eine explizite Abhängigkeit von Stufe 1 deklariert werden.

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 ein neues Feature oder eine neue Aufgabe vorhanden ist, die eine neuere Agent-Version 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, schlägt Pipelines mit einer klaren Fehlermeldung fehl, anstatt Agents zum Aktualisieren anzufordern. Dieses Feature ist hauptsächlich für Kunden mit selbst gehosteten Pools und sehr strengen Änderungssteuerungsanforderungen interessant. Automatische Updates sind standardmäßig aktiviert, und es wird empfohlen, die meisten Kunden zu deaktivieren.

Agentdiagnose

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

Diensthaken für YAML-Pipelines

Die Integration von Diensten in YAML-Pipelines ist einfach. 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 beispielsweise ein Helpdeskticket 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 für bestimmte Umgebungen gefiltert werden. Ebenso können Zustandsänderungsereignisse nach dem neuen Status der Pipelineausführung oder der Phase gefiltert werden.

Optimieren der Integration

Optimieren ist eine leistungsstarke A/B-Test- und Featurekennzeichnungsplattform für Produktteams. Die Integration von Azure-Pipelines mit der Optimierungs-Experimentierplattform ermöglicht Produktteams das Testen, Lernen und Bereitstellen in einem beschleunigten Tempo, während alle DevOps-Vorteile von Azure Pipelines gewonnen werden.

Die Optimierungserweiterung für Azure DevOps fügt den Build- und Releasepipelinen Experimentierungs- und Featurekennzeichnungsschritte hinzu, sodass Sie die Features kontinuierlich durchlaufen und mithilfe von 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 Artefaktequelle in Azure DevOps-Releasepipelinen verknüpfen. Dadurch können Sie die GitHub-Version als Teil Ihrer Bereitstellungen nutzen.

Wenn Sie in der Releasepipelinedefinition auf "Artefakte hinzufügen " klicken, finden Sie den neuen GitHub Release-Quelltyp . Sie können die Dienstverbindung und das GitHub-Repo bereitstellen, um die GitHub-Version zu nutzen. Sie können auch eine Standardversion für die GitHub-Version auswählen, um die neueste, bestimmte Tag-Version 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 in Azure Pipelines

Terraform ist ein Open-Source-Tool zum Entwickeln, Ändern und Versionsverwaltungsinfrastruktur sicher und effizient. Terraform codiert APIs in deklarative Konfigurationsdateien, sodass Sie die Infrastruktur mithilfe einer hochstufigen 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 hier in der Dokumentation.

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. Beispielsweise haben Sie möglicherweise Aktivitäten, 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 die Implementierung wert sind, basierend auf den direkten Auswirkungen, die sie auf die Leistung Ihres Features haben.

Die Erweiterung "Google Analytics-Experimente" für Azure DevOps fügt den Build- und Releasepipelinen Experimentierschritte hinzu, sodass Sie die Tests 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 Erweiterung für Google Analytics-Experimente aus dem Marketplace herunterladen.

Aktualisierte ServiceNow-Integration in 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 eine beliebige Änderungseigenschaft verwenden können, um das Torergebnis 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 verlassen zu müssen.

Flaky Bug Management und Lösung

Wir haben flaky Testverwaltung eingeführt, um den End-to-End-Lebenszyklus mit Erkennung, Berichterstellung und Auflösung zu unterstützen. Um es weiter zu verbessern, fügen wir flaky Testfehlerverwaltung und -auflösung hinzu.

Während Sie den flakyn Test untersuchen, können Sie einen Fehler mithilfe der Fehleraktion erstellen, die dann einem Entwickler zugewiesen werden kann, um die Ursache des flakyn Tests weiter zu untersuchen. Der Fehlerbericht enthält Informationen über die Pipeline wie Fehlermeldung, Stapelablaufverfolgung und andere Informationen, die dem Test zugeordnet sind.

Wenn ein Fehlerbericht behoben oder geschlossen wird, heben wir den Test automatisch als unflaky auf.

Festlegen von VSTest-Vorgängen, die nicht ausgeführt werden, wenn eine Mindestanzahl von Tests nicht ausgeführt wird

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

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

Die VSTest-Aufgabe speichert Testergebnisse und zugeordnete Dateien im $(Agent.TempDirectory)\TestResults Ordner. 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 die Markdown-Unterstützung für Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie Fehlermeldungen für Testausführungen und Testergebnisse ganz einfach formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu erleichtern. Die unterstützte Markdownsyntax finden Sie hier.

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

Sie können jetzt Pipelinedekortoren zu Bereitstellungsaufträgen hinzufügen. Sie können einen beliebigen benutzerdefinierten Schritt (z. B. Sicherheitsrisikoscanner) automatisch in jede Lebenszyklus-Hook-Ausführung jedes Bereitstellungsauftrags einfügen. Da Pipelinedekortoren auf alle Pipelines in einer Sammlung angewendet werden können, kann dies als Teil der Erzwingung sicherer Bereitstellungspraktiken genutzt werden.

Darüber hinaus können Bereitstellungsaufträge zusammen mit dienstseitigem Auto als Containerauftrag ausgeführt werden.

Test Plans

Seite "Neuer Testplan"

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

Helfen Sie mir, die neue Seite zu verstehen

Die neue Test Plans Seite hat insgesamt 6 Abschnitte, von denen die ersten 4 neu sind, während die Diagrammerweiterungsabschnitte & die vorhandene Funktionalität sind.

1. Testplanheader: Verwenden Sie diese Option, um einen Testplan zu suchen, zu suchen, zu bearbeiten, zu kopieren oder zu klonen.
2. Testsuitenstruktur: Verwenden Sie dies, um Testsuiten hinzuzufügen, zu verwalten, zu exportieren oder zu bestellen. Nutzen Sie dies auch, um Konfigurationen zuzuweisen und Benutzerakzeptanztests durchzuführen.
3. Registerkarte definieren: Zusammenfügen, Hinzufügen und Verwalten von Testfällen in einer Testsuite der Wahl über diese Registerkarte.
4. Ausführen der Registerkarte: Zuweisen und Ausführen von Tests über diese Registerkarte oder Suchen eines Testergebnisses zum Drilldown.
5. Diagrammregisterkarte: Nachverfolgen der Testausführung und des Status über Diagramme, die auch an Dashboards angeheftet werden können.
6. Erweiterbarkeit: Unterstützt die aktuelle Erweiterbarkeitspunkte innerhalb des Produkts.

Ermöglicht eine umfassende Strichansicht dieser neuen Abschnitte unten.

1. Testplankopf

Aufgaben

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

• Markieren eines Testplans als Favorit
• Aufheben der Markierung eines Favoritentestplans
• Navigieren Sie ganz einfach zu Ihren bevorzugten Testplänen
• Zeigen Sie den Iterationspfad des Testplans an, der eindeutig angibt, ob der Testplan aktuell oder aktuell ist.
• Anzeigen der schnellen Zusammenfassung des Berichts "Testfortschritt" mit einem Link zum Navigieren zum Bericht
• Navigieren Sie zurück zur Seite "Alle/Mine" Test Plans

Kontextmenüoptionen

Das Kontextmenü im Header "Testplan" bietet die folgenden Optionen:

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

Testplan kopieren (neue Funktion)

Es wird empfohlen, pro Sprint/Release einen neuen Testplan 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 eine Funktion "Testplan kopieren" auf der neuen Seite aktiviert. Durch die Nutzung können Sie Testpläne kopieren oder klonen. Die backing REST-API wird hier behandelt, und die API ermöglicht es Ihnen, einen Testplan auch in Projekten zu kopieren/zu klonen.
Weitere Richtlinien für Test Plans Verwendung finden Sie hier.

2. Testsuitenstruktur

Aufgaben

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

• Erweitern/Reduzieren: Mit diesen Symbolleistenoptionen können Sie die Hierarchiestruktur der Suite erweitern oder reduzieren.
• Testpunkte aus untergeordneten Suites anzeigen: Diese Symbolleistenoption ist nur sichtbar, wenn Sie sich auf der Registerkarte "Ausführen" befinden. Auf diese Weise können Sie alle Testpunkte für die angegebene Suite und ihre untergeordneten Elemente in einer Ansicht anzeigen, um die Verwaltung von Testpunkten zu erleichtern, ohne zu einzelnen Suites einzeln navigieren zu müssen.
• Bestellsuiten: Sie können Suites ziehen/ablegen, um entweder die Hierarchie von Suites neu anzuordnen oder sie innerhalb des Testplans von einer Suitehierarchie in eine andere zu verschieben.

Kontextmenüoptionen

Das Kontextmenü in der Testsuite-Struktur 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 anforderungsbasierte Suite, um direkte Verknüpfungen mit den Anforderungen/Benutzergeschichten zur nahtlosen Ablaufverfolgung zu erstellen.
  • Verwenden Sie abfragebasiert, um Testfälle dynamisch zu organisieren, die einem Abfragekriterium entsprechen.
• Zuweisen von Konfigurationen: 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 Eigenschaften des Testplans, Testsuiteeigenschaften sowie Details zu den Testfällen und Testpunkten als "E-Mail" oder "Drucken in pdf".
• Öffnen Sie die Arbeitsaufgabe der Testsuite: Mit dieser Option können Sie das Arbeitselementformular "Test Suite" bearbeiten, um die Arbeitsaufgabenfelder zu verwalten.
• Weisen Sie Testern zu, um alle Tests auszuführen: Diese Option ist sehr nützlich für Benutzerakzeptanztests (UAT) Szenarien, in denen derselbe Test von mehreren Testern ausgeführt werden muss, in der Regel zu verschiedenen Abteilungen gehören.
• Umbenennen/Löschen: Mit diesen Optionen können Sie den Suitenamen verwalten oder die Suite und deren Inhalt aus dem Testplan entfernen.

3. Registerkarte definieren

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

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

Aufgaben

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

• Neuen Testfall mithilfe des Arbeitselementformulars hinzufügen: Mit dieser Option können Sie mithilfe des Arbeitselementformulars einen neuen Testfall erstellen. Der erstellte Testfall wird automatisch der Suite hinzugefügt.
• Neuen Testfall mithilfe des Rasters hinzufügen: Mit dieser Option können Sie eine oder mehrere Testfälle mithilfe der Rasteransicht für Testfälle erstellen. Die erstellten Testfälle werden automatisch der Suite hinzugefügt.
• Fügen Sie vorhandene Testfälle mithilfe einer Abfrage hinzu: Mit dieser Option können Sie der Suite vorhandene Testfälle hinzufügen, indem Sie eine Abfrage angeben.
• Order test cases by drag/drop: You can reorder cases by drag/drop by drag/drop of one or more test cases within a given suite. Die Reihenfolge der Testfälle gilt nur für manuelle Testfälle und nicht für automatisierte Tests.
• Verschieben Sie Testfälle von 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 zum Anzeigen/Bearbeiten von Testfällen zusammen mit Testschritten verwenden.
• Vollbildansicht: Sie können den Inhalt der gesamten Registerkarte "Definieren" in einem Vollbildmodus mit dieser Option anzeigen.
• Filtern: Mithilfe der Filterleiste können Sie die Liste der Testfälle mithilfe der Felder "Testfalltitel", "zugewiesen" und "Zustand" 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 Arbeitselementformular des Testfalls.

Kontextmenüoptionen

Das Kontextmenü im Knoten "Testfall" auf der Registerkarte "Definieren" enthält die folgenden Optionen:

• Öffnen/Bearbeiten des Arbeitsaufgabenformulars für Testfälle: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitsaufgabenfelder bearbeiten, einschließlich der Testschritte.
• Testfälle bearbeiten: Mit dieser Option können Sie Arbeitsaufgabenfelder für Testfall massenbearbeitungen. Sie können diese Option jedoch nicht verwenden, um Testschritte zu massenbearbeitungen.
• Testfälle im Raster bearbeiten: Mit dieser Option können Sie die ausgewählten Testfälle massenbearbeitungen, einschließlich Testschritten mithilfe der Rasteransicht.
• Konfigurationen zuweisen: 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. Die zugrunde liegende Testfallarbeitsaufgabe wird jedoch nicht geändert.
• Erstellen Sie eine Kopie/Klon von Testfällen: Mit dieser Option können Sie eine Kopie/Klon ausgewählter Testfälle erstellen. Weitere Informationen finden Sie unten.
• Verknüpfte Elemente anzeigen: Mit dieser Option können Sie die verknüpften Elemente für einen bestimmten Testfall betrachten. Weitere Informationen finden Sie unten.

Testfälle kopieren/klonen (neue Funktion)

In Szenarien, in denen Sie einen Testfall kopieren/klonen möchten, können Sie die Option "Testfall kopieren" verwenden. Sie können die Zielprojekt-, Zieltestplan- und Zieltestsuite angeben, in der sie den Testfall kopieren/geklont erstellen können. Darüber hinaus können Sie 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 Wertvorschlag des Test Plans Produkts. Mit der Option "Verknüpfte Elemente anzeigen" können Sie ganz einfach alle verknüpften Anforderungen betrachten, mit denen dieser Testfall verknüpft ist, mit allen Testsuiten/Testplänen, in denen dieser Testfall verwendet wurde, und alle Fehler, die als Teil der Testausführung abgelegt wurden.

4. Registerkarte 'Ausführen'

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

Was ist ein Testpunkt? Testfälle selbst sind nicht ausführbare Dateien. 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 über einen Testfall als "Testanmeldungsfunktionalität" verfügen 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. Durch die Testergebnisseansicht (Ausführungsverlauf) können Sie alle Ausführungen eines Testpunkts anzeigen. Die neueste Ausführung für den Testpunkt ist das, was Sie auf der Registerkarte "Ausführen" sehen.
Daher sind Testfälle wiederverwendbare Entitäten. Durch die Einbeziehung in einen Testplan oder eine Suite werden Testpunkte generiert. Durch Ausführen von Testpunkten bestimmen Sie die Qualität des zu entwickelnden Produkts oder Diensts.

Einer der hauptvorteile der neuen Seite ist für Benutzer, die hauptsächlich testausführungs-/tracking ausführen (nur "Standard"-Zugriffsstufe haben müssen), sie sind nicht durch die Komplexität der Suiteverwaltung überfordert (Registerkarte definieren ist für solche Benutzer ausgeblendet).

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

Aufgaben

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

• Massenmarkierungstestpunkte: Mit dieser Option können Sie das Ergebnis der Testpunkte schnell markieren – bestanden, fehlgeschlagen, blockiert oder nicht anwendbar, ohne den Testfall über den Testläufer auszuführen. Das Ergebnis kann für einen oder mehrere Testpunkte bei einem Go markiert werden.
• Ausführen von Testpunkten: Mit dieser Option können Sie die Testfälle ausführen, indem Sie jeden Testschritt einzeln durchlaufen und sie mit einem Testläufer übergeben/fehlgeschlagen markieren. Je nachdem, welche Anwendung Sie testen, können Sie den "Web Runner" verwenden, um eine "Webanwendung" oder den "Desktopläufer" zum Testen von Desktop- und/oder Webanwendungen zu testen. Sie können auch die Option "Ausführen mit Optionen" aufrufen, um einen Build anzugeben, mit dem die Tests angegeben werden sollen, die Sie ausführen möchten.
• Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte "Ausführen" mit "Spaltenoptionen" sichtbar sind. Die Liste der für die Auswahl verfügbaren Spalten sind testpunkten zugeordnet, z. B. Run by, Assigned Tester, Configuration usw.
• Vollbildansicht: Sie können den Inhalt der gesamten Registerkarte "Ausführen" im Vollbildmodus mithilfe dieser Option anzeigen.
• Filtern: Mithilfe der Filterleiste können Sie die Liste der Testpunkte mithilfe der Felder "Testfalltitel", "zugewiesen", "Status", "Testergebnis", "Tester" und "Konfiguration" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.

Kontextmenüoptionen

Das Kontextmenü im Knoten "Testpunkt" auf der Registerkarte "Ausführen" enthält die folgenden Optionen:

• Testergebnis markieren: Wie oben können Sie das Ergebnis der Testpunkte schnell markieren – bestanden, fehlgeschlagen, blockiert oder nicht anwendbar.
• Testpunkte ausführen: Wie oben können Sie die Testfälle über Testläufer ausführen.
• Zurücksetzen des Tests auf aktiv: Diese Option ermöglicht es Ihnen, das Testergebnis auf aktiv zurückzusetzen, wodurch das letzte Ergebnis des Testpunkts ignoriert wird.
• Öffnen/Bearbeiten von Arbeitsaufgabenformular für Testfälle: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitselementfelder bearbeiten, einschließlich der Testschritte.
• Zuweisen von Testern: Mit dieser Option können Sie die Testpunkte den Testern für die Testausführung zuweisen.
• Testergebnis anzeigen: Diese Option ermöglicht es Ihnen, die neuesten Testergebnisdetails anzuzeigen, einschließlich des Ergebnisses jedes Testschritts, Kommentare, hinzugefügt oder Fehler abgelegt.
• Anzeigen des Ausführungsverlaufs: Mit dieser Option können Sie den gesamten Ausführungsverlauf für den ausgewählten Testpunkt anzeigen. Es öffnet eine neue Seite, auf der Sie die Filter anpassen können, um den Ausführungsverlauf nicht nur des ausgewählten Testpunkts, sondern auch für den gesamten Testfall anzuzeigen.

Test Plans Statusbericht

Mit diesem out-of-the-box-Bericht können Sie die Ausführung und den Status eines oder mehrerer Test Plans in einem Projekt nachverfolgen. Besuchen Sie Test Plans > Statusbericht*, um mit der Verwendung des Berichts zu beginnen.

Die drei Abschnitte des Berichts umfassen folgendes:

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

Artifacts

Hinweis

Azure DevOps Server 2020 importiert keine Feeds, die sich im Papierkorb befinden, während des Datenimports. Wenn Sie Feeds importieren möchten, die sich im Papierkorb befinden, stellen Sie sie vor dem Starten des Datenimports aus dem Papierkorb wiederhergestellt.

Lizenzausdrücke und eingebettete Lizenzen

Jetzt können Sie die Details der Lizenzinformationen für NuGet-Pakete anzeigen, die in Azure-Artefakten gespeichert sind, während Sie Pakete in Visual Studio durchsuchen. Dies gilt für Lizenzen, die mithilfe von Lizenzausdrücke oder eingebetteten Lizenzen dargestellt werden. Jetzt können Sie einen Link zu den Lizenzinformationen auf der Seite "Visual Studio-Paketdetails" (roter Pfeil in der nachstehenden Abbildung) sehen.

Durch Klicken auf den Link gelangen Sie zu einer Webseite, auf der Sie die Details der Lizenz anzeigen können. Diese Erfahrung ist sowohl für Lizenzausdrücke als auch für eingebettete Lizenzen identisch, sodass Sie Lizenzdetails für Pakete sehen können, die in Azure-Artefakten 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 authentifizieren, indem Sie Authentifizierungsaufgaben mit leichtem Gewicht verwenden. Dazu gehören NuGet, npm, PIP, Twine und Maven. Zuvor können Sie sich mit diesen Paketmanagern authentifizieren, indem Sie Aufgaben verwenden, die eine große Anzahl von Funktionen bereitgestellt haben, einschließlich der Möglichkeit, Pakete zu veröffentlichen und herunterzuladen. Dies erfordert jedoch die Verwendung dieser Aufgaben für alle Aktivitäten, die mit den Paketmanagern interagieren. Wenn Sie ihre eigenen Skripts zum Ausführen von Aufgaben wie Veröffentlichungs- oder Herunterladen von Paketen hatten, könnten Sie sie in Ihrer Pipeline nicht verwenden. Jetzt können Sie Skripts ihres eigenen Designs in Ihrer Pipeline YAML verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben ausführen. Ein Beispiel mit 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. Dies ermöglicht Ihnen die vollständige Kontrolle über Die Aufrufe von Befehlen und erleichtert die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration. Weitere Informationen finden Sie in der Dokumentation zur NuGet-,npm-, PIP-, Twine- und Maven-Authentifizierungsaufgabe.

Verbesserungen der Ladezeit der Feedseite

Wir freuen uns, bekannt zu geben, dass wir die Ladezeit der Feedseite verbessert haben. Im Durchschnitt haben die Ladezeiten der Feedseite um 10 % verringert. Die größten Feeds haben die größte Verbesserung der 99. Prozent der Feedseitenladezeit (Ladezeiten in den höchsten 99 % aller Feeds) um 75 % verringert.

Freigeben Ihrer Pakete öffentlich mit öffentlichen Feeds

Sie können jetzt Ihre Pakete in öffentlichen Feeds erstellen und speichern. Pakete, die in öffentlichen Feeds gespeichert sind, sind für alle im Internet ohne Authentifizierung verfügbar, unabhängig davon, ob sie sich in Ihrer Sammlung befinden oder sogar in einer Azure DevOps-Auflistung angemeldet sind. Erfahren Sie mehr über öffentliche Feeds in unserer Feeds-Dokumentation oder springen Sie direkt in unser Lernprogramm, um Pakete öffentlich zu teilen.

Konfigurieren von Upstreams in verschiedenen Sammlungen innerhalb eines AAD-Mandanten

Sie können nun einen Feed in einer anderen Auflistung hinzufügen, die Ihrem Azure Active Directory (AAD)-Mandanten als upstream-Quelle zu Ihrem Artefakte-Feed zugeordnet ist. Ihr Feed kann Pakete aus den Feeds finden und verwenden, die als Upstreamquellen konfiguriert sind, sodass Pakete einfach über Sammlungen freigegeben werden können, die Ihrem AAD-Mandanten zugeordnet sind. Erfahren Sie, wie Sie dies in den Dokumenten einrichten.

Verwenden des Python-Anmeldeinformationenanbieters zum Authentifizieren von Pip und Twine mit Azure-Artefakte-Feeds

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

Azure-Artefakte-Feeds im Visual Studio Package Manager

Jetzt werden Paketsymbole, Beschreibungen und Autoren im Visual Studio NuGet Package Manager für Pakete angezeigt, die von Azure-Artefakte-Feeds bereitgestellt wurden. Zuvor wurden die meisten dieser Metadaten nicht für VS bereitgestellt.

Aktualisierte Verbindung mit Feederfahrung

Das Dialogfeld "Verbinden mit Feed" ist der Einstieg in die Verwendung von Azure-Artefakten; es 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 zu erweitern, für die wir Anweisungen geben.

Öffentliche Feeds sind jetzt allgemein verfügbar mit dem upstream-Support

Die öffentliche Vorschau öffentlicher Feeds hat eine großartige Einführung und Feedback erhalten. In dieser Version erweiterten wir zusätzliche Features auf allgemeine Verfügbarkeit. Jetzt können Sie einen öffentlichen Feed als upstream-Quelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl auf private als auch auf projektbezogene Feeds vorgeschaltet werden können.

Erstellen von projektbezogenen Feeds aus dem Portal

Wenn wir öffentliche Feeds veröffentlicht haben, veröffentlichten wir auch projektbezogene Feeds. Bis jetzt könnten projektbezogene Feeds über REST-APIs oder durch Erstellen eines öffentlichen Feeds erstellt und dann das Projekt privat gedreht werden. Jetzt können Sie projektbezogene Feeds direkt im Portal aus jedem Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch sehen, welche Feeds Projekt sind und welche auflistungsbereichs in der Feedauswahl enthalten sind.

Npm-Leistungsverbesserungen

Wir haben Änderungen an unserem Kerndesign vorgenommen, um die Art und Weise zu verbessern, wie wir npm-Pakete in Azure-Artefakte-Feeds speichern und bereitstellen. Dies hat uns bei einigen der am höchsten verwendeten APIs für npm zu einer bis zu 10-fachen Reduzierung der Latenz beigetragen.

Verbesserungen der Barrierefreiheit

Wir haben Korrekturen bereitgestellt, um Barrierefreiheitsprobleme auf unserer Feedsseite zu beheben. Die Korrekturen umfassen folgendes:

• Erstellen von Feederfahrungen
• Benutzeroberfläche für globale Feedeinstellungen
• Herstellen einer Verbindung mit Feederfahrung

Wiki

Umfassende Bearbeitung für Codewikiseiten

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

Jetzt können Sie eine Codewikiseite im querseitigen Editor innerhalb von Wiki bearbeiten. Auf diese Weise können Sie die Rich-Markdown-Symbolleiste verwenden, um Ihre Inhalte zu erstellen, die die Bearbeitungserfahrung mit dem in Projektwiki identisch machen. Sie können weiterhin die Bearbeitung in Repos auswählen, indem Sie im Kontextmenü die Option "In Repos bearbeiten " auswählen.

Erstellen und Einbetten von Arbeitselementen auf einer Wiki-Seite

Während wir Ihr Feedback hören, 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 ein Arbeitselement 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 Arbeitsaufgabe" aus. Dadurch sparen Sie Zeit, da Sie zuerst die Arbeitsaufgabe nicht erstellen müssen, wechseln Sie zum Bearbeiten, und suchen Sie dann die Arbeitsaufgabe, um sie einzubetten. Außerdem wird der Kontextwechsel reduziert, da Sie nicht aus dem Wiki-Bereich gehen.

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

Kommentare in Wiki-Seiten

Zuvor 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 erfolgen mussten. Mit Kommentaren können Sie jetzt direkt innerhalb des Wikis mit anderen zusammenarbeiten. Sie können die @mention Benutzerfunktionen innerhalb von Kommentaren nutzen, um die Aufmerksamkeit anderer Teammitglieder zu lenken. Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert. Weitere Informationen zu Kommentaren finden Sie in unserer Dokumentation hier.

Ausblenden von Ordnern und Dateien ab "." in wiki-Struktur

Bis jetzt zeigt die Wiki-Struktur alle Ordner und Dateien ab einem Punkt (.) in der Wiki-Struktur an. 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ötige Unübersichtlichkeiten reduziert werden.

Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert.

Kurz- und lesbare Wiki-Seiten-URLs

Sie müssen keine mehrlineare URL verwenden, um Wiki-Seitenlinks freizugeben. 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 Featurevorschlagsticket aus dem Entwicklercommunity priorisiert.

Synchroner Bildlauf zum Bearbeiten von Wiki-Seiten

Das Bearbeiten von Wiki-Seiten ist jetzt einfacher mit synchroner Bildlauf zwischen dem Bearbeitungsbereich und dem Vorschaubereich. Durch das Scrollen auf einer Seite wird automatisch die andere Seite gescrollt, um die entsprechenden Abschnitte zuzuordnen. Sie können den synchronen Bildlauf mit der Umschaltfläche deaktivieren.

Hinweis

Der Status des synchronen Bildlaufschalters 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 die am häufigsten angezeigten Seiten zu erhalten.

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

Hinweis

Ein Seitenbesuch wird als Seitenansicht durch einen bestimmten Benutzer in einem 15-minütigen Intervall definiert.

Berichterstellung

Pipelinefehler- und Dauerberichte

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

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

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

Verbesserung des Abfrageergebnisse-Widgets

Das Abfrageergebnis-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 lange erwartete Verbesserungen aufgenommen:

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

Erweiterte Filterung von Lead- und Zykluszeit-Widgets

Lead- und Zykluszeit werden von Teams verwendet, um zu sehen, wie lange es dauert, bis die Arbeit durch ihre Entwicklungspipelinen fließt und letztendlich einen Mehrwert für ihre Kunden liefert.

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

Mit diesem Update können Fragen wie dies beantwortet werden, indem sie im Board-Schwimmlane filtern.

Wir haben auch Arbeitsaufgabenfilter eingeschlossen, um die Arbeitsaufgaben zu beschränken, die im Diagramm angezeigt werden.

Inline-Sprint-Burndown mithilfe von Story points

Ihr Sprint Burndown kann jetzt von Stories burndown ausgeführt werden. Dies adressieren Sie Ihr Feedback aus dem Entwicklercommunity.

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

1. Hintergrundprotokoll "Geschichten auswählen"
2. Auswählen des Burndowns für Summe der Storypunkte

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

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

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

Hinweis

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

Miniaturansicht des Inline-Sprints

Der Sprint Burndown ist zurück! Vor einigen Jahren haben wir den Im-Kontext-Sprint-Burndown aus den Kopfzeilen "Sprint Burndown" und "Taskboard" entfernt. Basierend auf Ihrem Feedback haben wir die Sprint-Burndown-Miniaturansicht verbessert und erneut 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 an dem vollständigen Bericht vorgenommen wurden, werden im Diagramm angezeigt, das in der Kopfzeile angezeigt wird. Daher können Sie sie jetzt so konfigurieren, dass sie basierend auf Geschichten, Storypunkten oder nach Anzahl von Aufgaben anstelle der verbleibenden Arbeitsmenge burndowns ausgeführt wird.

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

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

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

Hinweis

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 freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und über Entwicklercommunity nachverfolgen und Ratschläge zu Stack Overflow erhalten.

---

Seitenanfang