Versionshinweise zu Azure DevOps Server 2020
| Entwicklercommunity Systemanforderungen | Lizenzbedingungen | DevOps Blog | SHA-1 Hashes
In diesem Artikel finden Sie Informationen zum neuesten Release für Azure DevOps Server.
Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server-Bereitstellung finden Sie unter Azure DevOps Server Anforderungen. Um Azure DevOps-Produkte herunterzuladen, besuchen Sie die Seite Azure DevOps Server Downloads.
Das direkte Upgrade auf Azure DevOps Server 2020 wird ab Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2019 durchführen. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps lokal.
Sicheres Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020
Azure DevOps Server 2020 wird ein neues Aufbewahrungsmodell für die Pipelineausführung (Build) eingeführt, das auf Projektebeneneinstellungen basiert.
Azure DevOps Server 2020 behandelt die Buildaufbewahrung basierend auf Aufbewahrungsrichtlinien auf Pipelineebene unterschiedlich. Bestimmte Richtlinienkonfigurationen führen dazu, dass Pipelineausführungen nach dem Upgrade gelöscht werden. Pipelineausführungen, die manuell aufbewahrt wurden oder von einem Release beibehalten werden, werden nach dem Upgrade nicht gelöscht.
Lesen Sie unseren Blogbeitrag für weitere Informationen zum sicheren Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020.
Azure DevOps Server Veröffentlichungsdatum von Update 0.2 Patch 3 2020: 8. August 2023
Wir haben einen Patch für Azure DevOps Server 2020 Update 0.2 veröffentlicht, der Fehlerbehebungen für folgendes enthält.
- Es wurde ein Fehler behoben, der das Pushen von Paketen beim Upgrade von 2018 oder früher beeinträchtigt hat.
Azure DevOps Server 2020 Update 0.2 Patch 2 Veröffentlichungsdatum: 13. Juni 2023
Wir haben einen Patch für Azure DevOps Server 2020 Update 0.2 veröffentlicht, der Fehlerbehebungen für folgendes enthält.
- Es wurde ein Fehler behoben, der das Pushen von Paketen beim Upgrade von 2018 oder früher beeinträchtigt hat.
Azure DevOps Server 2020 Update 0.2 Patch 1 Veröffentlichungsdatum: 18. Oktober 2022
Wir haben einen Patch für Azure DevOps Server 2020 Update 0.2 veröffentlicht, der Fehlerbehebungen für folgendes enthält.
- Beheben Sie das Problem, dass neu hinzugefügte AD-Identitäten nicht in der Identitätsauswahl des Sicherheitsdialogs angezeigt werden.
- Behebung eines Problems mit dem Filter "Angefordert nach Mitglied der Gruppe" in den Webhookeinstellungen.
- Behebung eines Fehlers bei Gated-Check-In-Builds, wenn für die Organisationseinstellungen für die Pipeline ein Auftragsautorisierungsbereich konfiguriert war, der als Auftragsautorisierungsbereich auf das aktuelle Projekt für Pipelines ohne Release beschränken konfiguriert war.
Azure DevOps Server Veröffentlichungsdatum 2020.0.2: 17. Mai 2022
Azure DevOps Server 2020.0.2 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.0.2 direkt installieren oder ein Upgrade von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder höher durchführen.
Hinweis
Das Datenmigrationstool wird etwa drei Wochen nach dieser Version für Azure DevOps Server 2020.0.2 verfügbar sein. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.
Dieses Release enthält Fehlerbehebungen für Folgendes:
Buildwarteschlange kann mithilfe der Schaltfläche "Weiter ausführen" nicht übersprungen werden. Bisher war die Schaltfläche "Weiter ausführen" nur für Projektsammlungsadministratoren aktiviert.
Widerrufen aller persönlichen Zugriffstoken, nachdem das Active Directory-Konto eines Benutzers deaktiviert wurde.
Azure DevOps Server Veröffentlichungsdatum von Patch 9 2020.0.1: 26. Januar 2022
Wir haben einen Patch für Azure DevOps Server 2020.0.1 veröffentlicht, der Fehlerbehebungen für folgendes enthält.
- Email Benachrichtigungen wurden nicht gesendet, wenn das @mention Steuerelement in einem Arbeitselement verwendet wurde.
- Beheben Sie den TF400813-Fehler beim Wechseln des Kontos. Dieser Fehler ist beim Upgrade von TFS 2018 auf Azure DevOps Server 2020.0.1 aufgetreten.
- Problem behoben, bei dem die Zusammenfassungsseite "Projektübersicht" nicht geladen wurde.
- Verbesserung der Active Directory-Benutzersynchronisierung.
- Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.
Installationsschritte
- Aktualisieren Sie den Server mit Patch 9.
- Ü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). - Führen Sie den Updatebefehl
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation updatewie 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.
- Aktualisieren Sie den Server mit Patch 9.
- Ü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). - Kopieren Sie den Inhalt des Ordners „zip“ unter
C:\Program Files\{TFS Version Folder}\Search\zipin den Remotedateiordner von Elasticsearch. - Führen Sie
Configure-TFSSearch.ps1 -Operation updateauf dem Elasticsearch-Servercomputer aus.
SHA-256 Hash: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E
Azure DevOps Server Veröffentlichungsdatum von Patch 8 2020.0.1: 15. Dezember 2021
Patch 8 für Azure DevOps Server 2020.0.1 enthält Fehlerbehebungen für folgendes:
- Lokalisierungsproblem für benutzerdefinierte Arbeitselemente Layoutzustände.
- Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
- Problem mit abgeschnittenen Konsolenprotokollen, wenn mehrere identische Links in einer Zeile vorhanden sind.
- Problem mit der Auswertung von NOTSAMEAS-Regeln, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.
Azure DevOps Server Veröffentlichungsdatum von Patch 7 2020.0.1: 26. Oktober 2021
Patch 7 für Azure DevOps Server 2020.0.1 enthält Fehlerbehebungen für folgendes:
- Bisher konnten Azure DevOps Server nur Verbindungen mit GitHub Enterprise Server herstellen. Mit diesem Patch können Projektadministratoren Verbindungen zwischen Azure DevOps Server und Repositorys auf GitHub.com erstellen. Sie finden diese Einstellung auf der Seite GitHub-Verbindungen unter Projekteinstellungen.
- Beheben Sie das Problem mit dem Testplan-Widget. Im Testausführungsbericht wurde ein falscher Benutzer für die Ergebnisse angezeigt.
- Problem behoben, bei dem die Zusammenfassungsseite "Projektübersicht" nicht geladen wurde.
- Behebung eines Problems mit E-Mails, die nicht zur Bestätigung des Produktupgrades gesendet wurden.
Azure DevOps Server Veröffentlichungsdatum von Patch 6 2020.0.1: 14. September 2021
Patch 6 für Azure DevOps Server 2020.0.1 enthält Fehlerbehebungen für folgendes:
- Fehler beim Herunterladen/Hochladen von Artefakten beheben.
- Beheben Sie das Problem mit inkonsistenten Testergebnisdaten.
Azure DevOps Server Veröffentlichungsdatum von Patch 5 2020.0.1: 10. August 2021
Patch 5 für Azure DevOps Server 2020.0.1 enthält Fehlerbehebungen für folgendes:
- Fehler bei der Builddefinitionsbenutzeroberfläche behoben.
- Browserverlauf wurde geändert, um Dateien anstelle des Stammrepositorys anzuzeigen.
- Problem mit E-Mail-Übermittlungsaufträgen für einige Arbeitselementtypen behoben.
Azure DevOps Server Veröffentlichungsdatum von Patch 4 2020.0.1: 15. Juni 2021
Patch 4 für Azure DevOps Server 2020.0.1 enthält Fehlerbehebungen für folgendes:
- Problem mit dem Datenimport behoben. Der Datenimport hat bei Kunden mit vielen veralteten Testfällen lange gedauert. Dies ist auf Verweise zurückzuführen, die die Größe der
tbl_testCaseReferencesTabelle erhöht haben. Mit diesem Patch haben wir Verweise auf veraltete Testfälle entfernt, um den Datenimportprozess zu beschleunigen.
Azure DevOps Server Veröffentlichungsdatum von Patch 3 2020.0.1: 11. Mai 2021
Wir haben einen Patch für Azure DevOps Server 2020.0.1 veröffentlicht, der Folgendes behebt.
- Inkonsistente Testergebnisdaten bei Verwendung von Microsoft.TeamFoundation.TestManagement.Client.
Wenn Sie über Azure DevOps Server 2020.0.1 verfügen, sollten Sie Azure DevOps Server 2020.0.1 Patch 3 installieren.
Überprüfen der Installation
Option 1: Führen Sie
devops2020.0.1patch3.exe CheckInstallaus, devops2020.0.1patch3.exe die Datei ist, die über den obigen Link heruntergeladen wird. In der Ausgabe des Befehls wird entweder angegeben, dass der Patch installiert wurde oder nicht installiert ist.Option 2: Überprüfen Sie die Version der folgenden Datei:
[INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 wird standardmäßig inc:\Program Files\Azure DevOps Server 2020installiert. Nach der Installation von Azure DevOps Server 2020.0.1 Patch 3 lautet die Version 18.170.31228.1.
Azure DevOps Server 2020.0.1 Patch 2 Veröffentlichungsdatum: 13. April 2021
Hinweis
Wenn Sie über Azure DevOps Server 2020 verfügen, sollten Sie zuerst ein Update auf Azure DevOps Server 2020.0.1 ausführen. Installieren Sie Azure DevOps Server 2020.0.1 Patch 2020.0.1.
Wir haben einen Patch für Azure DevOps Server 2020.0.1 veröffentlicht, der Folgendes behebt.
- CVE-2021-27067 : Veröffentlichung von Informationen
- CVE-2021-28459: Rechteerweiterung
Um Korrekturen für diesen Patch zu implementieren, müssen Sie die unten aufgeführten Schritte für die allgemeine Patchinstallation ausführen, die Aufgabeninstallationen AzureResourceGroupDeploymentV2 und AzureResourceManagerTemplateDeploymentV3 .
Allgemeine Patchinstallation
Wenn Sie über Azure DevOps Server 2020.0.1 verfügen, sollten Sie Azure DevOps Server 2020.0.1 Patch 2 installieren.
Überprüfen der Installation
Option 1: Führen Sie
devops2020.0.1patch2.exe CheckInstallaus, devops2020.0.1patch2.exe die Datei ist, die über den obigen Link heruntergeladen wird. In der Ausgabe des Befehls wird entweder angegeben, dass der Patch installiert wurde oder nicht installiert ist.Option 2: Überprüfen Sie die Version der folgenden Datei:
[INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 wird standardmäßig inc:\Program Files\Azure DevOps Server 2020installiert. Nach der Installation von Azure DevOps Server 2020.0.1 Patch 2 lautet die Version 18.170.31123.3.
Installation des AzureResourceGroupDeploymentV2-Tasks
Hinweis
Alle unten genannten Schritte müssen auf einem Windows-Computer ausgeführt werden.
Installieren
Extrahieren Sie das AzureResourceGroupDeploymentV2.zip-Paket in einen neuen Ordner auf Ihrem Computer. Beispiel: D:\tasks\AzureResourceGroupDeploymentV2.
Laden Sie die Node.js 14.15.1 und npm (im Node.js-Download enthalten) auf Ihren Computer herunter, und installieren Sie diese Komponenten.
Öffnen Sie eine Eingabeaufforderung im Administratormodus, und führen Sie den folgenden Befehl aus, um tfx-cli zu installieren.
npm install -g tfx-cli
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.
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
- 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>*
Installation des AzureResourceManagerTemplateDeploymentV3-Tasks
Hinweis
Alle unten genannten Schritte müssen auf einem Windows-Computer ausgeführt werden.
Installieren
Extrahieren Sie das AzureResourceManagerTemplateDeploymentV3.zip-Paket in einen neuen Ordner auf Ihrem Computer. Beispiel: D:\tasks\AzureResourceManagerTemplateDeploymentV3.
Laden Sie Node.js 14.15.1 und npm (im Node.js Download enthalten) entsprechend Ihrem Computer herunter, und installieren Sie sie.
Öffnen Sie eine Eingabeaufforderung im Administratormodus, und führen Sie den folgenden Befehl aus, um tfx-cli zu installieren.
npm install -g tfx-cli
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.
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
- Führen Sie den folgenden Befehl aus, um den Task auf den Server hochzuladen. Verwenden Sie den Pfad der extrahierten ZIP-Datei aus Schritt 1.
~$ tfx build tasks upload --task-path *<Path of the extracted package>*
Azure DevOps Server 2020.0.1 Patch 1 Veröffentlichungsdatum: 9. Februar 2021
Wir haben einen Patch für Azure DevOps Server 2020.0.1 veröffentlicht, der Folgendes behebt. Weitere Informationen finden Sie im Blogbeitrag.
- Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht
- Fügen Sie Fixes ein, die mit Azure DevOps Server 2020 Patch 2 veröffentlicht wurden.
Azure DevOps Server Veröffentlichungsdatum von Patch 3 2020: 9. Februar 2021
Wir haben einen Patch für Azure DevOps Server 2020 veröffentlicht, der Folgendes behebt. Weitere Informationen finden Sie im Blogbeitrag.
- Beheben des Problems, das in diesem Entwicklercommunity Feedbackticket gemeldet wurde| Schaltfläche "Neuer Testfall" funktioniert nicht
Azure DevOps Server Veröffentlichungsdatum 2020.0.1: 19. Januar 2021
Azure DevOps Server 2020.0.1 ist ein Rollup von Fehlerbehebungen. Sie können Azure DevOps Server 2020.0.1 direkt installieren oder ein Upgrade von einer vorhandenen Installation durchführen. Unterstützte Versionen für das Upgrade sind Azure DevOps Server 2020, Azure DevOps Server 2019 und Team Foundation Server 2012 oder höher.
Diese Version enthält Korrekturen für folgende Fehler:
- Beheben Sie ein Upgradeproblem aus Azure DevOps Server 2019, bei dem der Git-Proxy nach dem Upgrade möglicherweise nicht mehr funktioniert.
- Behebung der System.OutOfMemoryException-Ausnahme für Nicht-ENU-Sammlungen vor Team Foundation Server 2017 beim Upgrade auf Azure DevOps Server 2020. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
- Wartungsfehler aufgrund fehlender Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
- Fehler mit ungültigem Spaltennamen in Analytics beim Upgrade auf Azure DevOps Server 2020 behoben. Behebt das in diesem Entwicklercommunity Feedbackticket gemeldete Problem.
- Gespeicherte XSS beim Anzeigen von Testfallschritten in Testfallergebnissen.
- Fehler beim Upgradeschritt beim Migrieren von Punktergebnisdaten zu TCM.
Azure DevOps Server Veröffentlichungsdatum von Patch 2020: 12. Januar 2021
Wir haben einen Patch für Azure DevOps Server 2020 veröffentlicht, der Folgendes behebt. Weitere Informationen finden Sie im Blogbeitrag.
- Testlaufdetails zeigen keine Testschrittdetails für Testdaten an, die mithilfe der OpsHub-Migration migriert wurden
- Ausnahme für den Initialisierer für "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"
- Nicht beibehaltene Builds werden nach der Migration zu Azure DevOps Server 2020 sofort gelöscht.
- Beheben der Ausnahme des Datenanbieters
Azure DevOps Server 2020 Patch 1 Datum: 8. Dezember 2020
Wir haben einen Patch für Azure DevOps Server 2020 veröffentlicht, der Folgendes behebt. Weitere Informationen finden Sie im Blogbeitrag.
- CVE-2020-17145 : Sicherheitsrisiko durch Spoofing in Azure DevOps Server und Team Foundation Services
Azure DevOps Server Veröffentlichungsdatum 2020: 6. Oktober 2020
Azure DevOps Server 2020 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features der zuvor veröffentlichten Azure DevOps Server 2020 RC2.
Hinweis
Azure DevOps 2020 Server hat ein Problem mit der Installation einer der Assemblys, die vom Git Virtual File System (GVFS) verwendet werden.
Wenn Sie ein Upgrade von Azure DevOps 2019 (beliebiger Version) oder einem Azure DevOps 2020-Release candidate durchführen und in dasselbe Verzeichnis wie das vorherige Release installieren, wird die Assembly Microsoft.TeamFoundation.Git.dll nicht installiert. Sie können überprüfen, ob das Problem aufgetreten ist, indem Sie in <Install Dir>\Version Control Proxy\Web Services\binden Ordnern , <Install Dir>\Application Tier\TFSJobAgent und <Install Dir>\Tools nach suchenMicrosoft.TeamFoundation.Git.dll. Wenn die Datei fehlt, können Sie eine Reparatur ausführen, um die fehlenden Dateien wiederherzustellen.
Navigieren Sie zum Ausführen einer Reparatur auf dem Azure DevOps Server Computer/VM zuSettings -> Apps & Features, und führen Sie eine Reparatur auf Azure DevOps 2020 Server aus. Nach Abschluss der Reparatur können Sie den Computer/die VM neu starten.
Veröffentlichungsdatum Azure DevOps Server 2020 RC2: 11. August 2020
Azure DevOps Server 2020 RC2 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features des zuvor veröffentlichten Azure DevOps Server 2020 RC1.
Veröffentlichungsdatum der Azure DevOps Server RC1 2020: 10. Juli 2020
Wir haben Azure DevOps Server 2020 RC1 erneut veröffentlicht, um dieses Entwicklercommunity Feedbackticket zu beheben.
Zuvor konnten Sie nach dem Upgrade von Azure DevOps Server 2019 Update 1.1 auf Azure DevOps Server 2020 RC1 keine Dateien in den Repositorys, Pipelines und wiki der Webbenutzeroberfläche anzeigen. Es wurde eine Fehlermeldung angezeigt, die darauf hinweist, dass innerhalb dieses Bereichs der Seite ein unerwarteter Fehler aufgetreten ist. Sie können versuchen, diese Komponente neu zu laden oder die gesamte Seite zu aktualisieren. Mit dieser Version haben wir dieses Problem behoben. Weitere Informationen finden Sie im Blogbeitrag.
Azure DevOps Server Veröffentlichungsdatum 2020 RC1: 30. Juni 2020
Zusammenfassung der Neuerungen in Azure DevOps Server 2020
Azure DevOps Server 2020 bietet viele neue Features. Einige der Highlights sind unter anderem:
- Mehrstufige Pipelines
- Continuous deployment in YAML
- Nachverfolgen des Fortschritts übergeordneter Elemente mithilfe des Backlogs für rollup on Boards
- Hinzufügen des Filters "Übergeordnetes Arbeitselement" zum Taskboard und zum Sprintbacklog
- Neue Web-Benutzeroberfläche für Azure Repos Zielseiten
- Richtlinienverwaltung für repositoryübergreifende Filialen
- Seite "Neuer Testplan"
- Umfangreiche Bearbeitung für Codewiki-Seiten
- Berichte zu Pipelinefehlern und -dauer
Sie können auch zu einzelnen Abschnitten wechseln, um alle neuen Features für jeden Dienst anzuzeigen:
Allgemein
Allgemeine Verfügbarkeit der Azure DevOps CLI
Im Februar haben wir die Azure DevOps-Erweiterung für die Azure CLI eingeführt. Mit der Erweiterung können Sie über die Befehlszeile mit Azure DevOps interagieren. Wir haben Ihr Feedback gesammelt, das uns half, die Erweiterung zu verbessern und weitere Befehle hinzuzufügen. Wir freuen uns nun mitteilen zu können, dass die Erweiterung allgemein verfügbar ist.
Weitere Informationen zur Azure DevOps CLI finden Sie in der Dokumentation hier.
Verwenden des Veröffentlichungsprofils zum Bereitstellen von Azure WebApps für Windows über das Deployment Center
Jetzt können Sie die profilbasierte Veröffentlichungsauthentifizierung verwenden, um Ihre Azure WebApps für Windows im Bereitstellungscenter bereitzustellen. Wenn Sie über die Berechtigung zum Bereitstellen in einer Azure WebApp für Windows mithilfe des Veröffentlichungsprofils verfügen, können Sie die Pipeline mithilfe dieses Profils in den Deployment Center-Workflows einrichten.
Boards
Hinzufügen des Filters "Übergeordnetes Arbeitselement" zum Taskboard und zum Sprintbacklog
Sowohl dem Sprint-Board als auch dem Sprint-Backlog wurde ein neuer Filter hinzugefügt. Dadurch können Sie Backlogelemente auf Anforderungsebene (erste Spalte links) nach ihrem übergeordneten Element filtern. Im folgenden Screenshot haben wir beispielsweise die Ansicht so gefiltert, dass nur Benutzergeschichten angezeigt werden, bei denen das übergeordnete Element "Mein großes Feature" ist.
Verbessern der Fehlerbehandlung – erforderliche Felder für Fehler/Aufgabe
Wenn Sie im Kanban-Board in der Vergangenheit ein Arbeitselement von einer Spalte in eine andere verschoben haben, in der der Zustand die Feldregeln geändert hat, zeigt die Karte nur eine rote Fehlermeldung an, die Sie dazu zwingt, das Arbeitselement zu öffnen, um die Grundursache zu verstehen. In Sprint 170 haben wir die Benutzeroberfläche verbessert, sodass Sie jetzt auf die rote Fehlermeldung klicken können, um die Details des Fehlers anzuzeigen, ohne das Arbeitselement selbst öffnen zu müssen.
Live-Neuladen des Arbeitselements
Früher, wenn ein Arbeitselement aktualisiert und ein zweites Teammitglied Änderungen an demselben Arbeitselement vorgenommen hat, hat der zweite Benutzer seine Änderungen verloren. Solange Sie beide unterschiedliche Felder bearbeiten, werden Liveupdates der Änderungen am Arbeitselement angezeigt.
Verwalten von Iterations- und Bereichspfaden über die Befehlszeile
Sie können nun Iterations- und Bereichspfade über die Befehlszeile verwalten, indem Sie die az boards iteration Befehle und az boards area verwenden. Beispielsweise können Sie Iterations- und Bereichspfade interaktiv über die CLI einrichten und verwalten oder das gesamte Setup mithilfe eines Skripts automatisieren. Weitere Informationen zu den Befehlen und der Syntax finden Sie in der Dokumentation hier.
Option "Übergeordnete Arbeitsaufgabe Spalte als Spalte"
Sie haben jetzt die Möglichkeit, das übergeordnete Element jedes Arbeitselements in Ihrem Produkt- oder Sprintbacklog anzuzeigen. Um dieses Feature zu aktivieren, wechseln Sie zu Spaltenoptionen für den gewünschten Backlog, und fügen Sie dann die Spalte Übergeordnetes Element hinzu.
Ändern des von einem Projekt verwendeten Prozesses
Ihre Tools sollten sich wie Ihr Team ändern. Sie können Jetzt Ihre Projekte von jeder vordefinierten Prozessvorlage zu einem anderen sofort einsatzbereiten Prozess wechseln. Beispielsweise können Sie Ihr Projekt von Agile zu Scrum oder Basic in Agile ändern. Die vollständige schrittweise Dokumentation finden Sie hier.
Ausblenden von benutzerdefinierten Feldern im Layout
Sie können nun benutzerdefinierte Felder im Formularlayout ausblenden, wenn Sie Ihren Prozess anpassen. Das Feld ist weiterhin über Abfragen und REST-APIs verfügbar. Dies ist nützlich für die Nachverfolgung zusätzlicher Felder, wenn Sie in andere Systeme integrieren.
Erhalten Sie Einblicke in die Integrität Ihres Teams mit drei neuen Azure Boards Berichten
Sie können nicht korrigieren, was nicht angezeigt wird. Daher möchten Sie den Zustand und die Integrität ihrer Arbeitsprozesse genau im Auge behalten. Mit diesen Berichten erleichtern wir Ihnen das Nachverfolgen wichtiger Metriken mit minimalem Aufwand in Azure Boards.
Die drei neuen interaktiven Berichte sind Burndown, Kumulatives Flussdiagramm (CFD) und Velocity. Die Berichte werden auf der neuen Registerkarte "Analyse" angezeigt.
Metriken wie Sprint-Burndown, Arbeitsfluss und Teamgeschwindigkeit geben Ihnen einblick in den Fortschritt Ihres Teams und helfen Ihnen bei der Beantwortung von Fragen wie:
- Wie viel Arbeit bleibt in diesem Sprint? Sind wir auf dem richtigen Weg, es abzuschließen?
- Welcher Entwicklungsschritt dauert am längsten? Können wir etwas dagegen tun?
- Wie viel Arbeit sollten wir basierend auf vorherigen Iterationen für den nächsten Sprint planen?
Hinweis
Die zuvor in den Headern angezeigten Diagramme wurden durch diese erweiterten Berichte ersetzt.
Die neuen Berichte sind vollständig interaktiv und ermöglichen es Ihnen, sie an Ihre Bedürfnisse anzupassen. Sie finden die neuen Berichte auf der Registerkarte Analytics in jedem Hub.
Das Burndowndiagramm finden Sie unter dem Sprints-Hub .
Auf die CFD- und Velocity-Berichte kann über die Registerkarte Analyse unter Boards und Backlogs zugegriffen werden, indem Sie auf die entsprechenden Karte klicken.
Mit den neuen Berichten haben Sie mehr Kontrolle und Informationen zu Ihrem Team. Hier einige Beispiele:
- Die Berichte Sprint Burndown und Velocity können so festgelegt werden, dass sie die Anzahl der Arbeitselemente oder die Summe der verbleibenden Arbeit verwenden.
- Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne sich auf die Projekttermine zu auswirken. Wenn Ihr Team also normalerweise den ersten Tag jeder Sprintplanung verbringt, können Sie jetzt das Diagramm anpassen, um dies widerzuspiegeln.
- Das Burndown-Diagramm verfügt jetzt über ein Wasserzeichen, das Wochenenden anzeigt.
- Mit dem CFD-Bericht können Sie Boardspalten wie Design entfernen, um den Fokus auf den Ablauf zu erhalten, den die Teams steuern.
Hier sehen Sie ein Beispiel für den CFD-Bericht, der den Flow für die letzten 30 Tage des Stories-Backlogs anzeigt.
Das Geschwindigkeitsdiagramm kann jetzt für alle Backlogebenen nachverfolgt werden. Beispielsweise können Sie jetzt sowohl Features als auch Epics hinzufügen, während vor dem vorherigen Diagramm nur Anforderungen unterstützt wurden. Hier sehen Sie ein Beispiel für einen Geschwindigkeitsbericht für die letzten 6 Iterationen des Features-Backlogs.
Anpassen von Taskboardspalten
Wir freuen uns, ihnen mitteilen zu können, dass wir eine Option hinzugefügt haben, mit der Sie die Spalten auf dem Taskboard anpassen können. Sie können jetzt die Spalten hinzufügen, entfernen, umbenennen und neu anordnen.
Um die Spalten auf Ihrem Taskboard zu konfigurieren, wechseln Sie zu Spaltenoptionen.
Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert.
Umschalten, um abgeschlossene untergeordnete Arbeitselemente im Backlog anzuzeigen oder auszublenden
Häufig möchten Sie beim Verfeinern des Backlogs nur Elemente anzeigen, die noch nicht abgeschlossen wurden. Jetzt können Sie abgeschlossene untergeordnete Elemente im Backlog anzeigen oder ausblenden.
Wenn der Umschalter aktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand angezeigt. Wenn die Umschaltfläche deaktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand aus dem Backlog ausgeblendet.
Die neuesten Tags, die beim Markieren eines Arbeitselements angezeigt werden
Beim Taggen eines Arbeitselements zeigt die Option automatisch vervollständigt jetzt bis zu fünf Ihrer zuletzt verwendeten Tags an. Dies erleichtert das Hinzufügen der richtigen Informationen zu Ihren Arbeitselementen.
Schreibgeschützte und erforderliche Regeln für die Gruppenmitgliedschaft
Mit Arbeitselementregeln können Sie bestimmte Aktionen für Arbeitselementfelder festlegen, um deren Verhalten zu automatisieren. Sie können eine Regel erstellen, um ein Feld basierend auf der Gruppenmitgliedschaft auf schreibgeschützt oder erforderlich festzulegen. Beispielsweise können Sie Produktbesitzern die Möglichkeit geben, die Priorität Ihrer Features festzulegen, während sie für alle anderen schreibgeschützt werden.
Anpassen von Systemauswahllistenwerten
Sie können jetzt die Werte für jede Systemauswahlliste (mit Ausnahme des Felds Grund) anpassen, z. B. Schweregrad, Aktivität, Priorität usw. Die Auswahllistenanpassungen sind so definiert, dass Sie unterschiedliche Werte für dasselbe Feld für jeden Arbeitselementtyp verwalten können.
Neuer URL-Parameter für Arbeitselemente
Teilen Sie Links zu Arbeitselementen mit dem Kontext Ihres Boards oder Backlogs mit unserem neuen Arbeitselement-URL-Parameter. Sie können jetzt ein Arbeitselementdialogfeld auf Ihrem Board, Backlog oder Sprint öffnen, indem Sie den Parameter ?workitem=[ID] an die URL anfügen.
Jeder, mit dem Sie den Link teilen, wird dann mit demselben Kontext landen, den Sie beim Teilen des Links hatten!
Personen, Arbeitselemente und PRs in Textfeldern erwähnen
Während wir Ihr Feedback gehört haben, haben wir erfahren, dass Sie Personen, Arbeitselemente und PRs im Arbeitsbereichsbeschreibungsbereich (und anderen HTML-Feldern) für das Arbeitselement und nicht nur in Kommentaren Erwähnung möchten. Manchmal arbeiten Sie mit jemandem an einem Arbeitselement zusammen oder möchten einen PR in Ihrer Arbeitselementbeschreibung hervorheben, hatten aber keine Möglichkeit, diese Informationen hinzuzufügen. Jetzt können Sie Personen, Arbeitselemente und PRs in allen langen Textfeldern des Arbeitselements Erwähnung.
Hier sehen Sie ein Beispiel.
- Um Personenerwähnungen zu verwenden, geben Sie das @ Zeichen und den Namen der Person ein, die Sie Erwähnung möchten. @mentions in Arbeitselementfeldern werden E-Mail-Benachrichtigungen wie für Kommentare generiert.
- Um Arbeitselementerwähnungen zu verwenden, geben Sie das # Zeichen gefolgt von der Arbeitselement-ID oder dem Titel ein. #mentions erstellt eine Verknüpfung zwischen den beiden Arbeitselementen.
- Um PR-Erwähnungen zu verwenden, fügen Sie eine ! gefolgt von Ihrer PR-ID oder Ihrem Namen hinzu.
Reaktionen auf Diskussionskommentare
Eines unserer Standard Ziele ist es, die Arbeitselemente für Teams kollaborativer zu gestalten. Kürzlich haben wir eine Umfrage auf Twitter durchgeführt, um herauszufinden, welche Zusammenarbeitsfunktionen Sie in Diskussionen über das Arbeitselement wünschen. Reaktionen auf Kommentare haben die Umfrage gewonnen, also fügen wir sie hinzu! Hier sind die Ergebnisse der Twitter-Umfrage.
Sie können Reaktionen zu jedem Kommentar hinzufügen, und es gibt zwei Möglichkeiten, Ihre Reaktionen hinzuzufügen: das Smileysymbol in der oberen rechten Ecke eines Kommentars sowie am unteren Rand eines Kommentars neben vorhandenen Reaktionen. Sie können alle sechs Reaktionen hinzufügen, wenn Sie möchten, oder nur eine oder zwei. Um Ihre Reaktion zu entfernen, klicken Sie auf die Reaktion am unteren Rand Ihres Kommentars, und sie wird entfernt. Im Folgenden sehen Sie die Erfahrungen beim Hinzufügen einer Reaktion und wie die Reaktionen auf einen Kommentar aussehen.
Anheften Azure Boards Berichte an die Dashboard
Im Sprint 155-Update haben wir aktualisierte Versionen der CFD- und Velocity-Berichte aufgenommen. Diese Berichte sind auf der Registerkarte Analyse unter Boards und Backlogs verfügbar. Jetzt können Sie die Berichte direkt an Ihr Dashboard anheften. Um die Berichte anzuheften, zeigen Sie auf den Bericht, und wählen Sie die Auslassungspunkte "..." und In Dashboard kopieren.
Nachverfolgen des Fortschritts übergeordneter Elemente mithilfe des Backlogs für rollup on Boards
Rollupspalten zeigen Statusleisten und/oder Gesamtsummen numerischer Felder oder untergeordneter Elemente innerhalb einer Hierarchie an. Nachfolgerelemente entsprechen allen untergeordneten Elementen innerhalb der Hierarchie. Einem Produkt- oder Portfoliobacklog können mindestens eine Rollupspalte hinzugefügt werden.
Im folgenden Screenshot sehen Sie z. B. die Spalte Fortschritt nach allen Arbeitselementen, in der Statusleisten für Vorgängerarbeitselemente basierend auf dem Prozentsatz der geschlossenen Nachfolgerelemente angezeigt werden. Untergeordnete Elemente für Epics enthalten alle untergeordneten Features und ihre untergeordneten oder untergeordneten Arbeitselemente. Untergeordnete Elemente für Features umfassen alle untergeordneten Benutzergeschichten und ihre untergeordneten Arbeitselemente.
Taskboard-Liveupdates
Ihr Taskboard wird jetzt automatisch aktualisiert, wenn Änderungen auftreten! Wenn andere Teammitglieder Karten auf dem Taskboard verschieben oder neu anordnen, wird Ihr Board automatisch mit diesen Änderungen aktualisiert. Sie müssen nicht mehr F5 drücken, um die neuesten Änderungen anzuzeigen.
Unterstützung für benutzerdefinierte Felder in Rollupspalten
Ein Rollup kann jetzt für jedes Feld durchgeführt werden, einschließlich benutzerdefinierter Felder. Wenn Sie eine Rollupspalte hinzufügen, können Sie dennoch eine Rollupspalte aus der Schnellliste auswählen. Wenn Sie jedoch ein Rollup für numerische Felder ausführen möchten, die nicht Teil der out-of-the-box-Prozessvorlage sind, können Sie Ihre eigene wie folgt konfigurieren:
- Klicken Sie in Ihrem Backlog auf "Spaltenoptionen". Klicken Sie dann im Bereich auf "Rollupspalte hinzufügen" und dann auf Benutzerdefiniertes Rollup konfigurieren.
- Wählen Sie zwischen Fortschrittsleiste und Gesamt aus.
- Wählen Sie einen Arbeitselementtyp oder eine Backlogebene aus (in der Regel werden mehrere Arbeitselementtypen aggregiert).
- Wählen Sie den Aggregationstyp aus. Anzahl der Arbeitselemente oder Summe. Für Summe müssen Sie das feld auswählen, das zusammengefasst werden soll.
- Über die Schaltfläche OK gelangen Sie zurück zum Spaltenoptionenbereich, in dem Sie Ihre neue benutzerdefinierte Spalte neu anordnen können.
Beachten Sie, dass Sie Ihre benutzerdefinierte Spalte nicht bearbeiten können, nachdem Sie auf OK geklickt haben. Wenn Sie eine Änderung vornehmen müssen, entfernen Sie die benutzerdefinierte Spalte, und fügen Sie eine weitere Spalte wie gewünscht hinzu.
Neue Regel zum Ausblenden von Feldern in einem Arbeitselementformular basierend auf einer Bedingung
Wir haben der geerbten Regel-Engine eine neue Regel hinzugefügt, mit der Sie Felder in einem Arbeitselementformular ausblenden können. Diese Regel blendet Felder basierend auf der Gruppenmitgliedschaft der Benutzer aus. Wenn der Benutzer beispielsweise zur Gruppe "Product Owner" gehört, können Sie ein entwicklerspezifisches Feld ausblenden. Weitere Informationen finden Sie in der Dokumentation hier.
Benachrichtigungseinstellungen für benutzerdefinierte Arbeitselemente
Es ist unglaublich wichtig, über Arbeitselemente auf dem Laufenden zu bleiben, die für Sie oder Ihr Team relevant sind. Es hilft Teams dabei, zusammenzuarbeiten und bei Projekten auf dem richtigen Weg zu bleiben, und stellt sicher, dass alle richtigen Parteien beteiligt sind. Allerdings haben verschiedene Akteure unterschiedliche Investitionen in unterschiedliche Anstrengungen, und wir glauben, dass sich dies in Ihrer Fähigkeit widerspiegeln sollte, die status eines Arbeitselements zu verfolgen.
Wenn Sie zuvor einem Arbeitselement folgen und Benachrichtigungen über vorgenommene Änderungen erhalten möchten, erhalten Sie E-Mail-Benachrichtigungen für alle änderungen, die am Arbeitselement vorgenommen wurden. Nachdem Wir Ihr Feedback berücksichtigt haben, machen wir das Befolgen eines Arbeitselements für alle Beteiligten flexibler. Nun wird eine neue Einstellungsschaltfläche neben der Schaltfläche Folgen in der oberen rechten Ecke des Arbeitselements angezeigt. Dadurch gelangen Sie zu einem Popupfenster, in dem Sie Ihre Folgeoptionen konfigurieren können.
Unter Benachrichtigungseinstellungen können Sie aus drei Benachrichtigungsoptionen auswählen. Zunächst können Sie vollständig abbestellt werden. Zweitens können Sie vollständig abonniert sein, wo Sie Benachrichtigungen für alle Änderungen an Arbeitselementen erhalten. Schließlich können Sie sich für einige der wichtigsten Änderungsereignisse für Arbeitselemente benachrichtigen lassen. Sie können nur eine oder alle drei Optionen auswählen. Dadurch können Teammitglieder Arbeitselemente auf höherer Ebene verfolgen und nicht von jeder einzelnen Vorgenommenen Änderung abgelenkt werden. Mit diesem Feature vermeiden wir unnötige E-Mails und ermöglichen Es Ihnen, sich auf die wichtigen Aufgaben zu konzentrieren.
Verknüpfen von Arbeitselementen mit Bereitstellungen
Wir freuen uns, die Bereitstellungssteuerung für das Arbeitselementformular freizugeben. Dieses Steuerelement verknüpft Ihre Arbeitselemente mit einem Release und ermöglicht es Ihnen, einfach nachzuverfolgen, wo Ihr Arbeitselement bereitgestellt wurde. Weitere Informationen finden Sie in der Dokumentation hier.
Importieren von Arbeitselementen aus einer CSV-Datei
Bisher war der Import von Arbeitselementen aus einer CSV-Datei von der Verwendung des Excel-Plug-Ins abhängig. In diesem Update bieten wir eine erstklassige Importerfahrung direkt aus Azure Boards, damit Sie neue oder vorhandene Arbeitselemente importieren oder aktualisieren können. Weitere Informationen finden Sie in der Dokumentation hier.
Hinzufügen eines übergeordneten Felds zu Arbeitselementkarten
Der übergeordnete Kontext ist jetzt in Ihrem Kanban-Board als neues Feld für Arbeitselementkarten verfügbar. Sie können jetzt das Feld Übergeordnetes Element zu Ihren Karten hinzufügen, ohne dass Problemumgehungen wie Tags und Präfixe verwendet werden müssen.
Hinzufügen eines übergeordneten Felds zu Backlog und Abfragen
Das übergeordnete Feld ist jetzt verfügbar, wenn Backlogs und Abfrageergebnisse angezeigt werden. Um das übergeordnete Feld hinzuzufügen, verwenden Sie die Ansicht Spaltenoptionen .
Repos
Code Coverage-Metriken und Branch-Richtlinie für Pull Requests
Sie können jetzt Code Coverage-Metriken für Änderungen in der Pull Request-Ansicht (PR) anzeigen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen durch automatisierte Tests angemessen getestet haben. Coverage status wird in der PR-Übersicht als Kommentar angezeigt. Sie können Details der Abdeckungsinformationen für jede Codezeile anzeigen, die in der Datei diff Ansicht geändert wird.
Darüber hinaus können Repositorybesitzer jetzt Code Coverage-Richtlinien festlegen und verhindern, dass große, ungetestete Änderungen in einem Branch zusammengeführt werden. Die gewünschten Abdeckungsschwellenwerte können in einer azurepipelines-coverage.yml Einstellungsdatei definiert werden, die im Stammverzeichnis des Repositorys eingecheckt wird, und die Abdeckungsrichtlinie kann mithilfe der vorhandenen Konfiguration einer Branchrichtlinie für zusätzliche Dienste in Azure Repos definiert werden.
Filtern von Kommentarbenachrichtigungen aus Pull Requests
Kommentare in Pull Requests können aufgrund von Benachrichtigungen häufig zu viel Rauschen führen. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie abonnieren, nach Kommentaralter, Kommentar, gelöschten Kommentar, erwähnten Benutzern, Pull Request-Autor, Zielbranch und Threadteilnehmern. Sie können diese Benachrichtigungsabonnements erstellen, indem Sie in der oberen rechten Ecke auf das Benutzersymbol klicken und zu Benutzereinstellungen navigieren.
Diensthooks für Pull Request-Kommentare
Sie können jetzt Diensthooks für Kommentare in einem Pull Request basierend auf Repository und Zielbranch erstellen.
Richtlinie zum Blockieren von Dateien mit angegebenen Mustern
Administratoren können jetzt eine Richtlinie festlegen, um zu verhindern, dass Commits basierend auf Dateitypen und Pfaden in ein Repository gepusht werden. Die Dateinamenüberprüfungsrichtlinie blockiert Pushvorgänge, die dem angegebenen Muster entsprechen.
Auflösen von Arbeitselementen über Commits mithilfe von Schlüsselwörtern
Sie können jetzt Arbeitselemente über Commits auflösen, die an die Standardbranch vorgenommen wurden, indem Sie Schlüsselwörter wie Fix, Fixes oder Fixed verwenden. Sie können z. B. "This change fixed #476" in Ihre Commitnachricht schreiben, und das Arbeitselement #476 wird abgeschlossen, wenn der Commit per Push übertragen oder in die Standardbranch zusammengeführt wird. Weitere Informationen finden Sie in der Dokumentation hier.
Granularität für automatische Prüfer
Bisher war beim Hinzufügen von Prüfern auf Gruppenebene zu einem Pull Request nur eine Genehmigung von der hinzugefügten Gruppe erforderlich. Jetzt können Sie Richtlinien festlegen, die mehr als einen Prüfer aus einem Team erfordern, um einen Pull Request zu genehmigen, wenn automatische Prüfer hinzugefügt werden. Darüber hinaus können Sie eine Richtlinie hinzufügen, um zu verhindern, dass Anforderer ihre eigenen Änderungen genehmigen.
Verwenden der dienstkontobasierten Authentifizierung zum Herstellen einer Verbindung mit AKS
Bisher haben wir beim Konfigurieren von Azure Pipelines über das AKS Deployment Center eine Azure Resource Manager-Verbindung verwendet. Diese Verbindung hatte Zugriff auf den gesamten Cluster und nicht nur auf den Namespace, für den die Pipeline konfiguriert wurde. Mit diesem Update verwenden unsere Pipelines die dienstkontobasierte Authentifizierung, um eine Verbindung mit dem Cluster herzustellen, sodass er nur Zugriff auf den namespace hat, der der Pipeline zugeordnet ist.
Vorschau von Markdowndateien in Pull Request Parallele diff
Sie können jetzt eine Vorschau der Darstellung einer Markdowndatei anzeigen, indem Sie die neue Schaltfläche Vorschau verwenden. Darüber hinaus können Sie den vollständigen Inhalt einer Datei aus der parallelen diff anzeigen, indem Sie die Schaltfläche Ansicht auswählen.
Ablauf der Buildrichtlinie für manuelle Builds
Richtlinien erzwingen die Codequalitäts- und Change Management-Standards Ihres Teams. Zuvor konnten Sie Buildablaufrichtlinien für automatisierte Builds festlegen. Jetzt können Sie Buildablaufrichtlinien auch auf Ihre manuellen Builds festlegen.
Hinzufügen einer Richtlinie zum Blockieren von Commits basierend auf der E-Mail des Commitautors
Administratoren können jetzt eine Pushrichtlinie festlegen, um zu verhindern, dass Commits in ein Repository gepusht werden, für das die Commitautor-E-Mail nicht mit dem angegebenen Muster übereinstimmt.
Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert, um eine ähnliche Benutzeroberfläche bereitzustellen. Wir halten das Ticket weiterhin geöffnet und ermutigen Die Benutzer, uns mitzuteilen, welche anderen Arten von Pushrichtlinien Sie sehen möchten.
Markieren von Dateien als überprüft in einem Pull Request
Manchmal müssen Sie Pull Requests überprüfen, die Änderungen an einer großen Anzahl von Dateien enthalten, und es kann schwierig sein, nachzuverfolgen, welche Dateien Sie bereits überprüft haben. Jetzt können Sie Dateien in einem Pull Request als überprüft markieren.
Sie können eine Datei als überprüft markieren, indem Sie das Dropdownmenü neben einem Dateinamen verwenden oder mit dem Mauszeiger auf den Dateinamen klicken.
Hinweis
Dieses Feature dient nur dazu, Ihren Fortschritt zu verfolgen, wenn Sie einen Pull Request überprüfen. Es stellt keine Abstimmung über Pull Requests dar, sodass diese Markierungen nur für den Prüfer sichtbar sind.
Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert.
Neue Web-Benutzeroberfläche für Azure Repos Landing Pages
Sie können jetzt unsere neuen modernen, schnellen und mobilfreundlichen Landing Pages in Azure Repos ausprobieren. Diese Seiten sind als Neue Repos-Zielseiten verfügbar. Zielseiten enthalten alle Seiten mit Ausnahme von Pull Request-Details, Commitdetails und Branchvergleichen.
Web
Mobil
Cross-Repo Branch-Richtlinienverwaltung
Branchrichtlinien sind eines der leistungsstarken Features von Azure Repos, mit denen Sie wichtige Branches schützen können. Obwohl die Möglichkeit zum Festlegen von Richtlinien auf Projektebene in der REST-API vorhanden ist, gab es dafür keine Benutzeroberfläche. Jetzt können Administratoren Richtlinien für einen bestimmten Branch oder die Standardbranch für alle Repositorys in ihrem Projekt festlegen. Beispielsweise könnte ein Administrator zwei Mindestprüfer für alle Pull Requests anfordern, die in jedem Standard Branch in jedem Repository in ihrem Projekt ausgeführt werden. Sie finden das Feature Branchschutz hinzufügen in den Repository-Projekteinstellungen.
Neue Zielseiten für die Webplattformkonvertierung
Wir haben die Benutzeroberfläche für Repos-Zielseiten aktualisiert, um sie modern, schnell und mobil zu gestalten. Im Folgenden finden Sie zwei Beispiele für die Seiten, die aktualisiert wurden. In zukünftigen Updates werden weitere Seiten aktualisiert.
Weberfahrung:
Mobile Erfahrung:
Unterstützung für die Sprache Kotlin
Wir freuen uns, ihnen mitteilen zu können, dass wir jetzt die Kotlin-Sprachmarkierung im Datei-Editor unterstützen. Die Hervorhebung verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen, schnell zu überprüfen, um Fehler zu finden. Wir haben dieses Feature basierend auf einem Vorschlag aus dem Entwicklercommunity priorisiert.
Benutzerdefiniertes Benachrichtigungsabonnement für Pull Requests-Entwürfe
Um die Anzahl der E-Mail-Benachrichtigungen von Pull Requests zu reduzieren, können Sie jetzt ein benutzerdefiniertes Benachrichtigungsabonnement für Pull Requests erstellen, die im Entwurfszustand erstellt oder aktualisiert werden. Sie können E-Mails speziell für Pull Requests-Entwürfe abrufen oder E-Mails aus Pull Requests-Entwürfen herausfiltern, damit Ihr Team nicht benachrichtigt wird, bevor der Pull Request zur Überprüfung bereit ist.
Verbesserte PR-Umsetzbarkeit
Wenn Sie viele Pull Requests zu überprüfen haben, kann es schwierig sein, zu verstehen, wo Sie zuerst maßnahmen sollten. Um pull request actionability zu verbessern, können Sie jetzt mehrere benutzerdefinierte Abfragen auf der Pull Request List-Seite mit mehreren neuen Optionen erstellen, nach denen Sie filtern können, z. B. den Entwurfszustand. Diese Abfragen erstellen separate und zerlegbare Abschnitte auf Ihrer Pull Request-Seite sowie "Von mir erstellt" und "Mir zugewiesen". Sie können auch die Überprüfung eines Pull Request ablehnen, dem Sie über das Abstimmungsmenü oder das Kontextmenü auf der Seite mit der Pull Request-Liste hinzugefügt wurden. In den benutzerdefinierten Abschnitten werden nun separate Registerkarten für Pull Requests angezeigt, für die Sie eine Überprüfung bereitgestellt oder abgelehnt haben. Diese benutzerdefinierten Abfragen funktionieren repositoryübergreifend auf der Registerkarte "Meine Pull Requests" der Sammlungs-Startseite. Wenn Sie zu einem Pull Request zurückkehren möchten, können Sie ihn kennzeichnen, und sie werden ganz oben in Der Liste angezeigt. Schließlich werden Pull Requests, die auf auto-complete festgelegt wurden, in der Liste mit einer Pille gekennzeichnet, die "Auto-complete" lautet.
Pipelines
Mehrstufige Pipelines
Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Pipelines zu verwalten. Diese Updates machen die Pipelines modern und konsistent mit der Richtung von Azure DevOps. Darüber hinaus vereinen diese Updates klassische Buildpipelines und mehrstufige YAML-Pipelines in einer einzigen Umgebung. Es ist für Mobilgeräte geeignet und bietet verschiedene Verbesserungen bei der Verwaltung Ihrer Pipelines. Sie können Einen Drilldown durchführen und Pipelinedetails anzeigen, Details ausführen, Pipelineanalysen, Auftragsdetails, Protokolle und vieles mehr.
Die folgenden Funktionen sind in der neuen Benutzeroberfläche enthalten:
- Anzeigen und Verwalten mehrerer Phasen
- Genehmigen von Pipelineausführungen
- Scrollen Sie den ganzen Weg zurück in Protokollen, während eine Pipeline noch in Bearbeitung ist
- Die Integrität pro Branch einer Pipeline.
Continuous deployment in YAML
Wir freuen uns, Die YAML-CD-Features von Azure Pipelines bereitstellen zu können. Wir bieten jetzt eine einheitliche YAML-Benutzeroberfläche, sodass Sie jede Ihrer Pipelines so konfigurieren können, dass CI, CD oder CI und CD gemeinsam ausgeführt werden. YAML CD-Features führen mehrere neue erweiterte Features ein, die für alle Sammlungen mit mehrstufigen YAML-Pipelines verfügbar sind. Einige der Highlights sind unter anderem:
- Mehrstufige YAML-Pipelines (für CI und CD)
- Genehmigungen und Überprüfungen von Ressourcen
- Umgebungen und Bereitstellungsstrategien
- Kubernetes - und VM-Ressourcen in der Umgebung
- Überprüfen von Apps für die Zusammenarbeit
- Aktualisierte Benutzeroberfläche für Dienstverbindungen
- Ressourcen in YAML-Pipelines
Wenn Sie mit dem Erstellen beginnen möchten, lesen Sie die Dokumentation oder den Blog zum Erstellen mehrstufiger CI/CD-Pipelines.
Verwalten von Pipelinevariablen im YAML-Editor
Wir haben die Benutzeroberfläche für die Verwaltung von Pipelinevariablen im YAML-Editor aktualisiert. Sie müssen nicht mehr zum klassischen Editor wechseln, um Variablen in Ihren YAML-Pipelines hinzuzufügen oder zu aktualisieren.
Genehmigen von Releases direkt über den Releases-Hub
Die Bearbeitung ausstehender Genehmigungen wurde erleichtert. Zuvor war es möglich, eine Version auf der Detailseite des Releases zu genehmigen. Sie können Releases jetzt direkt über den Releases Hub genehmigen.
Verbesserungen bei den ersten Schritten mit Pipelines
Eine häufige Frage mit dem Assistenten für die ersten Schritte war die Möglichkeit, die generierte Datei umzubenennen. Derzeit wird es als azure-pipelines.yml im Stammverzeichnis Ihres Repositorys eingecheckt. Sie können dies nun auf einen anderen Dateinamen oder Speicherort aktualisieren, bevor Sie die Pipeline speichern.
Schließlich haben Sie mehr Kontrolle beim Einchecken der azure-pipelines.yml Datei in einen anderen Branch, da Sie das Erstellen eines Pull Requests aus diesem Branch überspringen können.
Vorschau eines vollständig analysierten YAML-Dokuments ohne Commit oder Ausführen der Pipeline
Wir haben eine Vorschauversion hinzugefügt, aber keinen Ausführungsmodus für YAML-Pipelines. Jetzt können Sie eine YAML-Pipeline ausprobieren, ohne sie in ein Repository zu übertragen oder auszuführen. Angesichts einer vorhandenen Pipeline und einer optionalen neuen YAML-Nutzlast erhalten Sie mit dieser neuen API die vollständige YAML-Pipeline zurück. In zukünftigen Updates wird diese API in einem neuen Editorfeature verwendet.
Für Entwickler: POST mit dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview einem JSON-Text wie folgt:
{
"PreviewRun": true,
"YamlOverride": "
# your new YAML here, optionally
"
}
Die Antwort enthält das gerenderte YAML.
Cronzeitpläne in YAML
Zuvor konnten Sie den UI-Editor verwenden, um einen geplanten Trigger für YAML-Pipelines anzugeben. Mit diesem Release können Sie Builds mit cron-Syntax in Ihrer YAML-Datei planen und die folgenden Vorteile nutzen:
- Als Code konfigurieren: Sie können die Zeitpläne zusammen mit Ihrer Pipeline als Teil von Code nachverfolgen.
- Ausdrucksstark: Sie haben mehr Ausdruckskraft beim Definieren von Zeitplänen als das, was Sie mit der Benutzeroberfläche erreichen konnten. Für instance ist es einfacher, einen einzelnen Zeitplan anzugeben, der jede Stunde eine Ausführung startet.
- Branchenstandard: Viele Entwickler und Administratoren sind bereits mit der Cron-Syntax vertraut.
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
- releases/*
exclude:
- releases/ancient/*
always: true
Wir haben es Ihnen auch leicht gemacht, Probleme mit Cron-Zeitplänen zu diagnostizieren. Mit den geplanten Ausführungen im Menü Pipeline ausführen erhalten Sie eine Vorschau auf die bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Fehler mit Ihren Cron-Zeitplänen zu diagnostizieren.
Benutzeroberfläche für Updates zu Dienstverbindungen
Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Dienstverbindungen zu verwalten. Diese Updates machen die Dienstverbindung modern und konsistent mit der Richtung von Azure DevOps. Anfang dieses Jahres haben wir die neue Benutzeroberfläche für Dienstverbindungen als Vorschaufeature eingeführt. Vielen Dank an alle, die die neue Erfahrung ausprobiert haben und uns ihr wertvolles Feedback gegeben haben.
Neben der Aktualisierung der Benutzeroberfläche haben wir auch zwei Funktionen hinzugefügt, die für die Nutzung von Dienstverbindungen in YAML-Pipelines von entscheidender Bedeutung sind: Pipelineautorisierungen und Genehmigungen und Überprüfungen.
Die neue Benutzeroberfläche wird mit diesem Update standardmäßig aktiviert . Sie haben weiterhin die Möglichkeit, die Vorschau abzuwählen.
Hinweis
Wir planen, die projektübergreifende Freigabe von Dienstverbindungen als neue Funktion einzuführen. Weitere Informationen zur Freigabe und zu den Sicherheitsrollen finden Sie hier.
Überspringen von Phasen in einer YAML-Pipeline
Wenn Sie eine manuelle Ausführung starten, sollten Sie manchmal einige Phasen in Ihrer Pipeline überspringen. Für instance, wenn Sie keine Bereitstellung in der Produktion durchführen möchten oder wenn Sie die Bereitstellung in einigen Umgebungen in der Produktion überspringen möchten. Sie können dies jetzt mit Ihren YAML-Pipelines tun.
Der aktualisierte Ausführungspipelinebereich zeigt eine Liste der Phasen aus der YAML-Datei an, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Sie müssen beim Überspringen von Phasen Vorsicht walten lassen. Wenn ihre erste Phase für instance bestimmte Artefakte erzeugt, die für nachfolgende Phasen benötigt werden, sollten Sie die erste Phase nicht überspringen. Der Ausführungsbereich zeigt eine allgemeine Warnung an, wenn Sie Phasen überspringen, die nachgelagerte Abhängigkeiten aufweisen. Es bleibt Ihnen überlassen, ob es sich bei diesen Abhängigkeiten um echte Artefaktabhängigkeiten handelt oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.
Das Überspringen einer Phase entspricht dem erneuten Verdrahten der Abhängigkeiten zwischen den Phasen. Alle unmittelbar nachgelagerten Abhängigkeiten der übersprungenen Phase hängen vom Upstream übergeordneten Der übersprungenen Phase ab. Wenn bei der Ausführung ein Fehler auftritt und Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, weist auch dieser Versuch das gleiche Übersprungverhalten auf. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.
Neue Benutzeroberfläche für Dienstverbindungen als Standardumgebung
Es gibt eine neue Benutzeroberfläche für Dienstverbindungen. Diese neue Benutzeroberfläche basiert auf modernen Designstandards und verfügt über verschiedene wichtige Features zur Unterstützung mehrstufiger YAML-CD-Pipelines wie Genehmigungen, Autorisierungen und projektübergreifender Freigabe.
Weitere Informationen zu Dienstverbindungen finden Sie hier.
Pipelineressourcenversionsauswahl im Dialogfeld "Ausführen erstellen"
Wir haben die Möglichkeit hinzugefügt, Pipelineressourcenversionen im Dialogfeld "Erstellen ausführen" manuell zu erfassen. Wenn Sie eine Pipeline als Ressource in einer anderen Pipeline nutzen, können Sie nun die Version dieser Pipeline auswählen, wenn Sie eine Ausführung erstellen.
az CLI-Verbesserungen für Azure Pipelines
Befehle zur Pipelinevariablengruppe und Variablenverwaltung
Es kann schwierig sein, YAML-basierte Pipelines von einem Projekt in ein anderes zu portieren, da Sie die Pipelinevariablen und Variablengruppen manuell einrichten müssen. Mit der Pipelinevariablengruppe und den Befehlen für die Variablenverwaltung können Sie jetzt das Einrichten und Verwalten von Pipelinevariablen und Variablengruppen per Skript ausführen, die wiederum versionsgesteuert werden können, sodass Sie problemlos die Anweisungen zum Verschieben und Einrichten von Pipelines von einem Projekt zum anderen freigeben können.
Ausführen der Pipeline für einen PR-Branch
Beim Erstellen eines PR kann es schwierig sein, zu überprüfen, ob die Änderungen die Pipelineausführung auf dem Zielbranch unterbrechen könnten. Mit der Möglichkeit, eine Pipelineausführung auszulösen oder einen Build für einen PR-Branch in eine Warteschlange zu stellen, können Sie nun die änderungen überprüfen und visualisieren, indem Sie ihn für die Zielpipeline ausführen. Weitere Informationen finden Sie in der Dokumentation zum Befehl az pipelines run und az pipelines build queue .
Überspringen der ersten Pipelineausführung
Beim Erstellen von Pipelines möchten Sie manchmal eine YAML-Datei erstellen und committen und die Pipelineausführung nicht auslösen, da dies aus verschiedenen Gründen zu einer fehlerhaften Ausführung führen kann. Die Infrastruktur ist nicht bereit oder muss Variablen-/Variablengruppen usw. erstellen und aktualisieren. Mit der Azure DevOps CLI können Sie jetzt die erste automatisierte Pipelineausführung beim Erstellen einer Pipeline überspringen, indem Sie den Parameter --skip-first-run einschließen. Weitere Informationen finden Sie in der Dokumentation zum Befehl az pipeline create .
Dienstendpunktbefehlserweiterung
Cli-Befehle des Dienstendpunkts unterstützten nur die Einrichtung und Verwaltung des Dienstendpunkts azure rm und github. Mit dieser Version können Sie jedoch mithilfe von Dienstendpunkten einen beliebigen Dienstendpunkt erstellen, indem Sie die Konfiguration per Datei bereitstellen und optimierte Befehle bereitstellen– az devops service-endpoint github und az devops service-endpoint azurerm, die erstklassige Unterstützung zum Erstellen von Dienstendpunkten dieser Art bieten. Weitere Informationen finden Sie in der Befehlsdokumentation .
Bereitstellungsaufträge
Ein Bereitstellungsauftrag ist ein besonderer Auftragstyp , der zum Bereitstellen Ihrer App in einer Umgebung verwendet wird. Mit diesem Update haben wir Unterstützung für Schrittverweise in einem Bereitstellungsauftrag hinzugefügt. Beispielsweise können Sie eine Reihe von Schritten in einer Datei definieren und in einem Bereitstellungsauftrag darauf verweisen.
Außerdem haben wir dem Bereitstellungsauftrag unterstützung für zusätzliche Eigenschaften hinzugefügt. Hier finden Sie beispielsweise einige Eigenschaften eines Bereitstellungsauftrags, die Sie jetzt festlegen können:
- timeoutInMinutes : Wie lange der Auftrag ausgeführt werden soll, bevor er automatisch abgebrochen wird
- cancelTimeoutInMinutes : Wie viel Zeit soll "Immer ausgeführt werden, auch wenn Aufgaben abgebrochen werden" vor dem Beenden der Aufgaben
- Bedingung : Auftrag bedingt ausführen
- Variablen : Hartcodierte Werte können direkt oder Variablengruppen hinzugefügt werden, Variablengruppen, die von einem Azure-Schlüsseltresor unterstützt werden, können referenziert werden, oder Sie können auf eine Gruppe von Variablen verweisen, die in einer Datei definiert sind.
- continueOnError : Wenn zukünftige Aufträge ausgeführt werden sollen, auch wenn dieser Bereitstellungsauftrag fehlschlägt; standardwert auf "false"
Weitere Informationen zu Bereitstellungsaufträgen und der vollständigen Syntax zum Angeben eines Bereitstellungsauftrags finden Sie unter Bereitstellungsauftrag.
Anzeigen zugeordneter CD-Pipelines-Informationen in CI-Pipelines
Wir haben unterstützung für die CD-YAML-Pipelines hinzugefügt, wobei die CI-Pipelines als Pipelineressourcen bezeichnet werden. In Ihrer CI-Pipelineausführungsansicht wird nun eine neue Registerkarte "Zugeordnete Pipelines" angezeigt, auf der Sie alle Pipelineausführungen finden, die Ihre Pipeline nutzen, und Artefakte aus der Pipeline.
Unterstützung für GitHub-Pakete in YAML-Pipelines
Wir haben kürzlich einen neuen Ressourcentyp namens Packages eingeführt, der Unterstützung für die Nutzung von NuGet - und npm-Paketen von GitHub als Ressource in YAML-Pipelines hinzufügt. Als Teil dieser Ressource können Sie jetzt den Pakettyp (NuGet oder npm) angeben, den Sie von GitHub nutzen möchten. Sie können auch automatisierte Pipelinetrigger nach der Veröffentlichung einer neuen Paketversion aktivieren. Heute ist der Support nur für die Nutzung von Paketen von GitHub verfügbar, aber in Zukunft planen wir, die Unterstützung 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
GitHub-Pakete unterstützen heute nur die PAT-basierte Authentifizierung, was bedeutet, dass die GitHub-Dienstverbindung in der Paketressource vom Typ PAT sein sollte. Sobald diese Einschränkung aufgehoben wurde, bieten wir Unterstützung für andere Authentifizierungstypen.
Standardmäßig werden Pakete nicht automatisch in Ihre Aufträge heruntergeladen. Daher haben wir ein getPackage-Makro eingeführt, 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
ressourcenansicht Azure Kubernetes Service Clusterlink in Kubernetes-Umgebungen
Wir haben einen Link zur Ressourcenansicht von Kubernetes-Umgebungen hinzugefügt, damit Sie zum Azure-Blatt für den entsprechenden Cluster navigieren können. Dies gilt für Umgebungen, die Namespaces in Azure Kubernetes Service Clustern zugeordnet sind.
Freigeben von Ordnerfiltern in Benachrichtigungsabonnements
Ordner ermöglichen das Organisieren von Pipelines für eine einfachere Auffindbarkeit und Sicherheitskontrolle. Häufig möchten Sie benutzerdefinierte E-Mail-Benachrichtigungen für alle Releasepipelines konfigurieren, die durch alle Pipelines unter einem Ordner dargestellt werden. Zuvor mussten Sie mehrere Abonnements konfigurieren oder komplexe Abfragen in den Abonnements ausführen, um fokussierte E-Mails abzurufen. Mit diesem Update können Sie jetzt eine Releaseordnerklausel zu den Ereignissen abgeschlossener Bereitstellung und Genehmigung ausstehend hinzufügen und die Abonnements vereinfachen.
Verknüpfen von Arbeitselementen mit mehrstufigen YAML-Pipelines
Derzeit können Sie Arbeitselemente automatisch mit klassischen Builds verknüpfen. Dies war jedoch mit YAML-Pipelines nicht möglich. Mit diesem Update haben wir diese Lücke behoben. Wenn Sie eine Pipeline erfolgreich mit Code aus einem angegebenen Branch ausführen, ordnet Azure Pipelines die Ausführung automatisch allen Arbeitselementen zu (die über die Commits in diesem Code abgeleitet werden). Wenn Sie das Arbeitselement öffnen, können Sie die Ausführungen sehen, in denen der Code für das Arbeitselement erstellt wurde. Um dies zu konfigurieren, verwenden Sie den Einstellungsbereich einer Pipeline.
Abbrechen der Phase in einer mehrstufigen YAML-Pipelineausführung
Beim Ausführen einer mehrstufigen YAML-Pipeline können Sie jetzt die Ausführung einer Phase abbrechen, während sie ausgeführt wird. Dies ist hilfreich, wenn Sie wissen, dass die Phase fehlschlägt oder wenn Sie eine andere Ausführung haben, die Sie starten möchten.
Wiederholen fehlgeschlagener Phasen
Eines der am häufigsten angeforderten Features in mehrstufigen Pipelines ist die Möglichkeit, eine fehlgeschlagene Phase zu wiederholen, ohne von Anfang an beginnen zu müssen. Mit diesem Update fügen wir einen großen Teil dieser Funktionalität hinzu.
Sie können jetzt eine Pipelinephase wiederholen, wenn die Ausführung fehlschlägt. Alle Aufträge, die beim ersten Versuch fehlgeschlagen sind, und alle Aufträge, die transitiv von diesen fehlgeschlagenen Aufträgen abhängen, werden erneut versucht.
Dies kann Ihnen dabei helfen, Zeit auf verschiedene Arten zu sparen. Wenn Sie mehrere Aufträge in einer Phase ausführen, sollten Sie bei instance möglicherweise tests auf einer anderen Plattform ausführen. Wenn die Tests auf einer Plattform fehlschlagen, während andere erfolgreich sind, können Sie Zeit sparen, indem Sie die erfolgreichen Aufträge nicht erneut ausführen. Ein weiteres Beispiel ist, dass eine Bereitstellungsphase aufgrund einer flakigen Netzwerkverbindung fehlgeschlagen ist. Wenn Sie diese Phase wiederholen, können Sie Zeit sparen, da Sie keinen weiteren Build erstellen müssen.
Es gibt einige bekannte Lücken in diesem Feature. Beispielsweise können Sie eine Phase, die Sie explizit abbrechen, nicht wiederholen. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.
Genehmigungen in mehrstufigen YAML-Pipelines
Ihre YAML-CD-Pipelines können manuelle Genehmigungen enthalten. Infrastrukturbesitzer können ihre Umgebungen schützen und manuelle Genehmigungen einholen, bevor eine Phase in einer Pipeline für sie bereitgestellt wird. Mit der vollständigen Trennung der Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie sicher, dass Sie die manuelle Abmeldung für die Bereitstellung in einer bestimmten Pipeline durchführen und die zentrale Kontrolle über die Anwendung derselben Überprüfungen für alle Bereitstellungen auf die Umgebung erhalten.
Die Pipeline führt die Bereitstellung in der Entwicklung aus, wird zu Beginn der Phase zur Genehmigung beendet.
Erhöhung des Timeoutlimits und der Häufigkeit von Gates
Zuvor betrug das Gate-Timeoutlimit in Releasepipelines drei Tage. Mit diesem Update wurde das Timeoutlimit auf 15 Tage erhöht, um Gates mit längerer Dauer zuzulassen. Wir haben auch die Häufigkeit des Tores auf 30 Minuten erhöht.
Neue Buildimagevorlage für Dockerfile
Zuvor hat die Vorlage beim Erstellen einer neuen Pipeline für eine Dockerfile-Datei in einer neuen Pipeline empfohlen, das Image per Push 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 mit dem Agent erstellen können, ohne eine Push-Datei an eine Containerregistrierung senden zu müssen.
Neue Aufgabe zum Konfigurieren Azure App Service App-Einstellungen
Azure App Service ermöglicht die Konfiguration über verschiedene Einstellungen wie App-Einstellungen, Verbindungszeichenfolgen und andere allgemeine Konfigurationseinstellungen. Wir verfügen jetzt über eine neue Azure Pipelines-Aufgabe Azure App Service Einstellungen, die die Massenkonfiguration dieser Einstellungen mithilfe der JSON-Syntax in Ihrer Web-App oder einem ihrer Bereitstellungsslots unterstützt. Diese Aufgabe kann zusammen mit anderen App Service-Aufgaben verwendet werden, um Ihre Web-Apps, Funktions-Apps oder andere containerisierte App Services bereitzustellen, zu verwalten und zu konfigurieren.
Azure App Service unterstützt jetzt "Mit Vorschau austauschen"
Azure App Service unterstützt jetzt Den Austausch mit Vorschau auf den Bereitstellungsslots. Dies ist eine gute Möglichkeit, die App mit der Produktionskonfiguration zu überprüfen, bevor die App tatsächlich von einem Stagingslot in einen Produktionsslot ausgetauscht wird. Dies würde auch sicherstellen, dass für den Ziel-/Produktionsslot keine Ausfallzeiten auftreten.
Azure App Service Task unterstützt jetzt diesen mehrphasigen Austausch über die folgenden neuen Aktionen:
- Tausch mit Vorschau starten : Initiiert einen Tausch mit einer Vorschau (mehrphasigen Austausch) und wendet die Zielslotkonfiguration (z. B. den Produktionsslot) auf den Quellslot an.
- Tausch mit Vorschau abschließen: Wenn Sie bereit sind, den ausstehenden Tausch abzuschließen, wählen Sie die Aktion Tausch mit Vorschau abschließen aus.
- Tausch mit Vorschau abbrechen : Um einen ausstehenden Austausch abzubrechen, wählen Sie Mit Vorschau abbrechen aus.
Filter auf Stufenebene 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 Bühnenebene hinzugefügt.
Verbesserungen an Genehmigungen in YAML-Pipelines
Wir haben das Konfigurieren von Genehmigungen für Dienstverbindungen und Agentpools aktiviert. Für Genehmigungen folgen wir der Rollentrennung zwischen Infrastrukturbesitzern und Entwicklern. Durch das Konfigurieren von Genehmigungen für Ihre Ressourcen wie Umgebungen, Dienstverbindungen und Agentpools können Sie sicher sein, dass alle Pipelineausführungen, die Ressourcen verwenden, zuerst eine Genehmigung erfordern.
Die Vorgehensweise ä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 wurde.
Unterstützung für Containerstrukturtests in Azure Pipelines
Die Nutzung von Containern in Anwendungen nimmt zu und daher der Bedarf an robusten Tests und Validierungen. Azure Pipelines bietet jetzt Unterstützung für Containerstrukturtests. Dieses Framework bietet eine praktische und leistungsstarke Möglichkeit, den Inhalt und die Struktur Ihrer Container zu überprüfen.
Sie können die Struktur eines Images anhand von vier Kategorien von Tests überprüfen, die zusammen ausgeführt werden können: Befehlstests, Dateiexistenztests, Dateiinhaltstests und Metadatentests. Sie können die Ergebnisse in der Pipeline verwenden, um Go/No Go-Entscheidungen zu treffen. Testdaten sind in der Pipelineausführung mit einer Fehlermeldung verfügbar, um Fehler besser beheben zu können.
Eingeben der Konfigurationsdatei und der Bilddetails
Testdaten und Zusammenfassung
Pipelinedekortoren für Releasepipelines
Pipelinedekoratoren ermöglichen das Hinzufügen von Schritten am Anfang und Ende jedes Auftrags. Dies unterscheidet sich vom Hinzufügen von Schritten zu einer einzelnen Definition, da sie für alle Pipelines in einer Auflistung gilt.
Wir haben Decorators für Builds und YAML-Pipelines unterstützt, wobei Kunden sie verwenden, um die Schritte in ihren Aufträgen zentral zu steuern. Jetzt erweitern wir die Unterstützung auch auf Releasepipelines. Sie können Erweiterungen erstellen, um Schritte für den neuen Beitragspunkt hinzuzufügen, die allen Agentaufträgen in Releasepipelines hinzugefügt werden.
Bereitstellen von Azure Resource Manager (ARM) auf Abonnement- und Verwaltungsgruppenebene
Bisher haben wir Bereitstellungen nur auf Ressourcengruppenebene unterstützt. Mit diesem Update haben wir unterstützung für die Bereitstellung von ARM-Vorlagen auf Abonnement- und Verwaltungsgruppenebene hinzugefügt. Dies hilft Ihnen, wenn Sie eine Reihe von Ressourcen zusammen bereitstellen, diese jedoch in verschiedenen Ressourcengruppen oder Abonnements platzieren. Beispielsweise wird der virtuelle Sicherungscomputer für Azure Site Recovery in einer separaten Ressourcengruppe und an einem separaten Speicherort bereitgestellt.
CD-Funktionen für Ihre mehrstufigen YAML-Pipelines
Sie können jetzt Artefakte nutzen, die von Ihrer CI-Pipeline veröffentlicht wurden, und Pipeline-Vervollständigungstrigger aktivieren. In mehrstufigen YAML-Pipelines führen pipelines wir als Ressource ein. In Ihrem YAML können Sie jetzt auf eine andere Pipeline verweisen und CD-Trigger aktivieren.
Hier sehen Sie das detaillierte YAML-Schema für pipelines-Ressource.
resources:
pipelines:
- pipeline: MyAppCI # identifier for the pipeline resource
project: DevOpsProject # project for the build pipeline; optional input for current project
source: MyCIPipeline # source pipeline definition name
branch: releases/M159 # branch to pick the artifact, optional; defaults to all branches
version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
trigger: # Optional; Triggers are not enabled by default.
branches:
include: # branches to consider the trigger events, optional; defaults to all branches.
- main
- releases/*
exclude: # branches to discard the trigger events, optional; defaults to none.
- users/*
Darüber hinaus können Sie die von Ihrer Pipelineressource veröffentlichten Artefakte mithilfe der - download Aufgabe herunterladen.
steps:
- download: MyAppCI # pipeline resource identifier
artifact: A1 # name of the artifact to download; optional; defaults to all artifacts
Weitere Informationen finden Sie in der Dokumentation zum Herunterladen von Artefakten.
Orchestrieren der Canary-Bereitstellungsstrategie in der Umgebung für Kubernetes
Einer der wichtigsten Vorteile der Continuous Delivery von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu pushen. Dadurch können Sie schnell auf Änderungen der Geschäftsanforderungen reagieren. Die Umgebung wurde als erstklassiges Konzept eingeführt, das die Orchestrierung von Bereitstellungsstrategien ermöglicht und Releases ohne Ausfallzeiten ermöglicht. Zuvor haben wir die runOnce-Strategie unterstützt, die die Schritte einmal sequenziell ausgeführt hat. Mit der Unterstützung der Canary-Strategie in mehrstufigen Pipelines können Sie das Risiko jetzt reduzieren, indem Sie die Änderung langsam in eine kleine Teilmenge einführen. Wenn Sie mehr Vertrauen in die neue Version gewinnen, können Sie damit beginnen, sie auf mehr Server in Ihrer Infrastruktur bereitzustellen und mehr Benutzer an sie weiterzuleiten.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Die Canary-Strategie für Kuberenetes wird zuerst die Änderungen mit 10 % Pods bereitstellen, gefolgt von 20 %, während die Integrität während postRouteTraffic überwacht wird. Wenn alles gut geht, wird es zu 100% höher geschaltet.
Wir suchen nach frühzeitigem Feedback zur Unterstützung von VM-Ressourcen in Umgebungen und zur Durchführung einer fortlaufenden Bereitstellungsstrategie auf mehreren Computern. Kontaktieren Sie uns , um sich zu registrieren.
Genehmigungsrichtlinien für YAML-Pipelines
In YAML-Pipelines folgen wir einer ressourcenbesitzergesteuerten Genehmigungskonfiguration. Ressourcenbesitzer konfigurieren Genehmigungen für die Ressource und alle Pipelines, die die Ressource verwenden, pausen für Genehmigungen vor Beginn der Phase, in der die Ressource verbraucht wird. Es ist üblich, dass SOX-basierte Anwendungsbesitzer den Anforderer der Bereitstellung daran hindern, eigene Bereitstellungen zu genehmigen.
Sie können jetzt erweiterte Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien zu konfigurieren, z. B. der Anforderer sollte nicht genehmigen, die Genehmigung von einer Teilmenge der Benutzer und das Genehmigungstimeout anfordern.
ACR als erstklassige Pipelineressource
Wenn Sie ein in ACR (Azure Container Registry) veröffentlichtes Containerimage als Teil Ihrer Pipeline nutzen und Ihre Pipeline bei der Veröffentlichung eines neuen Images auslösen müssen, können Sie die ACR-Containerressource verwenden.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Darüber hinaus kann mit vordefinierten Variablen auf ACR-Bildmetadaten zugegriffen werden. Die folgende Liste enthält die verfügbaren ACR-Variablen zum Definieren einer ACR-Containerressource in Ihrer Pipeline.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Verbesserungen zum Auswerten der Artefaktüberprüfungsrichtlinie in Pipelines
Wir haben die Überprüfung des Artefakts auswerten erweitert, um das Hinzufügen von Richtlinien aus einer Liste mit sofort einsatzbereiten Richtliniendefinitionen zu erleichtern. Die Richtliniendefinition wird automatisch generiert und der Prüfkonfiguration hinzugefügt, die bei Bedarf aktualisiert werden kann.
Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag
Sie können nun Ausgabevariablen in den Lebenszyklus-Hooks eines Bereitstellungsauftrags definieren und sie in anderen nachgelagerten Schritten und Aufträgen innerhalb derselben Phase nutzen.
Beim Ausführen von Bereitstellungsstrategien können Sie mit der folgenden Syntax auftragsübergreifend auf Ausgabevariablen zugreifen.
- Für die runOnce-Strategie :
$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']] - Für die Canary-Strategie :
$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']] - Für rollierende Strategie:
$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
pool:
vmImage: 'ubuntu-16.04'
environment: staging
strategy:
canary:
increments: [10,20] # creates multiple jobs, one for each increment. Output variable can be referenced with this.
deploy:
steps:
- script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
// Map the variable from the job
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-16.04'
variables:
myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
steps:
- script: "echo $(myVarFromDeploymentJob)"
name: echovar
Weitere Informationen zum Festlegen einer Ausgabevariable mit mehreren Aufträgen
Vermeiden eines Rollbacks kritischer Änderungen
In klassischen Releasepipelines ist es üblich, sich für regelmäßige Updates auf geplante Bereitstellungen zu verlassen. Wenn Sie jedoch eine kritische Lösung haben, können Sie eine manuelle Bereitstellung out-of-band starten. Dabei bleiben ältere Releases weiterhin geplant. Dies stellte eine Herausforderung dar, da für die manuelle Bereitstellung ein Rollback ausgeführt wurde, wenn die Bereitstellungen gemäß Zeitplan fortgesetzt wurden. Viele von Ihnen haben dieses Problem gemeldet, und wir haben es jetzt behoben. Mit dem Fix würden alle älteren geplanten Bereitstellungen in der Umgebung abgebrochen, wenn Sie eine Bereitstellung manuell starten. Dies gilt nur, wenn die Warteschlangenoption "Zuletzt bereitstellen und andere abbrechen" ausgewählt ist.
Vereinfachte Ressourcenautorisierung in YAML-Pipelines
Eine Ressource ist alles, was von einer Pipeline außerhalb der Pipeline verwendet wird. Ressourcen müssen vor der Verwendung autorisiert werden. Bisher ist bei der Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline ein Ressourcenautorisierungsfehler aufgetreten. Sie mussten die Ressourcen auf der Zusammenfassungsseite der fehlgeschlagenen Ausführung autorisieren. Darüber hinaus ist die Pipeline fehlgeschlagen, wenn sie eine Variable verwendet, die auf eine nicht autorisierte Ressource verweist.
Wir erleichtern nun die Verwaltung von Ressourcenautorisierungen. Anstatt die Ausführung zu verfehlen, wartet die Ausführung am Anfang der Phase, in der die Ressource verwendet wird, auf Berechtigungen für die Ressourcen. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource auf der Seite Sicherheit autorisieren.
Auswerten der Artefaktprüfung
Sie können jetzt einen Satz von Richtlinien definieren und die Richtlinienauswertung als Überprüfung für eine 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 besteht, wenn die Richtlinie erfolgreich ist, und markiert die Phase als fehlgeschlagen, wenn die Überprüfung fehlschlägt.
Updates zum Bereitstellungstask für ARM-Vorlagen
Zuvor haben wir die Dienstverbindungen in der Bereitstellungsaufgabe der ARM-Vorlage nicht gefiltert. Dies kann dazu führen, dass die Bereitstellung fehlschlägt, wenn Sie eine Dienstverbindung mit niedrigerem Bereich auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich durchzuführen. Jetzt haben wir die Filterung von Dienstverbindungen hinzugefügt, um Dienstverbindungen mit niedrigerem Bereich basierend auf dem ausgewählten Bereitstellungsbereich herauszufiltern.
ReviewApp in Environment
ReviewApp stellt jeden Pull Request aus Ihrem Git-Repository in einer dynamischen Umgebungsressource bereit. Prüfer können sehen, wie diese Änderungen aussehen und mit anderen abhängigen Diensten arbeiten, bevor sie in den Standard Branch zusammengeführt und in der Produktion bereitgestellt werden. Dies erleichtert Ihnen das Erstellen und Verwalten von reviewApp-Ressourcen und profitiert von allen Nachverfolgbarkeits- und Diagnosefunktionen der Umgebungsfeatures. Mithilfe des reviewApp-Schlüsselwort (keyword) können Sie einen Klon einer Ressource erstellen (basierend auf einer vorhandenen Ressource in einer Umgebung dynamisch eine neue Ressource erstellen) und die neue Ressource der Umgebung hinzufügen.
Im Folgenden finden Sie einen YAML-Beispielausschnitt zur Verwendung von reviewApp unter Umgebungen.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Sammeln automatischer und benutzerspezifischer Metadaten aus der Pipeline
Jetzt können Sie die automatische und vom Benutzer angegebene Metadatensammlung aus Pipelinetasks aktivieren. Sie können Metadaten verwenden, um eine Artefaktrichtlinie für eine Umgebung zu erzwingen, indem Sie die Artefaktprüfung auswerten.
VM-Bereitstellungen mit Umgebungen
Eines der am häufigsten angeforderten Features in Umgebungen waren VM-Bereitstellungen. Mit diesem Update aktivieren wir die Vm-Ressource in Umgebungen. Sie können jetzt Bereitstellungen auf mehreren Computern orchestrieren und parallele Updates mithilfe von YAML-Pipelines durchführen. Sie können den Agent auch direkt auf jedem Ihrer Zielserver installieren und eine parallele Bereitstellung auf diesen Servern durchführen. Darüber hinaus können Sie den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.
Eine parallele Bereitstellung ersetzt Instanzen der vorherigen Version einer Anwendung durch Instanzen der neuen Version der Anwendung auf einer Gruppe von Computern (Rolling Set) in jeder Iteration.
Im Folgenden werden beispielsweise bis zu fünf Ziele in jeder Iteration aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Bei der Auswahl wird die Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, mit Ausnahme der Ziele, für die bereitgestellt wird, rechnung. Hiermit werden auch die Erfolgs- und Fehlerbedingungen während der Bereitstellung bestimmt.
jobs:
- deployment:
displayName: web
environment:
name: musicCarnivalProd
resourceType: VirtualMachine
strategy:
rolling:
maxParallel: 5 #for percentages, mention as x%
preDeploy:
steps:
- script: echo initialize, cleanup, backup, install certs...
deploy:
steps:
- script: echo deploy ...
routeTraffic:
steps:
- script: echo routing traffic...
postRouteTaffic:
steps:
- script: echo health check post routing traffic...
on:
failure:
steps:
- script: echo restore from backup ..
success:
steps:
- script: echo notify passed...
Hinweis
Mit diesem Update werden alle verfügbaren Artefakte aus der aktuellen Pipeline und aus den zugehörigen Pipelineressourcen nur in deploy lifecycle-hook heruntergeladen. Sie können jedoch den Download auswählen, indem Sie die Aufgabe "Pipelineartefakt herunterladen" angeben.
Es gibt einige bekannte Lücken in diesem Feature. Wenn Sie z. B. eine Phase wiederholen, wird die Bereitstellung auf allen VMs erneut ausgeführt, nicht nur auf Zielen mit Fehlern. Wir arbeiten daran, diese Lücken in zukünftigen Updates zu schließen.
Zusätzliche Steuerung Ihrer Bereitstellungen
Azure Pipelines unterstützt seit einiger Zeit Bereitstellungen, die mit manuellen Genehmigungen gesteuert werden. Mit den neuesten Verbesserungen haben Sie jetzt zusätzliche Kontrolle über Ihre Bereitstellungen. Zusätzlich zu Genehmigungen können Ressourcenbesitzer jetzt automatisierte checks Hinzufügen, um Sicherheits- und Qualitätsrichtlinien zu überprüfen. Diese Überprüfungen können verwendet werden, um Vorgänge auszulösen und dann darauf zu warten, dass sie abgeschlossen sind. Mithilfe der zusätzlichen Überprüfungen können Sie jetzt Integritätskriterien basierend auf mehreren Quellen definieren und sicher sein, dass alle Bereitstellungen, die auf Ihre Ressourcen abzielen, sicher sind, unabhängig davon, welche YAML-Pipeline die Bereitstellung durchführt. Die Auswertung jeder Überprüfung kann in regelmäßigen Abständen basierend auf dem angegebenen Wiederholungsintervall für die Überprüfung wiederholt werden.
Die folgenden zusätzlichen Überprüfungen sind jetzt verfügbar:
- Aufrufen einer beliebigen REST-API und Durchführen einer Überprüfung basierend auf dem Antworttext oder einem Rückruf vom externen Dienst
- Aufrufen einer Azure-Funktion und Durchführen einer Überprüfung basierend auf der Antwort oder einem Rückruf von der Funktion
- Abfragen von Azure Monitor-Regeln für aktive Warnungen
- Sicherstellen, dass die Pipeline eine oder mehrere YAML-Vorlagen erweitert
Genehmigungsbenachrichtigung
Wenn Sie einer Umgebung oder einer Dienstverbindung eine Genehmigung hinzufügen, warten alle mehrstufigen Pipelines, die die Ressource verwenden, automatisch zu Beginn der Phase auf die Genehmigung. Die benannten genehmigenden Personen müssen die Genehmigung abschließen, bevor die Pipeline fortgesetzt werden kann.
Mit diesem Update erhalten die genehmigenden Personen eine E-Mail-Benachrichtigung für die ausstehende Genehmigung. Benutzer und Teambesitzer können benutzerdefinierte Abonnements mithilfe von Benachrichtigungseinstellungen deaktivieren oder konfigurieren.
Konfigurieren von Bereitstellungsstrategien über Azure-Portal
Mit dieser Funktion haben wir es Ihnen erleichtert, Pipelines zu konfigurieren, die die Bereitstellungsstrategie Ihrer Wahl verwenden, z. B . Rolling, Canary oder Blau-Grün. Mithilfe dieser sofort einsatzbereiten Strategien können Sie Updates auf sichere Weise bereitstellen und die damit verbundenen Bereitstellungsrisiken minimieren. Klicken Sie auf einem virtuellen Azure-Computer auf die Einstellung "Continuous Delivery", um darauf zuzugreifen. Im Konfigurationsbereich werden Sie aufgefordert, Details zum Azure DevOps-Projekt auszuwählen, in dem die Pipeline erstellt wird, die Bereitstellungsgruppe, die Buildpipeline, die das bereitzustellende Paket veröffentlicht, und die Bereitstellungsstrategie Ihrer Wahl. Anschließend wird eine voll funktionsfähige Pipeline konfiguriert, die das ausgewählte Paket auf diesem virtuellen Computer bereitstellt.
Weitere Informationen finden Sie in unserer Dokumentation zum Konfigurieren von Bereitstellungsstrategien.
Laufzeitparameter
Laufzeitparameter ermöglichen Ihnen mehr Kontrolle darüber, welche Werte an eine Pipeline übergeben werden können. Im Gegensatz zu Variablen verfügen Laufzeitparameter über Datentypen und werden nicht automatisch zu Umgebungsvariablen. Mit Laufzeitparametern haben Sie folgende Möglichkeiten:
- Unterschiedliche Werte für Skripts und Aufgaben zur Laufzeit bereitstellen
- Parametertypen, zulässige Bereiche und Standardwerte steuern
- Dynamisches Auswählen von Aufträgen und Phasen mit Vorlagenausdruck
Weitere Informationen zu Laufzeitparametern finden Sie in der Dokumentation hier.
Verwenden von erweiterten Schlüsselwort (keyword) in Pipelines
Derzeit können Pipelines in Vorlagen integriert werden, um die Wiederverwendung zu fördern und die Bausteine zu reduzieren. Die Gesamtstruktur der Pipeline wurde weiterhin durch die YAML-Stammdatei definiert. Mit diesem Update haben wir eine strukturiertere Möglichkeit zur Verwendung von Pipelinevorlagen hinzugefügt. Eine YAML-Stammdatei kann jetzt die Schlüsselwort (keyword) erweitert verwenden, um anzugeben, dass die Standard Pipelinestruktur in einer anderen Datei gefunden werden kann. Dadurch können Sie steuern, welche Segmente erweitert oder geändert werden können und welche Segmente feststehen. Wir haben auch Pipelineparameter mit Datentypen verbessert, um die Hooks zu verdeutlichen, die Sie bereitstellen können.
In diesem Beispiel wird veranschaulicht, wie Sie einfache Hooks für den Pipelineautor bereitstellen können. Die Vorlage führt immer einen Build aus, führt optional zusätzliche Schritte aus, die von der Pipeline bereitgestellt werden, und führt dann einen optionalen Testschritt aus.
# azure-pipelines.yml
extends:
template: build-template.yml
parameters:
runTests: true
postBuildSteps:
- script: echo This step runs after the build!
- script: echo This step does too!
# build-template.yml
parameters:
- name: runTests
type: boolean
default: false
- name: postBuildSteps
type: stepList
default: []
steps:
- task: MSBuild@1 # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
- task: VSTest@2 # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
- ${{ step }}
Steuerungsvariablen, die zur Warteschlangenzeit überschrieben werden können
Zuvor konnten Sie die Benutzeroberfläche oder rest-API verwenden, um die Werte einer beliebigen Variablen zu aktualisieren, bevor sie eine neue Ausführung starten. Während der Autor der Pipeline bestimmte Variablen als _settable at queue time_markieren kann, hat das System dies weder erzwungen noch verhindert, dass andere Variablen festgelegt werden. Anders ausgedrückt: Die Einstellung wurde nur verwendet, um beim Starten einer neuen Ausführung zur Eingabe zusätzlicher 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-Sammlung erstellen.
Neue vordefinierte Variablen in der YAML-Pipeline
Variablen sind eine praktische Möglichkeit, wichtige Daten in verschiedene Teile Ihrer Pipeline einzufügen. Mit diesem Update haben wir einem Bereitstellungsauftrag einige vordefinierte Variablen hinzugefügt. Diese Variablen werden automatisch vom System festgelegt, auf den jeweiligen Bereitstellungsauftrag festgelegt und sind schreibgeschützt.
- Environment.Id: Die ID der Umgebung.
- Environment.Name: Der Name der Umgebung, auf die der Bereitstellungsauftrag abzielt.
- Environment.ResourceId: Die ID der Ressource in der Umgebung, auf die der Bereitstellungsauftrag abzielt.
- Environment.ResourceName: Der Name der Ressource in der Umgebung, auf die der Bereitstellungsauftrag abzielt.
Auschecken mehrerer Repositorys
Pipelines basieren häufig auf mehreren Repositorys. Sie können verschiedene Repositorys mit Quelle, Tools, Skripts oder anderen Elementen verwenden, die Sie zum Erstellen Ihres Codes benötigen. Zuvor mussten Sie diese Repositorys als Untermodule oder als manuelle Skripts hinzufügen, um git checkout auszuführen. Jetzt können Sie zusätzlich zu dem Repository, das Sie zum Speichern Ihrer YAML-Pipeline verwenden, andere Repositorys abrufen und auschecken.
Wenn Sie beispielsweise über ein Repository namens MyCode mit einer YAML-Pipeline und einem zweiten Repository namens Tools verfügen, sieht Ihre YAML-Pipeline wie folgt aus:
resources:
repositories:
- repository: tools
name: Tools
type: git
steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)
Im dritten Schritt werden die beiden Verzeichnisse MyCode und Tools im Verzeichnis sources angezeigt.
Azure Repos Git-Repositorys werden unterstützt. Weitere Informationen finden Sie unter Auschecken mehrerer Repositorys.
Abrufen von Details zur Laufzeit zu mehreren Repositorys
Wenn eine Pipeline ausgeführt wird, fügt Azure Pipelines Informationen zum Repository, Branch und Commit hinzu, die die Ausführung ausgelöst haben. Da YAML-Pipelines nun das Auschecken mehrerer Repositorys unterstützen, können Sie auch das Repository, den Branch und den Commit kennen, die für andere Repositorys ausgecheckt wurden. Diese Daten sind über einen Laufzeitausdruck verfügbar, den Sie nun einer Variablen zuordnen können. Beispiel:
resources:
repositories:
- repository: other
type: git
name: MyProject/OtherTools
variables:
tools.ref: $[ resources.repositories['other'].ref ]
steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"
Zulassen von Repositoryverweise auf andere Azure Repos Sammlungen
Wenn Sie zuvor auf Repositorys in einer YAML-Pipeline verwiesen haben, mussten sich alle Azure Repos Repositorys in derselben Sammlung wie die Pipeline befinden. Jetzt können Sie mithilfe einer Dienstverbindung auf Repositorys in anderen Sammlungen verweisen. Beispiel:
resources:
repositories:
- repository: otherrepo
name: ProjectName/RepoName
endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo
MyServiceConnection verweist auf eine andere Azure DevOps-Sammlung und verfügt über Anmeldeinformationen, die auf das Repository in einem anderen Projekt zugreifen können. Beide Repositorys self und otherrepowerden am Ende ausgecheckt.
Wichtig
MyServiceConnectionmuss eine Azure Repos-/Team Foundation Server-Dienstverbindung sein, sehen Sie sich die folgende Abbildung an.
Pipelineressourcenmetadaten als vordefinierte Variablen
Wir haben vordefinierte Variablen für YAML-Pipelineressourcen in der Pipeline hinzugefügt. Hier ist die Liste der verfügbaren Pipelineressourcenvariablen.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
kustomize and kompose as bake options in KubernetesManifest task
mit kustomize (Teil von Kubernetes sig-cli) können Sie unformatierte, vorlagenfreie YAML-Dateien für mehrere Zwecke anpassen und die ursprüngliche YAML-Datei unberührt lassen. Eine Option für kustomize wurde unter der Bake-Aktion des KubernetesManifest-Tasks hinzugefügt, sodass jeder Ordner, der kustomization.yaml-Dateien enthält, zum Generieren der Manifestdateien verwendet werden kann, die in der Bereitstellungsaktion der KubernetesManifest-Aufgabe verwendet werden.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
kompose transformiert eine Docker Compose-Datei in eine Kubernetes-Ressource.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
Unterstützung für Clusteradministratoranmeldeinformationen im HelmDeploy-Task
Zuvor hat der HelmDeploy-Task die Clusterbenutzeranmeldeinformationen für Bereitstellungen verwendet. Dies führte zu interaktiven Anmeldeaufforderungen und fehlerhaften Pipelines für einen Azure Active Directory-basierten RBAC-fähigen Cluster. Um dieses Problem zu beheben, haben wir ein Kontrollkästchen hinzugefügt, mit dem Sie anstelle der Anmeldeinformationen eines Clusterbenutzers Anmeldeinformationen für Den Clusteradministrator verwenden können.
Eingabe von Argumenten im Docker Compose-Task
In der Docker Compose-Aufgabe wurde ein neues Feld eingeführt, mit dem Sie Argumente wie --no-cachehinzufügen können. Das Argument wird von der Aufgabe übergeben, wenn Befehle wie build ausgeführt werden.
Verbesserungen von GitHub-Releasetasks
Wir haben mehrere Verbesserungen an der GitHub Release-Aufgabe vorgenommen. Sie können jetzt die Erstellung von Releases mithilfe des Tagmusterfelds besser steuern, indem Sie einen regulären Tagausdruck angeben. Die Freigabe wird nur erstellt, wenn der auslösende Commit mit einer übereinstimmenden Zeichenfolge markiert ist.
Wir haben auch Funktionen zum Anpassen der Erstellung und Formatierung von Changelog hinzugefügt. Im neuen Abschnitt für die Changelogkonfiguration können Sie nun das Release angeben, mit dem das aktuelle Release verglichen werden soll. Der Vergleich mit Release kann das letzte vollständige Release (ohne Vorabversionen), das letzte Nicht-Entwurfs-Release oder ein beliebiges vorheriges Release sein, das dem angegebenen Releasetag entspricht. Darüber hinaus stellt der Task das Changelogtypfeld bereit, um das Changelog zu formatieren. Basierend auf der Auswahl zeigt das Changelog entweder eine Liste von Commits oder eine Liste von Problemen/PRs an, die basierend auf Bezeichnungen kategorisiert sind.
Installationsprogramm für den Richtlinien-Agent öffnen
Der Open Policy-Agent ist eine Open Source allgemeine Richtlinien-Engine, die eine einheitliche, kontextbezogene Richtlinienerzwingung ermöglicht. Wir haben die Installationstask "Open Policy Agent" hinzugefügt. Dies ist besonders nützlich für die In-Pipeline-Richtlinienerzwingung in Bezug auf Infrastructure-as-Code-Anbieter.
Der Open Policy-Agent kann beispielsweise Rego-Richtliniendateien und Terraform-Pläne in der Pipeline auswerten.
task: OpenPolicyAgentInstaller@0
inputs:
opaVersion: '0.13.5'
Unterstützung für PowerShell-Skripts im Azure CLI-Task
Zuvor konnten Sie Batch- und Bashskripts als Teil einer Azure CLI-Aufgabe ausführen. Mit diesem Update haben wir der Aufgabe Unterstützung für PowerShell- und PowerShell-Kernskripts hinzugefügt.
Service Mesh Interface-basierte Canary-Bereitstellungen im KubernetesManifest-Task
Wenn die Canary-Strategie zuvor im KubernetesManifest-Task angegeben wurde, wurden Mit der Aufgabe Baseline- und Canary-Workloads erstellt, deren Replikate einem Prozentsatz der Replikate entsprachen, die für stabile Workloads verwendet werden. Dies war nicht identisch mit dem Aufteilen des Datenverkehrs auf den gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir der KubernetesManifest-Aufgabe Unterstützung für Service Mesh Interface-basierte Canary-Bereitstellungen hinzugefügt.
Die Abstraktion der Service Mesh-Schnittstelle ermöglicht die Plug-and-Play-Konfiguration mit Service Mesh-Anbietern wie Linkerd und Istio. Nun nimmt die KubernetesManifest-Aufgabe die harte Arbeit, die TrafficSplit-Objekte von SMI den stabilen, Baseline- und Canary-Diensten während des Lebenszyklus der Bereitstellungsstrategie zuzuordnen. Die gewünschte prozentuale Aufteilung des Datenverkehrs zwischen Stable, Baseline und Canary ist genauer, da die prozentuale Datenverkehrsteilung für die Anforderungen in der Dienstgitterebene gesteuert wird.
Im Folgenden wird ein Beispiel für die fortlaufende Ausführung von SMI-basierten Canary-Bereitstellungen gezeigt.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
Azure File Copy Task unterstützt jetzt AzCopy V10
Der Azure-Dateikopiertask kann in einer Build- oder Releasepipeline verwendet werden, um Dateien in Microsoft-Speicherblobs oder virtuelle Computer (VMs) zu kopieren. Die Aufgabe verwendet AzCopy, das Befehlszeilenhilfsprogramm zum schnellen Kopieren von Daten aus und in Azure-Speicherkonten. Mit diesem Update haben wir Unterstützung für AzCopy V10 hinzugefügt, die neueste Version von AzCopy.
Der azcopy copy Befehl unterstützt nur die damit verbundenen Argumente . Aufgrund der Änderung der Syntax von AzCopy sind einige der vorhandenen Funktionen in AzCopy V10 nicht verfügbar. Dazu zählen unter anderem folgende Einstellungen:
- Angeben des Protokollspeicherorts
- Bereinigen von Protokoll- und Plandateien nach dem Kopieren
- Fortsetzen des Kopierens bei Einem Auftragsfehler
Die zusätzlichen Funktionen, die in dieser Version der Aufgabe unterstützt werden, sind:
- Feldhaltersymbole im Dateinamen/Pfad der Quelle
- Ableiten des Inhaltstyps basierend auf der Dateierweiterung, wenn keine Argumente bereitgestellt werden
- Definieren der Protokoll-Ausführlichkeit für die Protokolldatei durch Übergeben eines Arguments
Verbessern der Pipelinesicherheit durch Einschränken des Umfangs von Zugriffstoken
Jeder Auftrag, der in Azure Pipelines ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und Von Ihren Skripts verwendet, um azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Protokolle hochzuladen, Testergebnisse, Artefakte oder REST-Aufrufe in Azure DevOps durchzuführen. Für jeden Auftrag wird ein neues Zugriffstoken generiert, das nach Abschluss des Auftrags abläuft. Mit diesem Update haben wir die folgenden Verbesserungen hinzugefügt.
Verhindern des Zugriffs des Tokens auf Ressourcen außerhalb eines Teamprojekts
Bisher war der Standardbereich aller Pipelines die Teamprojektsammlung. Sie können den Bereich in klassischen Buildpipelines in das Teamprojekt ändern. Für klassische Release- oder YAML-Pipelines hatten Sie diese Kontrolle jedoch nicht. Mit diesem Update führen wir eine Sammlungseinstellung ein, um zu erzwingen, dass jeder Auftrag ein projektbezogenes Token erhält, unabhängig davon, was in der Pipeline konfiguriert ist. Außerdem haben wir die Einstellung auf Projektebene hinzugefügt. Nun ist diese Einstellung für jedes neue Projekt und jede neue Sammlung, die Sie erstellen, automatisch aktiviert.
Hinweis
Die Auflistungseinstellung überschreibt die Projekteinstellung.
Das Aktivieren dieser Einstellung in vorhandenen Projekten und Sammlungen kann dazu führen, dass bestimmte Pipelines fehlschlagen, wenn Ihre Pipelines mithilfe von Zugriffstoken auf Ressourcen außerhalb des Teamprojekts zugreifen. Um Pipelinefehler zu minimieren, können Sie dem Project Build-Dienstkonto explizit Zugriff auf die gewünschte Ressource gewähren. Es wird dringend empfohlen, diese Sicherheitseinstellungen zu aktivieren.
Einschränken des Zugriffs auf builddienstrepository scope
Aufbauend auf der Verbesserung der Pipelinesicherheit durch Einschränken des Umfangs des Zugriffstokens kann Azure Pipelines den Repositoryzugriff jetzt auf die für eine YAML-basierte Pipeline erforderlichen Repositorys beschränken. Dies bedeutet, dass im Fall eines Verlusts des Zugriffstokens der Pipelines nur die in der Pipeline verwendeten Repositorys angezeigt werden. Bisher eignete sich das Zugriffstoken für alle Azure Repos Repositorys im Projekt oder möglicherweise für die gesamte Sammlung.
Dieses Feature ist für neue Projekte und Sammlungen standardmäßig aktiviert. Für vorhandene Sammlungen müssen Sie sie in denPipelineeinstellungen für Auflistungseinstellungen>> aktivieren. Bei Verwendung dieses Features müssen alle Repositorys, die für den Build benötigt werden (auch diejenigen, die Sie mit einem Skript klonen) in die Repositoryressourcen der Pipeline eingeschlossen werden.
Entfernen bestimmter Berechtigungen für das Zugriffstoken
Standardmäßig gewähren wir dem Zugriffstoken eine Reihe von Berechtigungen. Eine dieser Berechtigungen ist Warteschlangenbuilds. Mit diesem Update haben wir diese Berechtigung für das Zugriffstoken entfernt. Wenn Ihre Pipelines diese Berechtigung benötigen, können Sie sie je nach verwendetem Token explizit dem Project Build-Dienstkonto oder dem Projektsammlungsdienstkonto gewähren.
Sicherheit auf Projektebene für Dienstverbindungen
Wir haben sicherheit auf Hubebene für Dienstverbindungen hinzugefügt. Jetzt können Sie An einem zentralen Ort für alle Dienstverbindungen Benutzer hinzufügen/entfernen, Rollen zuweisen und den Zugriff verwalten.
Schrittadressierung und Befehlsisolation
Azure Pipelines unterstützt die Ausführung von Aufträgen in Containern oder auf dem Agenthost. Zuvor wurde ein vollständiger Auftrag auf eines dieser beiden Ziele festgelegt. Jetzt können einzelne Schritte (Aufgaben oder Skripts) auf dem von Ihnen ausgewählten Ziel ausgeführt werden. Schritte können auch auf andere Container ausgerichtet sein, sodass eine Pipeline jeden Schritt in einem speziellen, speziell entwickelten Container ausführen kann.
Container können als Isolationsgrenzen fungieren und verhindern, dass Code unerwartete Änderungen auf dem Hostcomputer vornimmt. Die Art und Weise, wie Schritte mit dem Agent kommunizieren und auf Dienste zugreifen , wird nicht durch das Isolieren von Schritten in einem Container beeinflusst. Daher führen wir auch einen Befehlseinschränkungsmodus ein, den Sie mit Schrittzielen verwenden können. Wenn Sie dies aktivieren, werden die Dienste eingeschränkt, die ein Schritt vom Agent anfordern kann. Es ist nicht mehr in der Lage, Protokolle anzufügen, Artefakte hochzuladen und bestimmte andere Vorgänge.
Hier sehen Sie ein umfassendes Beispiel, das die Ausführungsschritte auf dem Host in einem Auftragscontainer und in einem anderen Container zeigt:
resources:
containers:
- container: python
image: python:3.8
- container: node
image: node:13.2
jobs:
- job: example
container: python
steps:
- script: echo Running in the job container
- script: echo Running on the host
target: host
- script: echo Running in another container, in restricted commands mode
target:
container: node
commands: restricted
Schreibgeschützte Variablen
Systemvariablen wurden als unveränderlich dokumentiert, aber in der Praxis könnten sie von einer Aufgabe überschrieben werden, und nachgeschaltete Aufgaben würden den neuen Wert übernehmen. Mit diesem Update wird die Sicherheit in Bezug auf Pipelinevariablen verschärft, damit System- und Warteschlangenzeitvariablen schreibgeschützt werden. Darüber hinaus können Sie eine YAML-Variable schreibgeschützt machen, indem Sie sie wie folgt markieren.
variables:
- name: myVar
value: myValue
readonly: true
Rollenbasierter Zugriff für Dienstverbindungen
Wir haben den rollenbasierten Zugriff für Dienstverbindungen hinzugefügt. Bisher konnte die Dienstverbindungssicherheit nur über vordefinierte Azure DevOps-Gruppen wie Endpunktadministratoren und Endpunktersteller verwaltet werden.
Im Rahmen dieser Arbeit haben wir die neuen Rollen Leser, Benutzer, Ersteller und Administrator eingeführt. Sie können diese Rollen über die Dienstverbindungsseite in Ihrem Projekt festlegen, und diese werden von den einzelnen Verbindungen geerbt. In jeder Dienstverbindung haben Sie die Möglichkeit, die Vererbung zu aktivieren oder zu deaktivieren und die Rollen im Bereich der Dienstverbindung außer Kraft zu setzen.
Weitere Informationen zur Sicherheit von Dienstverbindungen finden Sie hier.
Projektübergreifende Freigabe von Dienstverbindungen
Wir haben die Unterstützung für die projektübergreifende Freigabe von Dienstverbindungen aktiviert. Sie können Ihre Dienstverbindungen jetzt sicher und sicher für Ihre Projekte freigeben.
Weitere Informationen zur Freigabe von Dienstverbindungen finden Sie hier.
Nachverfolgbarkeit für Pipelines und ACR-Ressourcen
Wir stellen die vollständige E2E-Rückverfolgbarkeit sicher, wenn Pipelines und ACR-Containerressourcen in einer Pipeline verwendet werden. Für jede Ressource, die von Ihrer YAML-Pipeline genutzt wird, können Sie zu den Commits, Arbeitselementen und Artefakten zurückverfolgen.
In der Zusammenfassungsansicht der Pipelineausführung sehen Sie Folgendes:
Die Ressourcenversion, die die Ausführung ausgelöst hat. Jetzt kann Ihre Pipeline ausgelöst werden, wenn eine andere Azure-Pipelineausführung abgeschlossen ist oder wenn ein Containerimage an ACR gepusht wird.
Die Commits , die von der Pipeline verwendet werden. Sie finden auch die Aufschlüsselung der Commits nach den einzelnen Ressourcen, die von der Pipeline genutzt werden.
Die Arbeitselemente , die jeder ressource zugeordnet sind, die von der Pipeline genutzt wird.
Die Artefakte , die von der Ausführung verwendet werden können.
In der Bereitstellungsansicht der Umgebung werden die Commits und Arbeitselemente für jede Ressource angezeigt, die in der Umgebung bereitgestellt wird.
Unterstützung für große Testanlagen
Mit der Aufgabe Testergebnisse veröffentlichen in Azure Pipelines können Sie Testergebnisse veröffentlichen, wenn Tests ausgeführt werden, um umfassende Testberichte und Analysen bereitzustellen. Bisher galt ein Grenzwert von 100 MB für Testanlagen sowohl für Testlauf- als auch für Testergebnisse. Dadurch wurde das Hochladen großer Dateien wie Absturzabbilder oder Videos eingeschränkt. Mit diesem Update haben wir Unterstützung für große Testanlagen hinzugefügt, sodass Sie alle verfügbaren Daten zur Problembehandlung für fehlerhafte Tests haben können.
Möglicherweise wird der VSTest-Task oder der Task Testergebnisse veröffentlichen angezeigt, der den Fehler 403 oder 407 in den Protokollen zurückgibt. Wenn Sie selbstgehostete Builds oder Release-Agents hinter einer Firewall verwenden, die ausgehende Anforderungen filtert, müssen Sie einige Konfigurationsänderungen vornehmen, um diese Funktionalität verwenden zu können.
Um dieses Problem zu beheben, wird empfohlen, die Firewall für ausgehende Anforderungen auf zu https://*.vstmrblob.vsassets.ioaktualisieren. Informationen zur Problembehandlung finden Sie in der Dokumentation hier.
Hinweis
Dies ist nur erforderlich, wenn Sie selbstgehostete Azure Pipelines-Agents verwenden und sich hinter einer Firewall befinden, die ausgehenden Datenverkehr filtert. Wenn Sie von Microsoft gehostete Agents in der Cloud verwenden oder den ausgehenden Netzwerkdatenverkehr nicht filtern, müssen Sie keine Maßnahmen ergreifen.
Anzeigen der richtigen Poolinformationen für jeden Auftrag
Wenn Sie zuvor eine Matrix zum Erweitern von Aufträgen oder eine Variable verwendet haben, um einen Pool zu identifizieren, wurden manchmal falsche Poolinformationen auf den Protokollseiten behoben. Diese Probleme wurden behoben.
CI-Trigger für neue Branches
Es war eine lange ausstehende Anforderung, keine CI-Builds auszulösen, wenn ein neuer Branch erstellt wird und wenn dieser Branch keine Änderungen aufweist. Betrachten Sie die folgenden Beispiele:
- Sie verwenden die Weboberfläche, um einen neuen Branch basierend auf einem vorhandenen Branch zu erstellen. Dadurch würde sofort ein neuer CI-Build ausgelöst, wenn der Branchfilter mit dem Namen des neuen Branchs übereinstimmt. Dies ist nicht erwünscht, da der Inhalt des neuen Branchs im Vergleich zum vorhandenen Branch identisch ist.
- Sie verfügen über ein Repository mit zwei Ordnern : app und Docs. Sie richten einen Pfadfilter für CI ein, der mit "app" übereinstimmt. Anders ausgedrückt: Sie möchten keinen neuen Build erstellen, wenn eine Änderung per Push in die Dokumentation übertragen wurde. Sie erstellen einen neuen Branch lokal, nehmen einige Änderungen an der Dokumentation vor und pushen diesen Branch dann an den Server. Wir haben früher einen neuen CI-Build ausgelöst. Dies ist unerwünscht, da Sie explizit aufgefordert haben, nicht nach Änderungen im Docs-Ordner zu suchen. Aufgrund der Art und Weise, wie wir ein neues Branchereignis behandelt haben, sieht es jedoch so aus, als ob auch eine Änderung am App-Ordner vorgenommen wurde.
Jetzt haben wir eine bessere Möglichkeit, CI für neue Branches zu behandeln, um diese Probleme zu beheben. Wenn Sie einen neuen Branch veröffentlichen, suchen wir explizit nach neuen Commits in diesem Branch und überprüfen, ob sie den Pfadfiltern entsprechen.
Aufträge können auf Ausgabevariablen aus vorherigen Phasen zugreifen.
Ausgabevariablen können jetzt phasenübergreifend in einer YAML-basierten Pipeline verwendet werden. Auf diese Weise können Sie nützliche Informationen, z. B. eine Go/No-Go-Entscheidung oder die ID einer generierten Ausgabe, von einer Phase zur nächsten übergeben. Das Ergebnis (status) einer vorherigen Phase und ihrer Aufträge ist ebenfalls verfügbar.
Ausgabevariablen werden weiterhin von Schritten innerhalb von Aufträgen erzeugt. Anstatt auf zu dependencies.jobName.outputs['stepName.variableName']verweisen, verweisen Phasen auf stageDependencies.stageName.jobName.outputs['stepName.variableName'].
Hinweis
Standardmäßig hängt jede Phase in einer Pipeline von der Phase ab, die sich in der YAML-Datei unmittelbar vor ihr befindet. Daher kann jede Phase Ausgabevariablen aus der vorherigen Phase verwenden. Sie können die Abhängigkeitsdiagramm ändern, wodurch auch geändert wird, welche Ausgabevariablen verfügbar sind. Wenn Phase 3 für instance eine Variable aus Phase 1 benötigt, muss sie eine explizite Abhängigkeit in Phase 1 deklarieren.
Deaktivieren automatischer 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, für die eine neuere Agent-Version erforderlich ist, um ordnungsgemäß zu funktionieren. Mit diesem Update fügen wir die Möglichkeit hinzu, automatische Upgrades auf Poolebene zu deaktivieren. Wenn in diesem Modus kein Agent der richtigen Version mit dem Pool verbunden ist, schlagen Pipelines mit einer eindeutigen Fehlermeldung fehl, anstatt Agents zum Aktualisieren anzufordern. Dieses Feature ist vor allem für Kunden mit selbstgehosteten Pools und sehr strengen Anforderungen an die Änderungssteuerung von Interesse. Automatische Updates sind standardmäßig aktiviert, und die meisten Kunden sollten sie nicht deaktivieren.
Agent-Diagnose
Wir haben Diagnose für viele häufige Agent-bezogene Probleme hinzugefügt, z. B. viele Netzwerkprobleme und häufige Ursachen von Upgradefehlern. Verwenden Sie für die ersten Schritte mit Diagnose unter Windows run.sh --Diagnose oder run.cmd --Diagnose.
Diensthooks für YAML-Pipelines
Die Integration von Diensten in YAML-Pipelines wurde noch einfacher. Mithilfe von Service Hooks-Ereignissen für YAML-Pipelines können Sie jetzt Aktivitäten in benutzerdefinierten Apps oder Diensten basierend auf dem Fortschritt der Pipelineausführungen steuern. Sie können beispielsweise ein Helpdeskticket erstellen, wenn eine Genehmigung erforderlich ist, einen Überwachungsworkflow nach Abschluss einer Phase initiieren oder eine Pushbenachrichtigung an die mobilen Geräte Ihres Teams senden, wenn eine Phase fehlschlägt.
Das Filtern nach Pipelinenamen und Phasennamen wird für alle Ereignisse unterstützt. Genehmigungsereignisse können auch nach bestimmten Umgebungen gefiltert werden. Ebenso können Zustandsänderungsereignisse nach dem neuen Zustand der Pipelineausführung oder der Phase gefiltert werden.
Optimizely-Integration
Optimizely ist eine leistungsstarke A/B-Test- und Featuremarkierungsplattform für Produktteams. Durch die Integration von Azure Pipelines mit der Optimizely-Experimentierplattform können Produktteams schneller testen, lernen und bereitstellen und gleichzeitig alle DevOps-Vorteile von Azure Pipelines nutzen.
Die Optimizely-Erweiterung für Azure DevOps fügt den Build- und Releasepipelines Experimentier- und Featureflagsrollingschritte hinzu, sodass Sie features kontinuierlich durchlaufen, bereitstellen und mithilfe von Azure Pipelines rollbacken können.
Weitere Informationen zur Azure DevOps Optimizely-Erweiterung finden Sie hier.
Hinzufügen einer GitHub-Version als Artefaktquelle
Jetzt können Sie Ihre GitHub-Releases als Artefaktquelle in Azure DevOps-Releasepipelines verknüpfen. Dadurch können Sie das GitHub-Release als Teil Ihrer Bereitstellungen nutzen.
Wenn Sie in der Releasepipelinedefinition auf Artefakt hinzufügen klicken, finden Sie den neuen GitHub Release-Quelltyp . Sie können die Dienstverbindung und das GitHub-Repository bereitstellen, um das GitHub-Release zu nutzen. Sie können auch eine Standardversion für das GitHub-Release auswählen, die als neueste, bestimmte Tagversion verwendet werden soll, oder zum Zeitpunkt der Releaseerstellung auswählen. Sobald ein GitHub-Release verknüpft ist, wird es automatisch heruntergeladen und in Ihren Releaseaufträgen verfügbar gemacht.
Terraform-Integration mit Azure Pipelines
Terraform ist ein Open-Source-Tool zum sicheren und effizienten Entwickeln, Ändern und Versionsverwaltung von Infrastruktur. Terraform codiert APIs in deklarative Konfigurationsdateien, sodass Sie die Infrastruktur mithilfe einer allgemeinen Konfigurationssprache definieren und bereitstellen können. Sie können die Terraform-Erweiterung verwenden, um Ressourcen für alle wichtigen Infrastrukturanbieter zu erstellen: Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP).
Weitere Informationen zur Terraform-Erweiterung finden Sie in der Dokumentation hier.
Integration in Google Analytics
Mit dem Google Analytics-Experimentframework können Sie nahezu jede Änderung oder Variation einer Website oder App testen, um deren Auswirkungen auf ein bestimmtes Ziel zu messen. Beispielsweise können Sie Aktivitäten haben, die Ihre Benutzer durchführen sollen (z. B. einen Kauf tätigen, sich für einen Newsletter registrieren) und/oder Metriken, die Sie verbessern möchten (z. B. Umsatz, Sitzungsdauer, Unzustellbarkeitsrate). Mit diesen Aktivitäten können Sie Änderungen identifizieren, die sich auf der Grundlage der direkten Auswirkungen auf die Leistung Ihres Features lohnen.
Die Erweiterung für Google Analytics-Experimente für Azure DevOps fügt den Build- und Releasepipelines Experimentierschritte hinzu, sodass Sie kontinuierlich durchlaufen, lernen und bereitstellen können, indem Sie die Experimente kontinuierlich verwalten und gleichzeitig alle DevOps-Vorteile von Azure Pipelines nutzen.
Sie können die Erweiterung für Google Analytics-Experimente aus dem Marketplace herunterladen.
Aktualisierte ServiceNow-Integration mit Azure Pipelines
Die Azure Pipelines-App für ServiceNow unterstützt die Integration von Azure Pipelines und ServiceNow Change Management. Mit diesem Update können Sie in die New York-Version von ServiceNow integrieren. Die Authentifizierung zwischen den beiden Diensten kann jetzt mithilfe von OAuth und der Standardauthentifizierung erfolgen. Darüber hinaus können Sie jetzt erweiterte Erfolgskriterien konfigurieren, sodass Sie eine beliebige Änderungseigenschaft verwenden können, um das Gate-Ergebnis zu bestimmen.
Erstellen von Azure Pipelines aus VSCode
Wir haben der Azure Pipelines-Erweiterung für VSCode eine neue Funktionalität hinzugefügt. Jetzt können Sie Azure Pipelines direkt aus VSCode erstellen, ohne die IDE zu verlassen.
Verwaltung und Lösung von Flaky-Fehlern
Wir haben die Schuppentestverwaltung eingeführt, um den End-to-End-Lebenszyklus mit Erkennung, Berichterstellung und Lösung zu unterstützen. Um dies weiter zu verbessern, fügen wir das Problemmanagement und die Lösung von Fehlern für lappende Tests hinzu.
Bei der Untersuchung des schuppigen Tests können Sie mithilfe der Bug-Aktion einen Fehler erstellen, der einem Entwickler zugewiesen werden kann, um die Grundursache des schläfenden Tests weiter zu untersuchen. Der Fehlerbericht enthält Informationen zur Pipeline wie Fehlermeldung, Stapelüberwachung und andere Informationen, die dem Test zugeordnet sind.
Wenn ein Fehlerbericht aufgelöst oder geschlossen wird, heben wir die Markierung des Tests automatisch als unproblemaisch auf.
Festlegen eines Fehlers für VSTest-Tasks, wenn eine mindeste Anzahl von Tests nicht ausgeführt wird
Die VSTest-Aufgabe ermittelt Und führt Tests mithilfe von Benutzereingaben (Testdateien, Filterkriterien usw.) sowie einem Testadapter aus, der für das verwendete Testframework spezifisch ist. Änderungen an Benutzereingaben oder am Testadapter können dazu führen, dass Tests nicht erkannt werden und nur eine Teilmenge der erwarteten Tests ausgeführt wird. Dies kann zu Situationen führen, in denen Pipelines erfolgreich sind, weil Tests übersprungen werden, anstatt dass der Code von ausreichend hoher Qualität ist. Um diese Situation zu vermeiden, haben wir eine neue Option in der VSTest-Aufgabe hinzugefügt, mit der Sie die Mindestanzahl von Tests angeben können, die ausgeführt werden müssen, damit die Aufgabe bestanden werden kann.
Die VSTest TestResultsDirectory-Option ist auf der Task-Benutzeroberfläche verfügbar.
Die VSTest-Aufgabe speichert Testergebnisse und zugeordnete $(Agent.TempDirectory)\TestResults Dateien im Ordner. Wir haben der Task-Benutzeroberfläche eine Option hinzugefügt, mit der Sie einen anderen Ordner zum Speichern von Testergebnissen konfigurieren können. Jetzt können alle nachfolgenden Aufgaben, die die Dateien an einem bestimmten Speicherort benötigen, diese verwenden.
Markdownunterstützung in automatisierten Testfehlermeldungen
Wir haben Markdownunterstützung für Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie Fehlermeldungen sowohl für testausführungs- als auch für testergebnisse problemlos formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu vereinfachen. Die unterstützte Markdownsyntax finden Sie hier.
Verwenden von Pipelinedekortoren zum automatischen Einfügen von Schritten in einen Bereitstellungsauftrag
Sie können jetzt Pipeline-Decorators zu Bereitstellungsaufträgen hinzufügen. Sie können jeden benutzerdefinierten Schritt (z. B. die Überprüfung von Sicherheitsrisiken) automatisch in die Ausführung jedes Lebenszyklus-Hooks jedes Bereitstellungsauftrags einfügen lassen. Da Pipeline-Decorators auf alle Pipelines in einer Sammlung angewendet werden können, kann dies als Teil der Erzwingung sicherer Bereitstellungsmethoden genutzt werden.
Darüber hinaus können Bereitstellungsaufträge als Containerauftrag zusammen mit Service-Sidecar ausgeführt werden, wenn definiert.
Test Plans
Seite "Neuer Testplan"
Eine neue Test Plans-Seite (Test Plans *) ist für alle Azure DevOps-Sammlungen verfügbar. Die neue Seite bietet optimierte Ansichten, die Ihnen helfen, sich auf die anstehenden Aufgaben zu konzentrieren – Testplanung, Erstellung oder Ausführung. Außerdem ist es übersichtlich und konsistent mit dem rest des Azure DevOps-Angebots.
Helfen Sie mir, die neue Seite zu verstehen
Die neue seite Test Plans umfasst insgesamt 6 Abschnitte, von denen die ersten 4 neu sind, während die Abschnitte Zur Erweiterbarkeit von Diagrammen & die vorhandene Funktionalität darstellen.
- Testplanheader: Verwenden Sie diese Option, um einen Testplan zu suchen, als Favorit zu suchen, zu bearbeiten, zu kopieren oder zu klonen.
- Testsammlungsstruktur: Verwenden Sie diese Struktur, um Testsammlungen hinzuzufügen, zu verwalten, zu exportieren oder zu bestellen. Nutzen Sie dies, um auch Konfigurationen zuzuweisen und Benutzerakzeptanztests durchzuführen.
- Registerkarte definieren: Über diese Registerkarte können Sie Testfälle in einer Testsammlung Ihrer Wahl sortieren, hinzufügen und verwalten.
- Registerkarte "Ausführen": Weisen Sie Tests über diese Registerkarte zu, und führen Sie sie aus, oder suchen Sie ein Testergebnis, in das Sie einen Drilldown ausführen möchten.
- Registerkarte Diagramm: Verfolgen Sie die Testausführung und status über Diagramme, die auch an Dashboards angeheftet werden können.
- Erweiterbarkeit: Unterstützt die aktuellen Erweiterbarkeitspunkte innerhalb des Produkts.
Lassen Sie uns eine umfassende Strichansicht dieser neuen Abschnitte unten sehen.
1. Testplanheader
Aufgaben
Mit dem Testplanheader können Sie die folgenden Aufgaben ausführen:
- Markieren eines Testplans als Favorit
- Aufheben der Markierung eines bevorzugten Testplans
- Einfaches Navigieren zwischen Ihren bevorzugten Testplänen
- Anzeigen des Iterationspfads des Testplans, der deutlich angibt, ob der Testplan Aktuell oder Vergangenheit ist
- Anzeigen der schnellen Zusammenfassung des Teststatusberichts mit einem Link zum Navigieren zum Bericht
- Navigieren Sie zurück zur Seite All/Mine Test Plans
Kontextmenüoptionen
Das Kontextmenü im Header Testplan bietet die folgenden Optionen:
- Kopieren des Testplans: 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 Formular testplan-Arbeitselement bearbeiten, um die Arbeitselementfelder zu verwalten.
- Testplaneinstellungen: Mit dieser Option können Sie die Testlaufeinstellungen (zum Zuordnen von Build- oder Releasepipelines) und die Testergebniseinstellungen konfigurieren.
Kopieren des Testplans (neue Funktion)
Es wird empfohlen, einen neuen Testplan pro Sprint/Release zu erstellen. Dabei kann im Allgemeinen der Testplan für den vorherigen Zyklus kopiert werden, und mit wenigen Änderungen ist der kopierte Testplan für den neuen Zyklus bereit. Um diesen Prozess zu vereinfachen, haben wir auf der neuen Seite die Funktion "Testplan kopieren" aktiviert. Wenn Sie es nutzen, können Sie Testpläne kopieren oder klonen. Die backing REST API wird hier behandelt, und mit der API können Sie einen Testplan auch projektübergreifend kopieren/klonen.
Weitere Richtlinien zur verwendung Test Plans finden Sie hier.
2. Testsammlungsstruktur
Aufgaben
Mit dem Test suite-Header können Sie die folgenden Aufgaben ausführen:
- Erweitern/Reduzieren: Mit diesen Symbolleistenoptionen können Sie die Suitehierarchiestruktur erweitern oder reduzieren.
- Testpunkte aus untergeordneten Suites anzeigen: Diese Symbolleistenoption ist nur sichtbar, wenn Sie sich auf der Registerkarte "Ausführen" befinden. Dadurch können Sie alle Testpunkte für die angegebene Suite und ihre untergeordneten Elemente in einer Ansicht anzeigen, um die Verwaltung von Testpunkten zu vereinfachen, ohne einzeln zu einzelnen Suites navigieren zu müssen.
- Sortieren von Suites: Sie können Suites per Drag-/Drop verschieben, um 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 Testsammlungsstruktur bietet die folgenden Optionen:
- Erstellen neuer Suites: Sie können wie folgt 3 verschiedene Arten von Suites erstellen:
- Verwenden Sie statische Suite oder Ordnersammlung, um Ihre Tests zu organisieren.
- Verwenden Sie die anforderungsbasierte Suite, um direkt mit den Anforderungen/User Storys zu verknüpfen, um eine nahtlose Rückverfolgbarkeit zu gewährleisten.
- Verwenden Sie abfragebasiert, um Testfälle dynamisch zu organisieren, die einem Abfragekriterium entsprechen.
- Konfigurationen zuweisen: Sie können Konfigurationen für die Suite zuweisen (z. B. Chrome, Firefox, EdgeChromium), die dann für alle vorhandenen Testfälle oder neuen Testfälle gelten, die Sie später dieser Suite hinzufügen.
- Exportieren als PDF/E-Mail: Exportieren Sie die Testplaneigenschaften, Testsammlungseigenschaften sowie Details der Testfälle und Testpunkte entweder als "E-Mail" oder "In PDF drucken".
- Testsammlungs-Arbeitselement öffnen: Mit dieser Option können Sie das Formular test suite work item bearbeiten, um die Arbeitselementfelder zu verwalten.
- Zuweisen von Testern zum Ausführen aller Tests: Diese Option ist sehr nützlich für Benutzerakzeptanztests (User Acceptance Testing, UAT), in denen derselbe Test von mehreren Testern ausgeführt werden muss, die in der Regel zu verschiedenen Abteilungen gehören.
- Umbenennen/Löschen: Mit diesen Optionen können Sie den Suitenamen verwalten oder die Suite und deren Inhalt aus dem Testplan entfernen.
3. Registerkarte definieren
Mithilfe der Registerkarte "Definieren" können Sie Testfälle für eine Testsammlung sortieren, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient hingegen zum Zuweisen und Ausführen von Testpunkten.
Die Registerkarte Definieren und bestimmte Vorgänge sind nur für Benutzer mit der Zugriffsebene Basic + Test Plans oder einer entsprechenden Zugriffsebene verfügbar. Alles andere sollte von einem Benutzer mit der Zugriffsebene "Basic" ausgeführt werden können.
Aufgaben
Auf der Registerkarte Definieren können Sie die folgenden Aufgaben ausführen:
- Neuen Testfall mithilfe des Arbeitselementformulars hinzufügen: Mit dieser Option können Sie mithilfe des Arbeitselementformulars einen neuen Testfall erstellen. Der erstellte Testfall wird automatisch der Suite hinzugefügt.
- Neuen Testfall mit Raster hinzufügen: Mit dieser Option können Sie einen oder mehrere Testfälle mithilfe der Rasteransicht Testfälle erstellen. Die erstellten Testfälle werden automatisch der Suite hinzugefügt.
- Vorhandene Testfälle mithilfe einer Abfrage hinzufügen: Mit dieser Option können Sie der Suite vorhandene Testfälle hinzufügen, indem Sie eine Abfrage angeben.
- Sortieren von Testfällen per Drag/Drop: Sie können Testfälle neu anordnen, indem Sie einen oder mehrere Testfälle innerhalb einer bestimmten Suite ziehen/ablegen. Die Reihenfolge der Testfälle gilt nur für manuelle Testfälle und nicht für automatisierte Tests.
- Verschieben von Testfällen aus einer Suite in eine andere: Mithilfe von Drag/Drop können Sie Testfälle aus einer Testsammlung in eine andere verschieben.
- Raster anzeigen: Sie können den Rastermodus zum Anzeigen/Bearbeiten von Testfällen zusammen mit Testschritten verwenden.
- Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte Definieren im Vollbildmodus anzeigen.
- Filtern: Mithilfe der Filterleiste können Sie die Liste der Testfälle mithilfe der Felder "Testfalltitel", "zugewiesen an" und "status" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.
- Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte Definieren angezeigt werden, indem Sie "Spaltenoptionen" verwenden. Die Liste der spalten, die zur Auswahl verfügbar sind, sind in erster Linie die Felder aus dem Arbeitselementformular für den Testfall.
Kontextmenüoptionen
Das Kontextmenü auf dem Knoten Testfall auf der Registerkarte Definieren bietet die folgenden Optionen:
- Arbeitselementformular für Testfälle öffnen/bearbeiten: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitselementfelder einschließlich Der Testschritte bearbeiten.
- Bearbeiten von Testfällen: Mit dieser Option können Sie Die Arbeitselementfelder des Testfalls in Massenbearbeitung bearbeiten. Sie können diese Option jedoch nicht zum Massenbearbeitungsvorgang von Testschritten verwenden.
- Bearbeiten von Testfällen im Raster: Mit dieser Option können Sie die ausgewählten Testfälle, einschließlich Testschritten, mithilfe der Rasteransicht massenbearbeitungen.
- Konfigurationen zuweisen: Mit dieser Option können Sie die Konfigurationen auf Suiteebene mit Konfigurationen auf Testfallebene überschreiben.
- Entfernen von Testfällen: Mit dieser Option können Sie die Testfälle aus der angegebenen Suite entfernen. Das zugrunde liegende Testfallarbeitselement wird jedoch nicht geändert.
- Erstellen einer Kopie/Klon von Testfällen: Mit dieser Option können Sie eine Kopie/einen Klon ausgewählter Testfälle erstellen. Weitere Informationen finden Sie unten.
- Verknüpfte Elemente anzeigen: Mit dieser Option können Sie die verknüpften Elemente für einen bestimmten Testfall anzeigen. Weitere Informationen finden Sie unten.
Kopieren/Klonen von Testfällen (neue Funktion)
In Szenarien, in denen Sie einen Testfall kopieren/klonen möchten, können Sie die Option "Testfall kopieren" verwenden. Sie können das Zielprojekt, den Zieltestplan und die Zieltestsammlung angeben, in der der kopier-/geklonte Testfall erstellt werden soll. Darüber hinaus können Sie auch angeben, ob Sie vorhandene Links/Anlagen einschließen möchten, die in die geklonte Kopie fließen sollen.
Anzeigen verknüpfter Elemente (neue Funktion)
Die Rückverfolgbarkeit zwischen Testartefakten, Anforderungen und Fehlern ist ein wichtiges Wertversprechen des Test Plans Produkts. Mit der Option "Verknüpfte Elemente anzeigen" können Sie alle verknüpften Anforderungen, mit denen dieser Testfall verknüpft ist, alle Testsammlungen/Testpläne, in denen dieser Testfall verwendet wurde, und alle Fehler anzeigen, die im Rahmen der Testausführung gespeichert wurden.
4. Registerkarte "Ausführen"
Mithilfe der Registerkarte "Definieren" können Sie Testfälle für eine Testsammlung sortieren, hinzufügen und verwalten. Die Registerkarte "Ausführen" dient hingegen zum Zuweisen und Ausführen von Testpunkten.
Was ist ein Testpunkt? Testfälle selbst sind nicht ausführbar. Wenn Sie einer Testsammlung einen Testfall hinzufügen, werden Testpunkte generiert. Ein Testpunkt ist eine einzigartige Kombination aus Testfall, Testsammlung, Konfiguration und Tester. Beispiel: Wenn Sie einen Testfall als "Testanmeldungsfunktion" haben und zwei Konfigurationen als Edge und Chrome hinzufügen, ergibt dies 2 Testpunkte. Jetzt können diese Testpunkte ausgeführt werden. Bei der Ausführung werden Testergebnisse generiert. In der Testergebnisansicht (Ausführungsverlauf) können Sie alle Ausführungen eines Testpunkts anzeigen. Die neueste Ausführung für den Testpunkt wird auf der Registerkarte "Ausführen" angezeigt.
Daher sind Testfälle wiederverwendbare Entitäten. Indem Sie sie in einen Testplan oder eine Testsammlung einschließen, werden Testpunkte generiert. Durch die Ausführung von Testpunkten bestimmen Sie die Qualität des zu entwickelnden Produkts oder Dienstes.
Einer der Hauptvorteile der neuen Seite ist für Benutzer, die hauptsächlich Testausführung/Nachverfolgung durchführen (benötigen nur "Basic"-Zugriffsebene), sie sind nicht von der Komplexität der Suite-Verwaltung überfordert (die Registerkarte definieren ist für solche Benutzer ausgeblendet).
Die Registerkarte Definieren und bestimmte Vorgänge sind nur für Benutzer mit der Zugriffsebene Basic + Test Plans oder einer entsprechenden Zugriffsebene verfügbar. Alles andere, einschließlich der Registerkarte "Ausführen", sollte von einem Benutzer mit der Zugriffsebene "Basic" ausgeführt werden können.
Aufgaben
Auf der Registerkarte Ausführen können Sie die folgenden Aufgaben ausführen:
- Massenmarkierung von Testpunkten: Mit dieser Option können Sie das Ergebnis der Testpunkte – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend – schnell markieren, ohne den Testfall über den Testrunner ausführen zu müssen. Das Ergebnis kann für einen oder mehrere Testpunkte auf einmal markiert werden.
- Testpunkte ausführen: Mit dieser Option können Sie die Testfälle ausführen, indem Sie jeden Testschritt einzeln durchlaufen und sie mit einem Testrunner als "bestanden/fehlgeschlagen" markieren. Abhängig von der Anwendung, die Sie testen, können Sie den "Web Runner" zum Testen einer "Webanwendung" oder den "Desktop-Runner" zum Testen von Desktop- und/oder Webanwendungen verwenden. Sie können auch die Option "Ausführen mit Optionen" aufrufen, um einen Build anzugeben, für den die Tests ausgeführt werden sollen.
- Spaltenoptionen: Sie können die Liste der Spalten verwalten, die auf der Registerkarte Ausführen angezeigt werden, indem Sie "Spaltenoptionen" verwenden. Die Liste der spalten, die zur Auswahl verfügbar sind, sind Testpunkten zugeordnet, z. B. Ausführen von, Zugewiesener Tester, Konfiguration usw.
- Vollbildansicht: Mit dieser Option können Sie den Inhalt der gesamten Registerkarte "Ausführen" im Vollbildmodus anzeigen.
- Filtern: Mithilfe der Filterleiste können Sie die Liste der Testpunkte mithilfe der Felder "Testfalltitel", "zugewiesen", "Status", "Testergebnis", "Tester" und "Konfiguration" filtern. Sie können die Liste auch sortieren, indem Sie auf die Spaltenüberschriften klicken.
Kontextmenüoptionen
Das Kontextmenü auf dem Knoten Testpunkt auf der Registerkarte Ausführen bietet die folgenden Optionen:
- Testergebnis markieren: Wie oben können Sie das Ergebnis der Testpunkte – bestanden, fehlgeschlagen, blockiert oder nicht zutreffend – schnell markieren.
- Testpunkte ausführen: Wie oben können Sie die Testfälle über einen Testrunner ausführen.
- Test auf aktiv zurücksetzen: Mit dieser Option können Sie das Testergebnis auf aktiv zurücksetzen, wodurch das letzte Ergebnis des Testpunkts ignoriert wird.
- Arbeitselementformular für Testfälle öffnen/bearbeiten: Mit dieser Option können Sie einen Testfall mithilfe des Arbeitselementformulars bearbeiten, in dem Sie die Arbeitselementfelder einschließlich Der Testschritte bearbeiten.
- Tester zuweisen: Mit dieser Option können Sie die Testpunkte Testern für die Testausführung zuweisen.
- Anzeigen des Testergebnisses: Mit dieser Option können Sie die neuesten Testergebnisse anzeigen, einschließlich des Ergebnisses jedes Testschritts, hinzugefügter Kommentare oder gespeicherter Fehler.
- Ausführungsverlauf anzeigen: Mit dieser Option können Sie den gesamten Ausführungsverlauf für den ausgewählten Testpunkt anzeigen. Dadurch wird eine neue Seite geöffnet, auf der Sie die Filter anpassen können, um den Ausführungsverlauf nicht nur des ausgewählten Testpunkts, sondern auch für den gesamten Testfall anzuzeigen.
Test Plans Statusbericht
Mit diesem sofort einsatzbereiten Bericht können Sie die Ausführung und status eines oder mehrerer Test Plans in einem Projekt nachverfolgen. Besuchen Sie Test Plans > Statusbericht*, um mit der Verwendung des Berichts zu beginnen.
Die drei Abschnitte des Berichts umfassen Folgendes:
- Zusammenfassung: Zeigt eine konsolidierte Ansicht für die ausgewählten Testpläne an.
- Ergebnistrend: Rendert eine tägliche Momentaufnahme, um Ihnen eine Ausführungs- und status Trendlinie zu bieten. Es kann Daten für 14 Tage (Standard), 30 Tage oder einen benutzerdefinierten Bereich anzeigen.
- Details: In diesem Abschnitt können Sie einen Drilldown nach jedem Testplan durchführen und wichtige Analysen für jede Testsammlung bereitstellen.
Artifacts
Hinweis
Azure DevOps Server 2020 importiert keine Feeds, die sich während des Datenimports im Papierkorb befinden. Wenn Sie Feeds importieren möchten, die sich im Papierkorb befinden, stellen Sie sie aus dem Papierkorb wieder her, bevor Sie mit dem Datenimport beginnen.
Lizenzausdrücke und eingebettete Lizenzen
Jetzt können Sie beim Durchsuchen von Paketen in Visual Studio die Details der Lizenzinformationen für NuGet-Pakete anzeigen, die in Azure Artifacts gespeichert sind. Dies gilt für Lizenzen, die mithilfe von Lizenzausdrücken oder eingebetteten Lizenzen dargestellt werden. Nun sehen Sie einen Link zu den Lizenzinformationen auf der Seite mit den Visual Studio-Paketdetails (roter Pfeil in der abbildung unten).
Wenn Sie auf den Link klicken, gelangen Sie zu einer Webseite, auf der Sie die Details der Lizenz anzeigen können. Diese Benutzeroberfläche ist sowohl für Lizenzausdrücke als auch für eingebettete Lizenzen identisch, sodass Sie Lizenzdetails für in Azure Artifacts gespeicherte Pakete an einem Ort anzeigen können (für Pakete, die Lizenzinformationen angeben und von Visual Studio unterstützt werden).
Einfache Authentifizierungsaufgaben
Sie können sich jetzt mithilfe von einfachen Authentifizierungsaufgaben bei beliebten Paket-Managern aus Azure Pipelines authentifizieren. Dazu gehören NuGet, npm, PIP, Twine und Maven. Zuvor konnten Sie sich bei diesen Paket-Managern mithilfe von Aufgaben authentifizieren, die eine große Menge an Funktionen bereitstellten, einschließlich der Möglichkeit, Pakete zu veröffentlichen und herunterzuladen. Dies erforderte jedoch die Verwendung dieser Aufgaben für alle Aktivitäten, die mit den Paket-Managern interagierten. Wenn Sie ihre eigenen Skripts zum Ausführen von Aufgaben wie dem Veröffentlichen oder Herunterladen von Paketen ausführen würden, könnten Sie sie nicht in Ihrer Pipeline verwenden. Jetzt können Sie Skripts Ihres eigenen Entwurfs in Ihrer Pipeline-YAML verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben durchführen. Beispiel für die Verwendung von npm:
Die Verwendung der Befehle "ci" und "publish" in dieser Abbildung ist beliebig. Sie können alle befehle verwenden, die von Azure Pipelines YAML unterstützt werden. Dies ermöglicht Ihnen die vollständige Kontrolle über den Befehlsaufruf und erleichtert die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration. Weitere Informationen finden Sie in der Dokumentation zu NuGet-, npm-, PIP-, Twine- und Maven-Authentifizierungstasks.
Verbesserungen an der Ladezeit von Feedseiten
Wir freuen uns, ihnen mitteilen zu können, dass wir die Ladezeit der Feedseite verbessert haben. Im Durchschnitt sind die Ladezeiten von Feedseiten um 10 % zurückgegangen. Bei den größten Feeds hat sich die Ladezeit der 99. Perzentile der Feedseite (Ladezeiten in den höchsten 99 % aller Feeds) um 75 % verringert.
Öffentliches Freigeben Ihrer Pakete mit öffentlichen Feeds
Sie können Ihre Pakete jetzt in öffentlichen Feeds erstellen und speichern. Pakete, die in öffentlichen Feeds gespeichert sind, stehen allen Benutzern im Internet ohne Authentifizierung zur Verfügung, unabhängig davon, ob sie sich in Ihrer Sammlung befinden oder sogar in einer Azure DevOps-Sammlung angemeldet sind. Erfahren Sie mehr über öffentliche Feeds in unserer Feeds-Dokumentation , oder springen Sie direkt in unser Tutorial zum öffentlichen Freigeben von Paketen.
Konfigurieren von Upstreams in verschiedenen Sammlungen innerhalb eines AAD-Mandanten
Sie können jetzt einen Feed in einer anderen Sammlung hinzufügen, die Ihrem Azure Active Directory-Mandanten (AAD) zugeordnet ist, als Upstream Quelle zu Ihrem Artifacts-Feed. Ihr Feed kann Pakete aus den Feeds finden und verwenden, die als Upstream Quellen konfiguriert sind, sodass Pakete problemlos über Sammlungen hinweg freigegeben werden können, die Ihrem AAD-Mandanten zugeordnet sind. Informationen zum Einrichten finden Sie in der Dokumentation.
Verwenden des Python-Anmeldeinformationsanbieters zum Authentifizieren von pip und Twine mit Azure Artifacts-Feeds
Sie können jetzt den Python-Anmeldeinformationsanbieter (artifacts-keyring) installieren und verwenden, um die Authentifizierung automatisch einzurichten, um Python-Pakete in oder aus einem Azure Artifacts-Feed zu veröffentlichen oder zu nutzen. Mit dem Anmeldeinformationsanbieter müssen Sie keine Konfigurationsdateien einrichten (pip.ini/pip.conf/.pypirc). Sie werden einfach durch einen Authentifizierungsfluss in Ihrem Webbrowser weitergeleitet, wenn Sie pip oder Twine zum ersten Mal aufrufen. Weitere Informationen finden Sie in der Dokumentation.
Azure Artifacts-Feeds im Visual Studio-Paket-Manager
Wir zeigen jetzt Paketsymbole, Beschreibungen und Autoren im Visual Studio NuGet-Paket-Manager für Pakete an, die über Azure Artifacts-Feeds bereitgestellt werden. Bisher wurden die meisten dieser Metadaten nicht für VS bereitgestellt.
Aktualisierte Benutzeroberfläche "Connect to feed" (Verbindung mit Feed herstellen)
Das Dialogfeld Mit Feed verbinden ist der Einstieg in die Verwendung von Azure Artifacts. Es enthält Informationen zum Konfigurieren von Clients und Repositorys zum Pushen und Pullen von Paketen aus Feeds in Azure DevOps. Wir haben das Dialogfeld aktualisiert, um detaillierte Informationen zur Einrichtung hinzuzufügen, und die Tools, für die wir Anweisungen geben, erweitert.
Öffentliche Feeds sind jetzt allgemein verfügbar mit Upstream Unterstützung
Die öffentliche Vorschau der öffentlichen Feeds hat große Akzeptanz und Feedback erhalten. In dieser Version haben wir zusätzliche Features auf die allgemeine Verfügbarkeit erweitert. Jetzt können Sie einen öffentlichen Feed als Upstream Quelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl zu und aus privaten als auch projektbezogenen Feeds Upstream können.
Erstellen von projektbezogenen Feeds über das Portal
Als wir öffentliche Feeds veröffentlicht haben, haben wir auch projektbezogene Feeds veröffentlicht. Bisher konnten projektbezogene Feeds über REST-APIs oder durch Erstellen eines öffentlichen Feeds erstellt und das Projekt dann privat werden. Jetzt können Sie projektbezogene Feeds direkt im Portal aus jedem Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch in der Feedauswahl sehen, welche Feeds projekt- und welche sammlungsweit sind.
npm-Leistungsverbesserungen
Wir haben Änderungen an unserem Kernentwurf vorgenommen, um die Art und Weise zu verbessern, wie npm-Pakete in Azure Artifacts-Feeds gespeichert und bereitgestellt werden. Dies hat uns geholfen, die Latenz für einige der am höchsten verwendeten APIs für npm bis zu 10-fach zu reduzieren.
Verbesserungen in Bezug auf die Barrierefreiheit
Wir haben Korrekturen bereitgestellt, um Probleme mit der Barrierefreiheit auf unserer Feedseite zu beheben. Die Fehlerbehebungen umfassen Folgendes:
- Erstellen einer Feedoberfläche
- Globale Feedeinstellungen
- Herstellen einer Verbindung mit der Feedoberfläche
Wiki
Umfangreiche Bearbeitung für Code-Wiki-Seiten
Zuvor wurden Sie beim Bearbeiten einer Code-Wiki-Seite zum Azure Repos Hub zur Bearbeitung weitergeleitet. Derzeit ist der Repositoryhub nicht für die Markdownbearbeitung optimiert.
Jetzt können Sie eine Code-Wiki-Seite im parallelen Editor innerhalb von Wiki bearbeiten. Auf diese Weise können Sie die umfangreiche Markdownsymbolleiste verwenden, um Ihre Inhalte zu erstellen, sodass die Bearbeitungserfahrung mit der im Projektwiki identisch ist. Sie können weiterhin die Bearbeitung in Repositorys auswählen, indem Sie im Kontextmenü die Option In Repos bearbeiten auswählen.
Erstellen und Einbetten von Arbeitselementen aus einer Wiki-Seite
Als wir Ihr Feedback gehört haben, haben wir gehört, dass Sie Wiki verwenden, um Brainstorming-Dokumente, Planungsdokumente, Ideen zu Features, Spezifikationsdokumenten und Besprechungsprotokollen zu erfassen. Jetzt können Sie Funktionen und User Storys ganz einfach direkt aus einem Planungsdokument erstellen, ohne die Wiki-Seite zu verlassen.
Um ein Arbeitselement zu erstellen, wählen Sie den Text auf der Wiki-Seite aus, auf der Sie das Arbeitselement einbetten möchten, und wählen Sie Neues Arbeitselement aus. Dies spart Ihnen Zeit, da Sie das Arbeitselement nicht zuerst erstellen, zu Bearbeiten wechseln und dann nach dem Arbeitselement suchen müssen, um es einzubetten. Außerdem wird der Kontextwechsel reduziert, wenn Sie den Wiki-Bereich nicht mehr öffnen.
Weitere Informationen zum Erstellen und Einbetten eines Arbeitselements aus dem Wiki finden Sie in unserer Dokumentation hier.
Kommentare auf Wiki-Seiten
Zuvor hatten Sie keine Möglichkeit, mit anderen Wiki-Benutzern innerhalb des Wikis zu interagieren. Dies machte die Zusammenarbeit an Inhalten und das Beantworten von Fragen zu einer Herausforderung, da Unterhaltungen über E-Mail- oder Chatkanäle erfolgen mussten. Mit Kommentaren können Sie jetzt direkt im Wiki mit anderen zusammenarbeiten. Sie können die @mention Benutzerfunktionen in 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.
Blenden Sie Ordner und Dateien aus, die mit "" beginnen. in der Wiki-Struktur
Bis jetzt wurden in der Wiki-Struktur alle Ordner und Dateien angezeigt, die mit einem Punkt (.) in der Wiki-Struktur beginnen. In Code-Wiki-Szenarien führte dies dazu, dass Ordner wie .vscode, die ausgeblendet werden sollen, in der Wiki-Struktur angezeigt wurden. Jetzt bleiben alle Dateien und Ordner, die mit einem Punkt beginnen, in der Wiki-Struktur ausgeblendet, wodurch unnötige Unordnung reduziert wird.
Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert.
Kurze und lesbare Wiki-Seiten-URLs
Sie müssen keine mehrzilige URL mehr verwenden, um Wiki-Seitenlinks zu teilen. Wir nutzen die Seiten-IDs in der URL, um Parameter zu entfernen, wodurch die URL kürzer und einfacher zu lesen ist.
Die neue Struktur der URLs sieht wie folgt aus:
https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}
Dies ist ein Beispiel für die neue URL für eine Willkommensseite im Azure DevOps-Wiki :
https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki
Dies wurde basierend auf diesem Featurevorschlagsticket aus dem Entwicklercommunity priorisiert.
Synchroner Bildlauf zum Bearbeiten von Wiki-Seiten
Das Bearbeiten von Wiki-Seiten ist jetzt einfacher mit synchronem Scrollen zwischen dem Bearbeitungs- und dem Vorschaubereich. Wenn Sie auf einer Seite scrollen, scrollt automatisch auf der anderen Seite, um die entsprechenden Abschnitte zuzuordnen. Sie können den synchronen Bildlauf mit der Umschaltfläche deaktivieren.
Hinweis
Der Status der synchronen Scroll-Umschaltfläche wird pro Benutzer und Konto gespeichert.
Seitenbesuche für Wiki-Seiten
Sie können jetzt Einblicke in die Seitenbesuche für Wiki-Seiten erhalten. Mit der REST-API können Sie auf die Seitenbesuchsinformationen der letzten 30 Tage zugreifen. Sie können diese Daten verwenden, um Berichte für Ihre Wiki-Seiten zu erstellen. Darüber hinaus können Sie diese Daten in Ihrer Datenquelle speichern und Dashboards erstellen, um bestimmte Erkenntnisse wie die am häufigsten angezeigten Seiten zu erhalten.
Außerdem wird eine aggregierte Anzahl 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-Minuten-Intervall definiert.
Berichterstellung
Berichte zu Pipelinefehlern und -dauer
Metriken und Erkenntnisse helfen Ihnen, den Durchsatz und die Stabilität Ihrer Pipelines kontinuierlich zu verbessern. Wir haben zwei neue Berichte hinzugefügt, um Ihnen Einblicke in Ihre Pipelines zu bieten.
- Der Pipelinefehlerbericht zeigt die Builddurchlaufrate und den Fehlertrend an. Darüber hinaus wird auch der Fehlertrend für Aufgaben angezeigt, um Erkenntnisse darüber zu liefern, welche Aufgabe in der Pipeline zur maximalen Anzahl von Fehlern beiträgt.
- Der Bericht zur Pipelinedauer zeigt den Trend der Zeit, die für die Ausführung einer Pipeline dauert. Außerdem wird angezeigt, welche Aufgaben in der Pipeline am meisten Zeit in Anspruch nehmen.
Verbesserung des Widgets "Abfrageergebnisse"
Das Widget für Abfrageergebnisse ist aus gutem Grund eines unserer beliebtesten Widgets. Das Widget zeigt die Ergebnisse einer Abfrage direkt auf Ihrem Dashboard an und ist in vielen Situationen nützlich.
Mit diesem Update haben wir viele lang erwartete Verbesserungen eingefügt:
- Sie können jetzt so viele Spalten auswählen, wie Sie im Widget anzeigen möchten. Kein 5-Spalten-Limit mehr!
- Das Widget unterstützt alle Größen von 1x1 bis 10x10.
- Wenn Sie die Größe einer Spalte ändern, wird die Spaltenbreite gespeichert.
- Sie können das Widget in die Vollbildansicht erweitern. Wenn sie erweitert ist, werden alle spalten angezeigt, die von der Abfrage zurückgegeben werden.
Erweiterte Filterung von Lead- und Zykluszeitwidgets
Die Lead- und Zykluszeit wird von Teams genutzt, um zu sehen, wie lange es dauert, bis die Arbeit ihre Entwicklungspipelines durchlaufen und letztendlich einen Mehrwert für ihre Kunden bietet.
Bisher haben die Lead- und Zykluszeitwidgets keine erweiterten Filterkriterien unterstützt, um Fragen wie z. B. "Wie lange dauert es, bis mein Team die Elemente mit höherer Priorität schließt?"
Mit diesem Update können Fragen wie diese beantwortet werden, indem Sie in der Board-Schwimmlane filtern.
Wir haben auch Arbeitselementfilter eingefügt, um die Arbeitselemente einzuschränken, die im Diagramm angezeigt werden.
Inline-Sprint-Burndown mithilfe von Storypunkten
Ihr Sprint-Burndown kann jetzt nach Stories burndownen. Dies berücksichtigt Ihr Feedback vom Entwicklercommunity.
Wählen Sie im Sprint-Hub die Registerkarte Analyse aus. Konfigurieren Sie dann den Bericht wie folgt:
- Auswählen des Backlogs "Stories"
- Auswählen des Burndowns für Die Summe der Story-Punkte
Ein Sprint Burndown-Widget mit allem, was Sie gefragt haben
Das neue Sprint Burndown-Widget unterstützt das Herunterbrennen nach Story points, anzahl der Aufgaben oder durch Summieren benutzerdefinierter Felder. Sie können sogar einen Sprint-Burndown für Features oder Epics erstellen. Das Widget zeigt den durchschnittlichen Burndown, den Prozentsatz abgeschlossen und die Bereichsvergrößerung an. Sie können das Team konfigurieren, sodass Sie Sprint-Burndowns für mehrere Teams auf demselben Dashboard anzeigen können. Mit all diesen großartigen Informationen können Sie die Größe auf der Dashboard auf bis zu 10x10 ändern.
Um es auszuprobieren, können Sie es aus dem Widgetkatalog hinzufügen, oder indem Sie die Konfiguration für das vorhandene Sprint Burndown-Widget bearbeiten und das Kontrollkästchen Neue Version jetzt testen aktivieren.
Hinweis
Das neue Widget verwendet Analytics. Wir haben den Legacy-Sprint-Burndown beibehalten, falls Sie keinen Zugriff auf Analytics haben.
Miniaturansicht des Inline-Sprint-Burndowns
Der Sprint Burndown ist zurück! Vor einigen Sprints haben wir den Kontext-Sprint-Burndown aus den Sprint Burndown- und Taskboard-Headern entfernt. Basierend auf Ihrem Feedback haben wir die Miniaturansicht des Sprint-Burndowns verbessert und wieder eingeführt.
Wenn Sie auf die Miniaturansicht klicken, wird sofort eine größere Version des Diagramms mit der Option angezeigt, den vollständigen Bericht auf der Registerkarte Analyse anzuzeigen. Alle Änderungen, die am vollständigen Bericht vorgenommen werden, werden im Im Header angezeigten Diagramm widergespiegelt. So können Sie es jetzt basierend auf Geschichten, Storypunkten oder der Anzahl der Aufgaben als Burndown konfigurieren, anstatt nur die verbleibende Menge an Arbeit.
Erstellen eines Dashboard ohne Team
Sie können jetzt eine Dashboard erstellen, ohne sie einem Team zuzuordnen. Wählen Sie beim Erstellen eines Dashboard den Projektdashboardtyp aus.
Ein Projektdashboard ähnelt einem Teamdashboard, es ist jedoch nicht einem Team zugeordnet, und Sie können entscheiden, wer das Dashboard bearbeiten/verwalten kann. Genau wie ein Teamdashboard ist es für jeden im Projekt sichtbar.
Alle Azure DevOps-Widgets, die einen Teamkontext erfordern, wurden aktualisiert, damit Sie ein Team in ihrer Konfiguration auswählen können. Sie können diese Widgets zu Project Dashboards hinzufügen und das gewünschte Team auswählen.
Hinweis
Für benutzerdefinierte Widgets oder Drittanbieterwidgets übergibt ein Projektdashboard den Standardkontext des Teams an diese Widgets. Wenn Sie über ein benutzerdefiniertes Widget verfügen, das vom Teamkontext abhängig ist, sollten Sie die Konfiguration aktualisieren, damit Sie ein Team auswählen können.
Feedback
Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen, es über Entwicklercommunity nachverfolgen und Sich zu Stack Overflow beraten lassen.