Azure DevOps Server 2020 Versionshinweise

Ist diese Seite hilfreich?

Haben Sie weiteres Feedback für uns?

Feedback wird an Microsoft gesendet: Wenn Sie auf die Sendeschaltfläche klicken, wird Ihr Feedback verwendet, um Microsoft-Produkte und -Dienste zu verbessern. Datenschutzrichtlinie

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

In diesem Artikel finden Sie Informationen zu der 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 neuer unterstützt. Wenn sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie auf Azure DevOps Server 2019 aktualisieren. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps lokal.

---

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

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

Azure DevOps Server 2020 behandelt die Aufbewahrung von Builddaten unterschiedlich, basierend auf Aufbewahrungsrichtlinien auf Pipelineebene. Bestimmte Richtlinienkonfigurationen führen dazu, dass die Pipeline nach dem Upgrade gelöscht wird. Die Pipeline führt aus, die manuell aufbewahrt oder von einer Version beibehalten wurde, wird 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.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 von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder höher direkt installieren.

Hinweis

Das Datenmigrationstool ist für Azure DevOps Server 2020.0.2 ca. drei Wochen nach dieser Version verfügbar. 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 nicht über die Schaltfläche "Weiter ausführen" überspringen. Zuvor wurde die Schaltfläche "Weiter ausführen" nur für Projektsammlungsadministratoren aktiviert.

• Widerrufen Sie alle persönlichen Zugriffstoken, nachdem das Active Directory-Konto eines Benutzers deaktiviert ist.

Azure DevOps Server 2020.0.1 Patch 9 Releasedatum: 26. Januar 2022

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

• E-Mail-Benachrichtigungen wurden beim Verwenden des @mention Steuerelements in einem Arbeitselement nicht gesendet.
• Beheben Sie den FEHLER TF400813 beim Wechseln von Konten. Dieser Fehler beim Upgrade von TFS 2018 auf Azure DevOps Server 2020.0.1.
• Problem mit der Project Übersichtszusammenfassungsseite beheben, 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 namens ZIP, der C:\Program Files\{TFS Version Folder}\Search\zip sich im Remotedateiordner elasticsearch befindet.
4. Führen Sie auf dem Elasticsearch-Servercomputer aus Configure-TFSSearch.ps1 -Operation update .

SHA-256 Hash: B0C05A972C73F253154AEEB7605605EF2E596A96A96A96A96AE942D7A9DD81545E

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

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

• Lokalisierungsproblem für benutzerdefinierte Arbeitselemente layoutzustä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-Regelnauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

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

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

• 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 Project Einstellungen.
• Problem mit dem Testplan-Widget beheben. Der Testausführungsbericht zeigt einen falschen Benutzer auf Ergebnissen an.
• Problem mit der Project Übersichtszusammenfassungsseite beheben, die nicht geladen werden kann.
• Problem mit E-Mails beheben, die nicht gesendet werden, um das Produktupgrade zu bestätigen.

Azure DevOps Server 2020.0.1 Patch 6 Releasedatum: 14. September 2021

Patch 6 für Azure DevOps Server 2020.0.1 enthält Korrekturen für folgendes.

• Beheben sie Artifacts Download-/Uploadfehler.
• Problem mit inkonsistenten Testergebnissen beheben.

Azure DevOps Server 2020.0.1 Patch 5 Releasedatum: 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.
• Änderte den Browserverlauf, um Dateien anstelle des Stamm-Repositorys anzuzeigen.
• Problem mit E-Mail-Übermittlungsaufträgen für einige Arbeitselementtypen beheben.

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

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

• Problem mit dem Datenimport beheben. Der Datenimport dauerte lange zeit für Kunden, die viele veraltete Testfälle haben. Dies war aufgrund von Verweisen, 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 Releasedatum: 11. Mai 2021

Wir haben einen Patch für Azure DevOps Server 2020.0.1 veröffentlicht, der folgendes behoben hat.

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

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

Überprüfen der Installation

• Option 1: Ausführen devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe ist die Datei, die oben im 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 Releasedatum: 13. April 2021

Hinweis

Wenn Sie Azure DevOps Server 2020 haben, sollten Sie zuerst Azure DevOps Server 2020.0.1 aktualisieren. Installieren Sie nach dem 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 behoben hat.

• CVE-2021-27067 : Veröffentlichung von Informationen
• CVE-2021-28459: Erhöhung der Berechtigung

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 über Azure DevOps Server 2020.0.1 verfügen, sollten Sie Azure DevOps Server 2020.0.1 Patch 2 installieren.

Überprüfen der Installation

• Option 1: 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 ihrem Computer herunter und installieren Sie sie.

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

npm install -g tfx-cli

4. Erstellen Sie ein persönliches Zugriffstoken mit 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 die Ausnahme "System.OutOfMemoryException" 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 Settings -> Apps & Features Sie zum 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.

Nach dem Upgrade von Azure DevOps Server 2019 Update 1.1 auf Azure DevOps Server 2020 RC1 konnten Sie dateien in der Repos, Pipelines und wiki der Web-UI nicht 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 für Boards Backlog
• Hinzufügen des Filters "Übergeordnete Arbeitsaufgabe" zum Task board und sprint backlog
• Neue Web-Ui für Azure Repos Startseiten
• Domänenübergreifende Verzweigungsrichtlinienverwaltung
• Seite "Neuer Testplan"
• Umfassende Bearbeitung für Codewikiseiten
• 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 Azure DevOps CLI

Im Februar haben wir die Azure DevOps-Erweiterung für Azure CLI eingeführt. Mit der Erweiterung können Sie mit Azure DevOps aus der Befehlszeile 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 Flow Diagramm (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" zugreifen, indem Sie auf die entsprechende 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.

Zuletzt angezeigte Tags beim Markieren eines Arbeitselements

Wenn Sie ein Arbeitselement markieren, wird die option automatisch abgeschlossen jetzt bis zu fünf Ihrer zuletzt verwendeten Tags angezeigt. Dies erleichtert das Hinzufügen der richtigen Informationen zu Ihren Arbeitselementen.

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. So können Sie beispielsweise Produktbesitzern die Möglichkeit gewähren, die Priorität Ihrer Features festzulegen, während sie für alle anderen Schreibgeschützte Elemente verwendet werden.

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 bebereicht, sodass Sie verschiedene Werte für das gleiche Feld für jeden Arbeitselementtyp verwalten können.

Neuer URL-Parameter für Arbeitselemente

Teilen Sie Links zu Arbeitselementen mit dem Kontext Ihres Boards oder Backlogs mit unserem neuen URL-Parameter für Arbeitselemente. Sie können nun ein Arbeitselementdialogfeld in Ihrer Board-, Backlog- oder Sprinterfahrung ö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 hatten, wenn Sie den Link freigegeben haben!

Erwähnen Sie Personen, Arbeitselemente und PRs in Textfeldern

Wie wir Ihr Feedback hören, hören wir, dass Sie die Möglichkeit haben, Personen, Arbeitselemente und PRs im Arbeitselementbeschreibungsbereich (und andere HTML-Felder) auf dem Arbeitselement und nicht nur in Kommentaren zu erwähnen. Manchmal arbeiten Sie mit einer Person an einem Arbeitselement zusammen, oder möchten Sie eine PR in Ihrer Arbeitselementbeschreibung hervorheben, aber keine Möglichkeit haben, diese Informationen hinzuzufügen. Jetzt können Sie Personen, Arbeitselemente und PRs in allen langen Textfeldern auf dem Arbeitselement 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 Arbeitselementfeldern werden E-Mail-Benachrichtigungen wie für Kommentare generiert.
• Geben Sie zum Verwenden von Arbeitselement-Erwähnungen das # Zeichen ein, gefolgt von der Arbeitselement-ID oder dem Titel. #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

Eine unserer Hauptziele besteht darin, die Arbeitselemente für Teams mehr Zusammenarbeit zu machen. Kürzlich haben wir eine Umfrage auf Twitter durchgeführt, um herauszufinden, welche Zusammenarbeitsfeatures Sie in Diskussionen über das Arbeitselement wünschen. Mit Reaktionen auf Kommentare gewannen wir die Umfrage, daher fügen wir sie hinzu! Hier sind die Ergebnisse der Twitter-Umfrage.

Sie können Reaktionen zu jedem Kommentar hinzufügen, und es gibt zwei Möglichkeiten, Ihre Reaktionen hinzuzufügen – das 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 eine oder zwei. Um Ihre Reaktion zu entfernen, klicken Sie auf die Reaktion unten in Ihrem Kommentar, und sie wird entfernt. Unten sehen Sie die Erfahrung, eine Reaktion hinzuzufügen, sowie wie die Reaktionen auf einen Kommentar aussehen.

Anheften Azure Boards Berichte an das Dashboard

Im Sprint 155 Update enthalten wir aktualisierte Versionen der CFD- und Geschwindigkeitsberichte. Diese Berichte sind auf der Registerkarte "Analyse" von Boards und Backlogs verfügbar. Jetzt können Sie die Berichte direkt an Ihr Dashboard anheften. Wenn Sie die Berichte anheften möchten, zeigen Sie auf den Bericht, wählen Sie die Auslassungspunkte "..." aus. menu, and Copy to Dashboard.

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

Rollupspalten zeigen Statusbalken und/oder Summen numerischer Felder oder absteigender Elemente in einer Hierarchie an. Absteigende Elemente entsprechen allen untergeordneten Elementen in der Hierarchie. Ein oder mehrere Rollupspalten können einem Produkt- oder Portfolio-Backlog hinzugefügt werden.

Hier zeigen wir beispielsweise Den Fortschritt durch Arbeitselemente an, die Statusleisten 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 für Das Taskboard

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

Unterstützung für benutzerdefinierte Felder in Rollup-Spalten

Das Rollup kann jetzt auf jedem Feld erfolgen, einschließlich benutzerdefinierter Felder. Wenn Sie eine Rollupspalte hinzufügen, können Sie weiterhin eine Rollupspalte aus der Schnellliste auswählen, wenn Sie jedoch auf numerische Felder, die nicht Teil der Feldprozessvorlage sind, ausführen möchten, können Sie ihre eigenen wie folgt konfigurieren:

1. Klicken Sie auf Ihrem Backlog auf "Spaltenoptionen". Klicken Sie dann im Panel auf "Spalte "Rollup hinzufügen" und konfigurieren Sie benutzerdefinierte Rollups.

   

2. Wählen Sie zwischen Der Statusleiste und der Summe aus.
3. Wählen Sie einen Arbeitselementtyp oder eine Backlog-Ebene aus (in der Regel aggregiert backlogs mehrere Arbeitselementtypen).
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 Bereich "Spaltenoptionen", 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 wie gewünscht hinzu.

Neue Regel zum Ausblenden von Feldern in einem Arbeitselementformular basierend auf bedingungsbasierten Bedingungen

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 hier in der Dokumentation.

Benutzerdefinierte Arbeitselementbenachrichtigungseinstellungen

Das Aktuelle an Arbeitselementen, die für Sie oder Ihr Team relevant sind, ist unglaublich wichtig. Es hilft Teams, zusammenzuarbeiten und mit Projekten nachzuverfolgen und sicherzustellen, dass alle richtigen Parteien beteiligt sind. Es gibt jedoch unterschiedliche Investitionen in unterschiedliche Anstrengungen, und wir glauben, dass dies in Ihrer Fähigkeit zum Folgen des Status eines Arbeitselements widerzuspiegeln ist.

Wenn Sie zuvor einem Arbeitselement folgen und Benachrichtigungen zu änderungen erhalten möchten, erhalten Sie E-Mail-Benachrichtigungen für alle Änderungen, die an das Arbeitselement vorgenommen wurden. Nachdem wir Ihr Feedback berücksichtigt haben, machen wir ein Arbeitselement flexibler für alle Beteiligten. Jetzt wird neben der Schaltfläche "Folgen " in der oberen rechten Ecke des Arbeitselements eine neue Einstellungsschaltfläche angezeigt. Dies führt Sie zu einem Popup, mit dem Sie Die folgenden Optionen konfigurieren können.

Aus Benachrichtigungs-Einstellungen können Sie aus drei Benachrichtigungsoptionen auswählen. Zunächst können Sie vollständig abgemeldet werden. Zweitens können Sie vollständig abonnieren, wo Sie Benachrichtigungen für alle Änderungen der Arbeitselemente erhalten. Schließlich können Sie auswählen, dass Sie für einige der wichtigsten Änderungen der Arbeitselemente benachrichtigt werden können. Sie können nur eine oder alle drei Optionen auswählen. Dadurch können Teammitglieder Arbeitselemente auf höherer Ebene befolgen und nicht von jeder einzelnen Änderung abgelenkt werden, die vorgenommen wird. Mit diesem Feature entfernen 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 im Arbeitselementformular zu veröffentlichen. Dieses Steuerelement verknüpft Ihre Arbeitselemente mit einer Version und ermöglicht Es Ihnen, einfach zu verfolgen, wo Ihr Arbeitselement bereitgestellt wurde. Weitere Informationen finden Sie hier.

Importieren von Arbeitselementen aus einer CSV-Datei

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

Hinzufügen eines übergeordneten Felds zu Arbeitselementkarten

Übergeordneter Kontext ist jetzt in Ihrem Kanban-Board als neues Feld für Arbeitselementkarten verfügbar. Sie können nun das Übergeordnete Feld zu Ihren Karten hinzufügen, um die Notwendigkeit zu 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. Um das übergeordnete Feld hinzuzufügen, verwenden Sie die Ansicht "Spaltenoptionen" .

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 als Kommentar in der PR-Übersicht angezeigt. Sie können Details der Abdeckungsinformationen für jede Codezeile anzeigen, die in der Datei diff-Ansicht geändert wird.

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

Filtern von Kommentarbenachrichtigungen aus Pullanforderungen

Kommentare in Pull-Anforderungen können aufgrund von Benachrichtigungen häufig viele Geräusche generieren. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie nach Kommentaralter, Kommentar, gelöschter Kommentar, erwähnten Benutzern, Pull-Anforderungsautor, 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.

Dienst-Hooks für Pull-Anforderungskommentare

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 verschoben werden. Die Dateinamenüberprüfungsrichtlinie blockiert Pushs, die dem angegebenen Muster entsprechen.

Beheben von Arbeitselementen mithilfe von Schlüsselwörtern

Sie können jetzt Arbeitselemente über Commits beheben, die an den Standardzweig vorgenommen wurden, indem Sie Tastenwörter wie Fix, Korrekturen oder Festes verwenden. Sie können z. B. schreiben - "diese Änderung behoben #476" in Ihrer Commitnachricht und arbeitselement #476 wird abgeschlossen, wenn der Commit in den Standardzweig verschoben oder zusammengeführt wird. Weitere Details finden Sie hier in der Dokumentation.

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

Beim Konfigurieren von Azure Pipelines aus dem AKS Deployment Center haben wir zuvor eine Azure Resource Manager-Verbindung verwendet. Diese Verbindung hatte Zugriff auf den gesamten Cluster und nicht nur den Namespace, für den die Pipeline konfiguriert wurde. Mit diesem Update verwenden unsere Pipelines die dienstkontobasierte Authentifizierung, um eine Verbindung mit dem Cluster herzustellen, 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 zum Hinzufügen von Verzweigungsschutz im Repos Project Einstellungen.

Neue Webplattform-Konvertierungs-Landingpages

Wir haben die Repos Startseiten-Benutzeroberfläche 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 im Entwurfszustand aktualisiert werden. Sie können E-Mails speziell für Entwürfe von Pullanfragen abrufen oder E-Mails aus Entwürfen 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 zur Überprüfung haben, können Sie verstehen, wo Sie zuerst Maßnahmen ergreifen sollten, schwierig sein. Um die Aktionensfähigkeit von Pullanforderungsanforderungen zu verbessern, können Sie jetzt mehrere benutzerdefinierte Abfragen auf der Pull-Anforderungslistenseite mit mehreren neuen Optionen erstellen, um nach dem Entwurfszustand zu filtern. Diese Abfragen erstellen separate und faltbare Abschnitte auf Ihrer Pullanforderungsseite zusätzlich zu "Erstellt von mir" und "Zugewiesen an 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 Sammlungsstartseite. Wenn Sie zu einer Pullanforderung zurückkehren möchten, können Sie sie kennzeichnen und oben in der Liste angezeigt. Schließlich werden Pullanforderungen, die auf autovervollständigen festgelegt wurden, mit einer Pille gekennzeichnet, die "Autovervollständigen" 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 zu einer einzigen Erfahrung zusammen. Es ist mobil freundlich und bietet verschiedene Verbesserungen, 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 Oberfläche enthalten:

• Anzeigen und Verwalten mehrerer Phasen
• Ausführen der Genehmigungspipeline
• Scrollen Sie zurück in Protokollen, während eine Pipeline noch ausgeführt wird
• Integrität pro Verzweigung einer Pipeline.

Kontinuierliche Bereitstellung in YAML

Wir freuen uns, Azure Pipelines YAML CD-Features bereitzustellen. Wir bieten jetzt eine einheitliche YAML-Erfahrung an, damit Sie jede Ihrer Pipelines so konfigurieren können, dass sie CI, CD oder CI und CD zusammen ausführen können. 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üfen 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 Oberfläche 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 über den Release-Hub

Das Handeln über ausstehende Genehmigungen wurde erleichtert. 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.

Bitbucket-Integration und weitere Verbesserungen bei den ersten Schritten mit Pipelines

Die erste Schritte des Assistenten für Pipelines wurde aktualisiert, um mit Bitbucket-Repositorys zu arbeiten. Azure Pipelines analysieren jetzt den Inhalt Ihres Bitbucket-Repositorys und empfehlen eine YAML-Vorlage, um Sie zu erhalten.

Eine häufige Frage mit dem Assistenten für die ersten Schritte war die Möglichkeit, die generierte Datei umzubenennen. Derzeit wird sie 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 der azure-pipelines.yml Datei auf eine andere Verzweigung, da Sie das Erstellen einer Pullanforderung aus dieser Verzweigung überspringen können.

Vorschau vollständig analysierter YAML-Dokumente ohne Commit 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ächen für Dienstverbindungen

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Dienstverbindungen zu verwalten. Diese Updates machen die Dienstverbindungsumgebung 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.

azCLI-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, um eine Pipeline zu erstellen, 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 Unterstützung zum Verbrauch 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 vielen 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 die Ausführung automatisch mit allen Arbeitselementen (die über die Commits in diesem Code abgeleitet werden). Wenn Sie die Arbeitsaufgabe öffnen, können Sie die Ausführung sehen, in der der Code für diese Arbeitsaufgabe erstellt wurde. Um dies zu konfigurieren, verwenden Sie den Einstellungsbereich einer Pipeline.

Phase abbrechen in einer mehrstufigen YAML-Pipelineausführung

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

Fehlgeschlagene Wiederholungsphasen

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

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

Dies kann Ihnen dabei helfen, Zeit auf verschiedene Arten zu sparen. Wenn Sie beispielsweise mehrere Aufträge in einer Phase ausführen, möchten Sie möglicherweise 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 erfolgreichen Aufträge nicht erneut ausführen. Ein weiteres Beispiel: Eine Bereitstellungsphase ist aufgrund der flakigen Netzwerkverbindung möglicherweise fehlgeschlagen. Durch erneutes Wiederholen dieser Phase 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 z. B. keine Phase wiederholen, die Sie explizit abbrechen. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.

Genehmigungen in mehrstufigen YAML-Pipelines

Ihre YAML CD-Pipelines können manuelle Genehmigungen enthalten. Infrastrukturbesitzer können ihre Umgebungen schützen und manuelle Genehmigungen vor einer Phase in jeder Pipeline durchführen, die für sie bereitgestellt wird. Mit vollständiger Trennung von Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie die manuelle Abmeldung für die Bereitstellung in einer bestimmten Pipeline sicher und erhalten zentrale Kontrolle beim Anwenden derselben Prüfungen über alle Bereitstellungen auf die Umgebung.

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

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

Zuvor war die Timeoutgrenze für Gate-Timeouts in Freigabepipelinen drei Tage. Mit diesem Update wurde das Timeoutlimit auf 15 Tage erhöht, um Tore mit längerer Dauer zuzulassen. Wir haben auch die Häufigkeit des Tors auf 30 Minuten erhöht.

Neue Buildimagevorlage für Dockerfile

Wenn Sie zuvor eine neue Pipeline für eine Dockerfile-Datei in der neuen Pipelineerstellung erstellen, empfiehlt sich die Vorlage, das Image an eine Azure Container Registry zu übertragen und in einem 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 übertragen werden 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 haben jetzt eine neue Azure Pipelines Aufgabe Azure App Service Einstellungen, die das Konfigurieren dieser Einstellungen in Massen mithilfe der JSON-Syntax in Ihrer Web-App oder eines seiner Bereitstellungsplätze unterstützt. Diese Aufgabe kann zusammen mit anderen App-Dienstaufgaben verwendet werden, um Web-Apps, Funktions-Apps oder andere containerisierte App-Dienste bereitzustellen, zu verwalten 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 produktionsbezogener Konfiguration zu überprüfen, bevor die App tatsächlich von einem Stagingplatz in einen Produktionsplatz ausgetauscht wird. Dies würde auch sicherstellen, dass der Ziel-/Produktionsplatz keine Ausfallzeiten hat.

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

• Start Swap with Preview – Initiiert einen Swap mit einer Vorschau (Mehrphasentausch) und wendet die Zielplatzkonfiguration (z. B. die Produktionsplatzkonfiguration) auf den Quellplatz an.
• Vollständiger Swap with Preview – Wenn Sie bereit sind, den ausstehenden Swap abzuschließen, wählen Sie die Aktion "Fertig tauschen mit Vorschau" aus.
• Tausch mit Vorschau abbrechen – Um einen ausstehenden Swap abzubrechen, wählen Sie "Swap with Preview" 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 Releasepipelineebene verfügbar. Sie wurden nun auch auf Stufe stufe 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. Durch das Konfigurieren von Genehmigungen für Ihre Ressourcen wie Umgebungen, Dienstverbindungen und Agentpools werden Sie sicher sein, dass alle Pipelineausführungen, die Ressourcen verwenden, zuerst eine Genehmigung erfordern.

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

Unterstützung von Containerstrukturtests in Azure Pipelines

Die Nutzung von Containern in Anwendungen steigt und somit die Notwendigkeit robuster Tests und Validierungen. Azure Pipelines bietet jetzt Unterstützung für Containerstrukturtests. Dieses Framework bietet eine bequeme und leistungsstarke Möglichkeit, den Inhalt und die Struktur Ihrer Container zu überprüfen.

Sie können die Struktur eines Bilds basierend auf vier Testkategorien überprüfen, die zusammen ausgeführt werden können: Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests. Sie können die Ergebnisse in der Pipeline verwenden, um entscheidungen zu treffen. Testdaten sind in der Pipeline verfügbar, die mit einer Fehlermeldung ausgeführt werden, um Ihnen bei der besseren Problembehandlung zu helfen.

Eingeben der Konfigurationsdatei und Bilddetails

Testdaten und Zusammenfassung

Pipelinedekortoren für Freigabepipelinen

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 denen Kunden diese verwenden, um die Schritte in ihren Aufträgen zentral zu steuern. Wir erweitern nun auch die Unterstützung für die Veröffentlichungspipeline. Sie können Erweiterungen erstellen, um Schritte für den neuen Beitragspunkt hinzuzufügen, und sie werden allen Agentaufträgen in Releasepipelinen hinzugefügt.

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

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

CD-Funktionen für Ihre mehrstufigen YAML-Pipelines

Sie können nun Artefakte nutzen, die von Ihrer CI-Pipeline veröffentlicht wurden, und Pipeline-Abschlusstrigger 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.

Hier ist 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 Artefakte herunterladen, die von Ihrer Pipelineressource mithilfe der - download Aufgabe veröffentlicht wurden.

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

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

Orchestrate canary deployment strategy on environment for Kubernetes

Einer der wichtigsten Vorteile der kontinuierlichen Bereitstellung von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu übertragen. Dadurch erhalten Sie die Möglichkeit, schnell auf Änderungen der Geschäftsanforderungen zu reagieren. 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 der Kanarischen 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 dem Rollout auf mehr Servern in Ihrer Infrastruktur beginnen und mehr 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 stellt zunächst die Änderungen mit 10 % Pods bereit, gefolgt von 20 % während der Überwachung der Integrität während postRouteTraffic. Wenn alles gut geht, wird es auf 100 % gefördert.

Wir suchen nach frühzeitigen Feedback zur Unterstützung der VM-Ressource in Umgebungen und die Durchführung einer rollierenden Bereitstellungsstrategie auf mehreren Computern. 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 Ressourcenpause für Genehmigungen verwenden, bevor die Phase mit der Nutzung der Ressource beginnt. Es ist üblich, dass SOX-basierte Anwendungsbesitzer den Anforderunger der Bereitstellung daran hindern, ihre eigenen Bereitstellungen zu genehmigen.

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

ACR als erstklassige Pipelineressource

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

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

Verbesserungen zum Auswerten der Artefakteüberprüfungsrichtlinie in Pipelines

Wir haben die Überprüfung der Bewertungsartefakte verbessert, um das Hinzufügen von Richtlinien aus einer Liste der Nicht-Box-Richtliniendefinitionen zu vereinfachen. Die Richtliniendefinition wird automatisch generiert und der Überprüfungskonfiguration hinzugefügt, die bei Bedarf aktualisiert werden kann.

Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag

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

Beim Ausführen von Bereitstellungsstrategien können Sie auf Ausgabevariablen in allen Aufträgen zugreifen, indem Sie die folgende Syntax verwenden.

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

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

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

Erfahren Sie mehr darüber, wie Sie eine Ausgabevariable mit mehreren Stellen festlegen

Vermeiden des Rollbacks kritischer Änderungen

In klassischen Releasepipelinen ist es üblich, sich auf geplante Bereitstellungen für regelmäßige Updates zu verlassen. Wenn Sie jedoch über einen kritischen Fix verfügen, können Sie entscheiden, eine manuelle Bereitstellung außerhalb des Bandes zu starten. Ältere Versionen bleiben weiterhin geplant. Dies stellte eine Herausforderung dar, da die manuelle Bereitstellung zurückgesetzt wird, wenn die Bereitstellungen pro Zeitplan fortgesetzt werden. Viele von Ihnen haben dieses Problem gemeldet und wir haben es jetzt behoben. Mit dem Fix werden alle älteren geplanten Bereitstellungen in der Umgebung abgebrochen, wenn Sie eine Bereitstellung manuell starten. Dies gilt nur, wenn die Warteschlangeoption als "Neueste Bereitstellen und Abbrechen anderer Personen" ausgewählt ist.

Vereinfachte Ressourcenautorisierung in YAML-Pipelines

Eine Ressource ist alles, was von einer Pipeline verwendet wird, die sich außerhalb der Pipeline befindet. Ressourcen müssen autorisiert werden, bevor sie verwendet werden können. Zuvor ist es bei der Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline mit einem Fehler bei der Ressourcenautorisierung fehlgeschlagen. Sie mussten die Ressourcen auf 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 erleichtern jetzt die Verwaltung von Ressourcenautorisierungen. Anstatt die Ausführung fehlschlagen zu können, wartet die Ausführung auf Berechtigungen für die Ressourcen am Anfang der Phase, in der die Ressource verbraucht wird. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource über die Sicherheitsseite autorisieren.

Auswerten der Artefaktprüfung

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

Aktualisierungen der 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 Verbindung mit einem niedrigeren Bereich für den Dienst auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich auszuführen. Jetzt haben wir die Filterung von Dienstverbindungen hinzugefügt, um niedrigere Dienstverbindungen basierend auf dem ausgewählten Bereitstellungsbereich herauszufiltern.

ReviewApp in Environment

ReviewApp stellt jede Pullanforderung aus Ihrem Git-Repository in einer dynamischen Umgebungsressource bereit. Prüfer können sehen, wie diese Änderungen aussehen und mit anderen abhängigen Diensten arbeiten, bevor sie in den Hauptzweig 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.

Nachfolgend sehen Sie einen Beispiel-YAML-Codeausschnitt zur Verwendung von ReviewApp unter Umgebungen.

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

Sammeln von automatischen und vom Benutzer angegebenen Metadaten aus der Pipeline

Jetzt können Sie die automatische und benutzerdefinierte Metadatensammlung aus Pipelineaufgaben aktivieren. Mithilfe von Metadaten können Sie artefaktrichtlinie in einer Umgebung erzwingen, indem Sie die Bewertung der Artefaktüberprüfung verwenden.

VM-Bereitstellungen mit Umgebungen

Eine der am häufigsten angeforderten Features in Umgebungen war VM-Bereitstellungen. Mit diesem Update aktivieren wir die Ressource "Virtueller Computer" in Umgebungen. Sie können jetzt Bereitstellungen auf mehreren Computern orchestrieren 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 vorantreiben. Darüber hinaus können Sie den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.

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

Beispiel: Unterhalb des Rollbereitstellungsupdates bis zu fünf Ziele in jeder Iteration. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl macht die Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, ohne die Ziele zu berücksichtigen, 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 den Download auswählen, indem Sie die Aufgabe "Pipelineartefakt herunterladen" angeben. Es gibt einige bekannte Lücken in diesem Feature. Wenn Sie beispielsweise eine Phase wiederholen, wird die Bereitstellung auf allen virtuellen Computern 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 hat seit einiger Zeit die Bereitstellungen unterstützt, die mit manuellen Genehmigungen gesteuert werden. Mit den neuesten Verbesserungen haben Sie jetzt zusätzliche Kontrolle über Ihre Bereitstellungen. Zusätzlich zu Genehmigungen können Ressourcenbesitzer jetzt 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 warten Sie dann, bis 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 für Ihre Ressourcen 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 vom 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 einer Umgebung oder einer Dienstverbindung eine Genehmigung hinzufügen, warten alle mehrstufigen Pipelines, die die Ressource verwenden, automatisch am Anfang der Phase auf die Genehmigung. 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 mindern. Um darauf zuzugreifen, klicken Sie auf die Einstellung "Fortlaufende Übermittlung" in einem virtuellen Azure-Computer. Im Konfigurationsbereich werden Sie aufgefordert, Details zum Azure DevOps Projekt auszuwählen, in dem die Pipeline erstellt wird, die Bereitstellungsgruppe, die Buildpipeline, die das zu bereitstellende Paket veröffentlicht, und die Bereitstellungsstrategie Ihrer Wahl. In Zukunft wird eine voll funktionsfähige Pipeline konfiguriert, die das ausgewählte Paket auf diesem virtuellen Computer bereitstellt.

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

Laufzeitparameter

Mit Laufzeitparametern können Sie mehr Kontrolle darüber 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:

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

Weitere Informationen zu Laufzeitparametern finden Sie in der Dokumentation hier.

Verwenden von Schlüsselworten in Pipelines

Derzeit können Pipelines in Vorlagen integriert werden, um die Wiederverwendung und Reduzierung der Kesselplatte zu fördern. Die Gesamtstruktur der Pipeline wurde weiterhin durch die 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. Außerdem haben wir die Pipelineparameter mit Datentypen erweitert, um die von Ihnen bereitgestellten Hooks zu löschen.

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 zur 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 verwendet, um beim Starten einer neuen Ausführung zu zusätzlichen Eingaben aufzufordern.

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 _settable at queue time_gekennzeichnet ist.

Hinweis

Diese Einstellung ist in vorhandenen Sammlungen standardmäßig deaktiviert, ist aber 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 verschiedenen Teilen Ihrer Pipeline zu erhalten. Mit diesem Update haben wir ein paar vordefinierte Variablen zu einem Bereitstellungsauftrag hinzugefügt. Diese Variablen werden automatisch vom System festgelegt, auf den spezifischen Bereitstellungsauftrag festgelegt und schreibgeschützt.

• Environment.Id – Die ID der Umgebung.
• Environment.Name – Der Name der Umgebung, die von dem Bereitstellungsauftrag ausgerichtet 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 gezielt verwendet wird.

Auschecken mehrerer Repositorys

Pipelines sich häufig auf mehrere Repositorys verlassen. 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-, GitHub- und Bitbucket-Cloud-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

MyServiceConnectionverweist 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 Compose Dateien in eine Kubernetes-Ressource um.

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

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

Unterstützung für Clusteradministratoranmeldeinformationen in der HelmDeploy-Aufgabe

Zuvor verwendet die HelmDeploy-Aufgabe die Clusterbenutzeranmeldeinformationen für Bereitstellungen. Dies führte zu interaktiven Anmeldeaufforderungen und fehlgeschlagenen 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 Compose Aufgabe

Ein neues Feld wurde in der aufgabe Docker Compose 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.

GitHub Aufgabenerweiterungen freigeben

Wir haben mehrere Verbesserungen an der aufgabe "GitHub Release" 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.

Dienst Mesh Schnittstellenbasierte Canarybereitstellungen 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-basierte Canary-Bereitstellungen zur KubernetesManifest-Aufgabe hinzugefügt.

Die Dienst-Mesh Interface-Abstraktion 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 verwendet, um Azure DevOps zurückzurufen. 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 diese Kontrolle für klassische Release- oder YAML-Pipelines verfügt. Mit diesem Update wird eine Auflistungseinstellung eingeführt, um jeden Auftrag zu erzwingen, um ein projektbezogenes Token abzurufen, unabhängig davon, was in der Pipeline konfiguriert ist. Wir haben auch die Einstellung auf Projektebene hinzugefügt. Jetzt haben alle neuen Projekte und Auflistungen, die Sie erstellen, diese Einstellung automatisch aktiviert.

  Hinweis

  Die Auflistungseinstellung überschreibt die Projekteinstellung.

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

• Einschränken des Builddienst-Repos-Bereichszugriffs

  Durch die Einschränkung des Zugriffstokens kann Azure Pipelines nun den Repositoryzugriff auf nur die für eine YAML-basierte Pipeline erforderlichen Repos beschrä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 die gesamte Auflistung gut.

  Dieses Feature ist standardmäßig für neue Projekte und Sammlungen aktiviert. Für vorhandene Sammlungen müssen Sie es in Sammlungen Einstellungen>> Pipelines Einstellungen 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 gewähren wir eine Reihe von Berechtigungen für das Zugriffstoken, eine dieser Berechtigungen ist Warteschlange-Builds. Mit diesem Update haben wir diese Berechtigung für das Zugriffstoken entfernt. Wenn Ihre Pipelines diese Berechtigung benötigen, können Sie sie explizit dem Project Builddienstkonto oder Project Sammlungs-Builddienstkonto gewähren, abhängig von dem von Ihnen verwendeten Token.

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

Schrittausrichtung und Befehlsisolation

Azure Pipelines unterstützt die Ausführung von Aufträgen entweder in Containern oder auf dem Agenthost. Zuvor wurde ein gesamter Auftrag auf einen dieser beiden Ziele festgelegt. Jetzt 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 die Schritte mit und dem Zugriff auf Dienste aus dem Agent kommunizieren, sind nicht betroffen, indem Schritte in einem Container getrennt werden. Daher führen wir auch einen Befehlseinschränkungsmodus ein, den Sie mit Schrittzielen verwenden können. Das Aktivieren beschränkt die Dienste, die ein Schritt vom Agent anfordern kann. Es kann keine Protokolle mehr anfügen, Artefakte hochladen und bestimmte andere Vorgänge ausführen.

Nachfolgend finden Sie ein umfassendes Beispiel, in dem Die Schritte im Host in einem Auftragscontainer und in einem anderen Container ausgeführt werden:

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 einer Aufgabe überschrieben werden und nachgelagerte Aufgaben den neuen Wert aufnehmen. Mit diesem Update erhöhen wir die Sicherheit um Pipelinevariablen, 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 Sicherheit der Dienstverbindung nur über vordefinierte Azure DevOps Gruppen wie Endpunktadministratoren und Endpunkt-Creators verwaltet werden.

Als Teil dieser Arbeit haben wir die neuen Rollen "Reader", "User", "Creator" und "Administrator" eingeführt. Sie können diese Rollen über die Seite "Dienstverbindungen" in Ihrem Projekt festlegen und diese werden von den einzelnen Verbindungen geerbt. Und in jeder Dienstverbindung können Sie die Vererbung aktivieren oder deaktivieren und die Rollen im Bereich der Dienstverbindung außer Kraft 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 mit Ihren Projekten sicher und sicher freigeben.

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 Übersichtsansicht der Pipeline können Sie sehen:

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

  

• Die Commits , die von der Pipeline verbraucht werden. Sie können auch die Aufschlüsselung der Commits durch jede Ressource finden, 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 anzeigen, die für die Umgebung bereitgestellt wird.

Unterstützung für große Testanlagen

Mit der Veröffentlichung von Testergebnissen in Azure Pipelines können Sie Testergebnisse veröffentlichen, wenn Tests ausgeführt werden, um eine umfassende Testberichterstellung und Analyseerfahrung bereitzustellen. Bis jetzt gab es eine Grenze 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, mit denen Sie alle verfügbaren Daten zur Problembehandlung ihrer fehlgeschlagenen Tests haben können.

Möglicherweise wird die Aufgabe "VSTest" oder "Testergebnisse veröffentlichen" angezeigt, die 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 zu verwenden. ​

Um dieses Problem zu beheben, empfehlen wir, die Firewall für ausgehende Anforderungen auf https://*.vstmrblob.vsassets.io. Hier finden Sie Problembehandlungsinformationen in der Dokumentation. ​

Hinweis

Dies ist nur erforderlich, wenn Sie selbst gehostete Azure Pipelines-Agents verwenden und hinter einer Firewall sind, die ausgehenden Datenverkehr filtert. Wenn Sie Microsoft-gehostete Agents in der Cloud verwenden oder keinen ausgehenden Netzwerkdatenverkehr filtern, müssen Sie keine Aktion ausführen.

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 auf 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 ein neuer Zweig erstellt wird und wenn dieser Zweig keine Änderungen aufweist. Betrachten Sie die folgenden Beispiele:

• Sie verwenden die Webschnittstelle, um eine neue Verzweigung basierend auf einem vorhandenen Zweig zu erstellen. Dadurch würde sofort ein neuer CI-Build ausgelöst, wenn der Zweigfilter dem Namen des neuen Zweigs entspricht. Dies ist unerwünscht, da der Inhalt des neuen Zweigs im Vergleich zu dem vorhandenen Zweig identisch ist.
• Sie verfügen über ein Repository mit zwei Ordnern – App und Dokumente. Sie richten einen Pfadfilter für CI ein, um mit "app" übereinzugleichen. Mit anderen Worten, Sie möchten keinen neuen Build erstellen, wenn eine Änderung an Dokumente verschoben wurde. Sie erstellen eine neue Verzweigung lokal, nehmen einige Änderungen an Dokumenten vor, und pushen Sie diese Verzweigung dann auf den Server. Wir haben verwendet, um einen neuen CI-Build auszulösen. Dies ist unerwünscht, da Sie explizit aufgefordert haben, nach Änderungen im Ordner "Dokumente" zu suchen. Aufgrund der Art und Weise, wie wir ein neues Branch-Ereignis behandelt haben, würde es jedoch aussehen, dass auch eine Änderung an dem App-Ordner vorgenommen wurde.

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

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

Ausgabevariablen können jetzt in phasenweise in einer YAML-basierten Pipeline verwendet werden. Dadurch 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 Phase und deren Aufträge sind ebenfalls verfügbar.

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

Hinweis

Standardmäßig hängt jede Phase in einer Pipeline von der 1 vor 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 on 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 Feature-Flag-Rolloutschritte 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 Freigabe als Artefaktquelle

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

Wenn Sie in der Releasepipelinedefinition auf "Artefakte hinzufügen" klicken, finden Sie den neuen GitHub Quelltyp "Release". Sie können die Dienstverbindung und das GitHub-Repo bereitstellen, um die GitHub Release zu nutzen. Sie können auch eine Standardversion für die GitHub Version auswählen, um die neueste, bestimmte Tagversion zu nutzen oder zur Erstellungszeit der Version auszuwählen. Sobald eine GitHub Version verknüpft ist, wird sie automatisch heruntergeladen und in Ihren Releaseaufträgen verfügbar gemacht.

Terraform-Integration mit Azure Pipelines

Terraform ist ein Open-Source-Tool 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 Experimente kontinuierlich durchlaufen, lernen und bereitstellen können, indem Sie die Experimente kontinuierlich verwalten und gleichzeitig alle DevOps Vorteile von Azure Pipelines gewinnen.

Sie können die Erweiterung für Google Analytics-Experimente aus dem Marketplace herunterladen.

Aktualisierte ServiceNow-Integration mit Azure Pipelines

Die Azure Pipelines-App für ServiceNow hilft bei der Integration 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 Sammlungen 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 Zugriffsstufe oder Äquivalent verfügbar. Alles andere, einschließlich der Registerkarte "Ausführen", sollte von einem Benutzer mit der Zugriffsstufe "Standard" exercisierbar sein.

Aufgaben

Auf 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 zutreffend, ohne den Testfall über den Testläufer ausführen zu müssen. Das Ergebnis kann für einen oder mehrere Testpunkte an einem Schritt markiert werden.
• Testpunkte ausführen: Mit dieser Option können Sie die Testfälle ausführen, indem Sie jeden Testschritt einzeln durchlaufen und sie mit einem Testläufer übergeben/fehlschlagen. Je nachdem, welche Anwendung Sie testen, können Sie den "Web Runner" verwenden, um eine "Webanwendung" oder den "Desktop-Runner" zum Testen von Desktop- und/oder Webanwendungen zu testen. Sie können auch die Option "Ausführen mit Optionen" aufrufen, um einen Build anzugeben, für den die Tests ausgeführt werden sollen.
• Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte "Ausführen" mit "Spaltenoptionen" sichtbar sind. Die Liste der für die Auswahl verfügbaren Spalten ist testpunkten zugeordnet, z. B. "Ausführen von", "Zugewiesener Tester", "Konfiguration" usw.
• Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte "Ausführen" im Vollbildmodus anzeigen.
• Filtern: Mithilfe der Filterleiste können Sie die Liste der Testpunkte mithilfe der Felder "Testfalltitel", "zugewiesen", "Status", "Testergebnis", "Tester" und "Konfiguration" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.

Kontextmenüoptionen

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

• Testergebnis markieren: Identisch mit oben, ermöglicht es Ihnen, das Ergebnis der Testpunkte schnell zu markieren – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend.
• Testpunkte ausführen: Wie oben können Sie die Testfälle über Testläufer ausführen.
• Zurücksetzen des Tests auf aktiv: Mit dieser Option können Sie das Testergebnis auf aktiv zurücksetzen, wodurch das letzte Ergebnis des Testpunkts ignoriert wird.
• Ö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.
• Tester zuweisen: Mit dieser Option können Sie den Testpunkten Testpunkte für die Testausführung zuweisen.
• Testergebnis anzeigen: Mit dieser Option können Sie die neuesten Testergebnisdetails anzeigen, einschließlich des Ergebnisses der einzelnen Testschritte, hinzugefügten Kommentare oder Fehler.
• Ausführungsverlauf anzeigen: 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

Dieser out-of-the-box-Bericht hilft Ihnen, die Ausführung und den Status eines oder mehrerer Test Plans in einem Projekt nachzuverfolgen. 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 geben.

Artifacts

Hinweis

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

Lizenzausdrücke und eingebettete Lizenzen

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

Wenn Sie auf den Link klicken, 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 an einem Ort in Azure Artifacts 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 von Azure Pipelines mithilfe von Authentifizierungsaufgaben mit geringem Gewicht authentifizieren. 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 nicht in Ihrer Pipeline verwenden. Jetzt können Sie Skripts Ihres eigenen Designs in Ihrer Pipeline YAML verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben ausführen. 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. Auf diese Weise können Sie die vollständige Kontrolle über den Aufruf von Befehlen haben und die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration vereinfachen. Weitere Informationen finden Sie in der Dokumentation zu NuGet, npm, PIP, Twine und Maven-Authentifizierungsaufgaben.

Verbesserungen beim Laden der Feedseite

Wir freuen uns, bekanntzugeben, dass wir die Ladezeit der Feedseite verbessert haben. Im Durchschnitt haben sich die Ladezeiten von Feedseiten um 10 % verringert. Die größten Feeds haben die größte Verbesserung der 99. Prozentile 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 jeden im Internet ohne Authentifizierung verfügbar, unabhängig davon, ob sie sich in Ihrer Sammlung befinden oder sogar bei 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 unterschiedlichen Auflistungen innerhalb eines AAD-Mandanten

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

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

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

Azure Artifacts Feeds im Visual Studio Paket-Manager

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

Aktualisiert Verbinden, um die Feederfahrung zu erhalten

Das Dialogfeld "Verbinden zum Feed" ist der Einstieg in die Verwendung von Azure Artifacts. 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 vorgelagerter Unterstützung

Die öffentliche Vorschau öffentlicher Feeds hat eine großartige Einführung und Feedback erhalten. In dieser Version haben wir zusätzliche Features auf allgemeine Verfügbarkeit erweitert. Jetzt können Sie einen öffentlichen Feed als vorgelagerte Quelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl vor als auch von privaten und projektbezogenen Feeds wechseln können.

Erstellen von projektbezogenen Feeds aus dem Portal

Wenn wir öffentliche Feeds veröffentlicht haben, haben wir auch projektbezogene Feeds veröffentlicht. Bis jetzt könnten projektbezogene Feeds über REST-APIs oder durch Erstellen eines öffentlichen Feeds erstellt und dann das private Projekt gedreht werden. Jetzt können Sie projektbezogene Feeds direkt im Portal aus einem beliebigen Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch sehen, welche Feeds Projekt sind und welche sammlungsbezogenen Elemente 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 Artifacts Feeds speichern und liefern. Dies hat uns geholfen, bis zu 10-faltige Latenz für einige der am höchsten verwendeten APIs für npm zu erreichen.

Verbesserungen in Bezug auf die Barrierefreiheit

Wir haben Korrekturen bereitgestellt, um Barrierefreiheitsprobleme auf unserer Feeds-Seite zu beheben. Die Korrekturen umfassen Folgendes:

• Erstellen von Feedfunktionen
• Benutzeroberfläche für globale Feedeinstellungen
• Verbinden zum Feed

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 Project Dashboardtyp aus.

Ein Project Dashboard 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