Versionshinweise zu Azure DevOps Server 2022 Update 1

---

| | Entwicklercommunity Systemanforderungen und Kompatibilität Lizenzbedingungen | | DevOps Blog | SHA-256 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 Server Produkte herunterzuladen, besuchen Sie die Seite Azure DevOps Server Downloads.

Das direkte Upgrade auf Azure DevOps Server 2022 Update 1 wird ab Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2013 oder früher befindet, müssen Sie vor dem Upgrade auf Azure DevOps Server 2022 einige Zwischenschritte ausführen. Weitere Informationen finden Sie auf der Seite Installieren .

---

Azure DevOps Server 2022 Update 1 Patch 3 Veröffentlichungsdatum: 12. März 2024

Datei	SHA-256 Hash
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Wir haben Patch 3 für Azure DevOps Server 2022 Update 1 veröffentlicht, das Fehlerbehebungen für folgendes enthält.

• Es wurde ein Problem behoben, bei dem der Proxyserver nach der Installation von Patch 2 nicht mehr funktionierte.
• Es wurde ein Renderingproblem auf der Seite mit den Erweiterungsdetails behoben, das sich auf Sprachen auswirkt, die nicht englisch waren.

Azure DevOps Server 2022 Update 1 Patch 2 Veröffentlichungsdatum: 13. Februar 2024

Datei	SHA-256 Hash
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Wir haben Patch 2 für Azure DevOps Server 2022 Update 1 veröffentlicht, das Fehlerbehebungen für folgendes enthält.

• Problem mit dem Rendern von Detailseiten in der Sucherweiterung behoben.
• Ein Fehler wurde behoben, bei dem der vom Proxycacheordner belegte Speicherplatz falsch berechnet und der Ordner nicht ordnungsgemäß bereinigt wurde.
• CVE-2024-20667: Azure DevOps Server Sicherheitsanfälligkeit bezüglich Remotecodeausführung.

Azure DevOps Server 2022 Update 1 Patch 1 Veröffentlichungsdatum: 12. Dezember 2023

Datei	SHA-256 Hash
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Wir haben Patch 1 für Azure DevOps Server 2022 Update 1 veröffentlicht, das Fehlerbehebungen für folgendes enthält.

• Verhindern sie die Einstellung requested for beim Anstehen einer Pipelineausführung.

Azure DevOps Server 2022 Update 1 Veröffentlichungsdatum: 28. November 2023

Hinweis

Es gibt zwei bekannte Probleme mit dieser Version:

1. Die Agent-Version wird nach dem Upgrade auf Azure DevOps Server 2022.1 und der Verwendung des Update-Agents in der Agentpoolkonfiguration nicht aktualisiert. Wir arbeiten derzeit an einem Patch, um dieses Problem zu beheben, und werden Updates im Entwicklercommunity freigeben, wenn wir fortschritte machen. In der Zwischenzeit finden Sie eine Problemumgehung für dieses Problem in diesem Entwicklercommunity Ticket.
2. Maven 3.9.x-Kompatibilität. Maven 3.9.x führte Breaking Changes mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport von Wagon auf natives HTTP aktualisiert wurde. Dies verursacht 401-Authentifizierungsprobleme für Kunden, die HTTP anstelle von HTTPS verwenden. Weitere Informationen zu diesem Problem finden Sie hier. Als Problemumgehung können Sie Maven 3.9.x mit der -Eigenschaft -Dmaven.resolver.transport=wagonweiterhin verwenden. Diese Änderung zwingt Maven zur Verwendung von Wagon Resolver Transport. Weitere Informationen finden Sie hier in der Dokumentation.

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

Hinweis

Es gibt ein bekanntes Problem mit der Kompatibilität mit Maven 3.9.x. Maven 3.9.x führte Breaking Changes mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport von Wagon auf natives HTTP aktualisiert wurde. Dies verursacht 401-Authentifizierungsprobleme für Kunden, die HTTP anstelle von HTTPS verwenden. Weitere Informationen zu diesem Problem finden Sie hier.

Als Problemumgehung können Sie Maven 3.9.x mit der -Eigenschaft -Dmaven.resolver.transport=wagonweiterhin verwenden. Diese Änderung zwingt Maven zur Verwendung von Wagon Resolver Transport. Weitere Informationen finden Sie hier in der Dokumentation.

Azure DevOps Server Veröffentlichungsdatum von Update 1 RC2 2022: 31. Oktober 2023

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

Hinweis

Es gibt ein bekanntes Problem mit der Kompatibilität mit Maven 3.9.x. Maven 3.9.x führte Breaking Changes mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport von Wagon auf natives HTTP aktualisiert wurde. Dies verursacht 401-Authentifizierungsprobleme für Kunden, die HTTP anstelle von HTTPS verwenden. Weitere Informationen zu diesem Problem finden Sie hier.

Als Problemumgehung können Sie Maven 3.9.x mit der -Eigenschaft -Dmaven.resolver.transport=wagonweiterhin verwenden. Diese Änderung zwingt Maven zur Verwendung von Wagon Resolver Transport. Weitere Informationen finden Sie hier in der Dokumentation.

Folgendes wurde mit dieser Version behoben:

• Es wurde ein Problem in lokalen Feeds behoben, bei dem die Upstream Einträge anzeigenamensänderungen nicht auflösten.
• Unerwarteter Fehler beim Wechseln von Registerkarten von Code zu einer anderen Registerkarte auf der Seite Suchen.
• Fehler beim Erstellen eines neuen Arbeitselementtyps mit chinesischen, japanischen und koreanischen Einheitlichen Ideographen (CJK). Ein Fragezeichen wurde bei raw log on gated check-in angezeigt, wenn der Name des Teamprojekts oder die Dateien CJK enthalten.
• Es wurde ein Problem während der Installation von Search behoben, bei dem der virtuelle Java-Computer (JVM) nicht genügend Arbeitsspeicher für den Prozess der elastischen Suche zuweisen konnte. Das Suchkonfigurationswidget verwendet jetzt das Java Development Kit (JDK), das mit der elastischen Suche gebündelt ist, und entfernt daher die Abhängigkeit von allen auf dem Zielserver vorinstallierten Java Runtime Environment (JRE).

Azure DevOps Server 2022 Update 1 RC1 Veröffentlichungsdatum: 19. September 2023

Azure DevOps Server 2022.1 RC1 enthält viele neue Features. Einige der Highlights sind unter anderem:

• Alle öffentlichen REST-APIs unterstützen präzise PAT-Bereiche.
• Spalte "Zuletzt aufgerufen" auf der Seite "Übermittlungspläne"
• Visualisieren aller Abhängigkeiten von Übermittlungsplänen
• @CurrentIteration-Makro in Übermittlungsplänen
• Aktuelles Projekt, das als Standardbereich für Buildzugriffstoken in klassischen Pipelines festgelegt ist
• Übergeordnetes Element im Widget "Abfrageergebnisse anzeigen"
• Dashboard kopieren
• Unterstützung für zusätzliche Diagrammtypen auf Wiki-Seiten
• Container Registry-Dienstverbindungen können jetzt verwaltete Azure-Identitäten verwenden.

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

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

---

Allgemein

Alle öffentlichen REST-APIs unterstützen präzise PAT-Bereiche.

Bisher waren eine Reihe öffentlich dokumentierter Azure DevOps-REST-APIs nicht Bereichen zugeordnet (z. B. Arbeitselementlesevorgänge), was dazu führte, dass Kunden vollständige Bereiche nutzten, um diese APIs über nicht interaktive Authentifizierungsmechanismen wie persönliche Zugriffstoken (PAT) zu nutzen. Die Verwendung eines persönlichen Zugriffstokens mit vollem Umfang erhöht das Risiko, wenn sie in die Hände eines böswilligen Benutzers gelangen können. Dies ist einer der Standard Gründe, warum viele unserer Kunden die Richtlinien der Steuerungsebene nicht in vollem Umfang genutzt haben, um die Nutzung und das Verhalten des PAT einzuschränken.

Jetzt sind alle öffentlichen Azure DevOps-REST-APIs mit einem präzisen PAT-Bereich verknüpft und unterstützen sie. Wenn Sie derzeit einen vollständigen PAT verwenden, um sich bei einer der öffentlichen Azure DevOps-REST-APIs zu authentifizieren, sollten Sie eine Migration zu einem PAT mit dem von der API akzeptierten spezifischen Bereich in Erwägung ziehen, um unnötigen Zugriff zu vermeiden. Die unterstützten granularen PAT-Bereiche für eine bestimmte REST-API finden Sie im Abschnitt Sicherheit der Dokumentationsseiten. Darüber hinaus finden Sie hier eine Tabelle mit Bereichen.

Erweiterungen sollten ihre Bereiche anzeigen

Wenn Sie Erweiterungen in Ihrer Azure DevOps-Sammlung installieren, können Sie die Berechtigungen überprüfen, die die Erweiterung im Rahmen der Installation benötigt. Nach der Installation sind die Erweiterungsberechtigungen in den Erweiterungseinstellungen jedoch nicht sichtbar. Für Administratoren, die eine regelmäßige Überprüfung der installierten Erweiterungen durchführen müssen, stellt dies eine Herausforderung dar. Nun haben wir die Erweiterungsberechtigungen zu Erweiterungseinstellungen hinzugefügt, damit Sie diese überprüfen und eine fundierte Entscheidung treffen können, ob sie beibehalten werden sollen oder nicht.

Boards

Spalte "Zuletzt aufgerufen" auf der Seite "Übermittlungspläne"

Die Verzeichnisseite Übermittlungspläne enthält eine Liste der für Ihr Projekt definierten Pläne. Sie können nach Folgendem sortieren: Name, Erstellt von, Beschreibung, Zuletzt konfiguriert oder Favoriten. Mit diesem Update haben wir der Verzeichnisseite eine Spalte Zuletzt aufgerufen hinzugefügt. Dadurch erhalten Sie Einen Überblick darüber, wann ein Übermittlungsplan zuletzt geöffnet und untersucht wurde. Daher ist es einfach, die Pläne zu identifizieren, die nicht mehr verwendet werden und gelöscht werden können.

Visualisieren aller Abhängigkeiten von Übermittlungsplänen

Übermittlungspläne haben immer die Möglichkeit geboten, die Abhängigkeiten über Arbeitselemente hinweg anzuzeigen. Sie können die Abhängigkeitslinien einzeln visualisieren. Mit dieser Version haben wir die Benutzeroberfläche verbessert, indem Sie alle Abhängigkeiten zeilenübergreifend über alle Arbeitselemente auf dem Bildschirm anzeigen können. Klicken Sie einfach oben rechts in Ihrem Lieferplan auf die Schaltfläche "Abhängigkeiten". Klicken Sie erneut darauf, um die Zeilen zu deaktivieren.

Grenzwerte für die Überarbeitung neuer Arbeitselemente

In den letzten Jahren haben wir gesehen, dass Projektsammlungen mit automatisierten Tools Zehntausende von Überarbeitungen von Arbeitselementen generiert haben. Dadurch entstehen Leistungs- und Benutzerfreundlichkeitsprobleme für das Arbeitselementformular und die BERICHTS-REST-APIs. Um das Problem zu beheben, haben wir einen Grenzwert für die Überarbeitung von Arbeitselementen von 10.000 für den Azure DevOps-Dienst implementiert. Der Grenzwert wirkt sich nur auf Updates aus, die die REST-API verwenden, nicht das Arbeitselementformular.

Klicken Sie hier , um mehr über das Revisionslimit zu erfahren und wie Sie ihn in Ihren automatisierten Tools behandeln können.

Erhöhen des Teamlimits für Übermittlungspläne von 15 auf 20

Mit Übermittlungsplänen können Sie mehrere Backlogs und mehrere Teams in Ihrer Projektsammlung anzeigen. Zuvor konnten Sie 15 Teambacklogs anzeigen, einschließlich einer Mischung aus Backlogs und Teams aus verschiedenen Projekten. Mit diesem Release haben wir den Höchstwert von 15 auf 20 erhöht.

Fehler beim Melden von Arbeitselementverknüpfungs-API behoben

Es wurde ein Fehler in der Berichtsarbeitselementlinks-Get-API behoben, um den richtigen remoteUrl-Wert für System.LinkTypes.Remote.Related Linktypen zurückzugeben. Vor diesem Fix haben wir den falschen Projektsammlungsnamen und eine fehlende Projekt-ID zurückgegeben.

Erstellen eines temporären Abfrage-REST-Endpunkts

Wir haben mehrere Instanzen von Erweiterungsautoren gesehen, die versuchen, nicht gespeicherte Abfragen auszuführen, indem sie die WIQL-Anweisung (Work Item Query Language) über die Abfragezeichenfolge übergeben. Dies funktioniert gut, es sei denn, Sie verfügen über eine große WIQL-Anweisung, die die Browsergrenzwerte für die Abfragezeichenfolgenlänge erreicht. Um dies zu beheben, haben wir einen neuen REST-Endpunkt erstellt, mit dem Toolautoren eine temporäre Abfrage generieren können. Wenn Sie die ID aus der Antwort verwenden, um die Abfragezeichenfolge zu übergeben, wird dieses Problem beseitigt.

Weitere Informationen finden Sie auf der Dokumentationsseite zur REST-API für temporäre Abfragen.

Batchlösch-API

Derzeit besteht die einzige Möglichkeit zum Entfernen von Arbeitselementen aus dem Papierkorb darin, diese REST-API zu verwenden, um nacheinander zu löschen. Dies kann ein langsamer Prozess sein und unterliegt der Ratenbegrenzung, wenn versucht wird, eine Beliebige Art von Massen sauber. Als Reaktion darauf haben wir einen neuen REST-API-Endpunkt hinzugefügt, um Arbeitselemente im Batch zu löschen und/oder zu zerstören.

@CurrentIteration Makro in Übermittlungsplänen

Mit diesem Update haben wir Unterstützung für das @CurrentIteration Makro für Formatvorlagen in Übermittlungsplänen hinzugefügt. Mit diesem Makro können Sie die aktuelle Iteration aus dem Teamkontext jeder Zeile in Ihrem Plan abrufen.

Logik zum Ändern der Kartengröße in Übermittlungsplänen

Nicht jeder verwendet das Zieldatum und/oder das Startdatum beim Nachverfolgen von Features und Epics. Einige wählen eine Kombination aus Datumsangaben und Iterationspfad. In diesem Release haben wir die Logik verbessert, um die Kombinationen für Iterationspfad und Datumsfeld entsprechend festzulegen, je nachdem, wie sie verwendet werden.

Wenn beispielsweise das Zieldatum nicht verwendet wird und Sie die Größe des Karte ändern, wird der neue Iterationspfad festgelegt, anstatt das Zieldatum zu aktualisieren.

Verbesserungen bei Batchupdates

Wir haben mehrere Änderungen an der Version 7.1 der Batchupdate-API für Arbeitselemente vorgenommen. Dazu gehören geringfügige Leistungsverbesserungen und die Behandlung von Teilausfällen. Das bedeutet, wenn ein Patch fehlschlägt, die anderen jedoch nicht, werden die anderen erfolgreich abgeschlossen.

Klicken Sie hier , um mehr über die REST-API für Batchupdates zu erfahren.

Batchlösch-API

Dieser neue REST-API-Endpunkt zum Löschen und/oder Zerstören von Arbeitselementen im Batch ist jetzt öffentlich verfügbar. Klicken Sie hier, um weitere Informationen zu erhalten.

Verhindern der Bearbeitung freigegebener Auswahllistenfelder

Benutzerdefinierte Felder werden prozessübergreifend gemeinsam genutzt. Dies kann zu einem Problem für Auswahllistenfelder führen, da Prozessadministratoren das Hinzufügen oder Entfernen von Werten aus dem Feld gestatten. Dabei wirken sich die Änderungen auf dieses Feld auf jeden Prozess aus, der es verwendet.

Um dieses Problem zu lösen, haben wir die Möglichkeit hinzugefügt, dass der Sammlungsadministrator ein Feld für die Bearbeitung "sperren" kann. Wenn das Feld für die Auswahlliste gesperrt ist, kann der lokale Prozessadministrator die Werte dieser Auswahlliste nicht ändern. Sie können das Feld nur dem Prozess hinzufügen oder daraus entfernen.

Neue Berechtigung zum Speichern von Kommentaren

Die Möglichkeit, nur Arbeitselementkommentare zu speichern, war eine der wichtigsten Anforderungen in der Entwicklercommunity. Wir freuen uns, Ihnen mitteilen zu können, dass wir dieses Feature implementiert haben. Zunächst sehen wir uns das am häufigsten verwendete Szenario an:

"Ich möchte verhindern, dass einige Benutzer Arbeitselementfelder bearbeiten, aber sie zur Diskussion beitragen können."

Um dies zu erreichen, müssen Sie zu Projekteinstellungen > Projektkonfigurationsbereichspfad >wechseln. Wählen Sie dann den gewünschten Bereichspfad aus, und klicken Sie auf Sicherheit.

Beachten Sie die neue Berechtigung "Bearbeiten von Arbeitselementkommentaren in diesem Knoten". Standardmäßig ist die Berechtigung auf Nicht festgelegt festgelegt. Das bedeutet, das Arbeitselement verhält sich genau wie zuvor. Damit eine Gruppe oder Benutzer Kommentare speichern können, wählen Sie diese Gruppe/Benutzer aus, und ändern Sie die Berechtigung in Zulassen.

Wenn der Benutzer das Arbeitselementformular in diesem Bereichspfad öffnet, kann er Kommentare hinzufügen, aber keines der anderen Felder aktualisieren.

Wir hoffen, Dass Sie dieses Feature genauso lieben wie wir. Wie immer, wenn Sie Feedback oder Vorschläge haben, teilen Sie uns dies bitte mit.

Berichte zu interaktiven Boards

Interaktive Berichte, die sich im Boards-Hub befinden, sind seit mehreren Jahren in unserer gehosteten Version des Produkts zugänglich. Sie ersetzen die älteren Diagramme für kumulative Flussdiagramme, Geschwindigkeit und Sprint-Burndown. Mit diesem Release stellen wir sie zur Verfügung.

Klicken Sie zum Anzeigen dieser Diagramme auf den Seiten Kanban Board, Backlog und Sprints auf die Registerkarte Analyse .

Repos

Entfernen der Berechtigung "Richtlinien bearbeiten" für den Branchersteller

Wenn Sie zuvor einen neuen Branch erstellt haben, wurde Ihnen die Berechtigung zum Bearbeiten von Richtlinien für diesen Branch erteilt. Mit diesem Update ändern wir das Standardverhalten so, dass diese Berechtigung nicht erteilt wird, auch dann nicht, wenn die Einstellung „Berechtigungsverwaltung“ für das Repository aktiviert ist.

Ihnen muss die Berechtigung „Richtlinien bearbeiten“ explizit (entweder manuell oder über die REST-API) durch Vererbung von Sicherheitsberechtigungen oder durch eine Gruppenmitgliedschaft gewährt werden.

Pipelines

Aktuelles Projekt, das als Standardbereich für Buildzugriffstoken in klassischen Pipelines festgelegt ist

Azure Pipelines verwendet Auftragszugriffstoken, um zur Laufzeit auf andere Ressourcen in Azure DevOps zuzugreifen. Ein Auftragszugriffstoken ist ein Sicherheitstoken, das von Azure Pipelines für jeden Auftrag zur Laufzeit dynamisch generiert wird. Zuvor wurde beim Erstellen einer neuen klassischen Pipeline der Standardwert für das Zugriffstoken auf Project Collection festgelegt. Mit diesem Update legen wir den Auftragsautorisierungsbereich auf aktuelles Projekt als Standard fest, wenn eine neue klassische Pipeline erstellt wird.

Weitere Informationen zu Auftragszugriffstoken finden Sie in der Dokumentation zu Access-Repositorys, Artefakten und anderen Ressourcen.

Änderung des Standardbereichs von Zugriffstoken in klassischen Buildpipelines

Um die Sicherheit klassischer Buildpipelines zu verbessern, lautet der Autorisierungsbereich des Buildauftrags beim Erstellen einer neuen Pipeline standardmäßig Project. Bisher war es projektauflistung. Erfahren Sie mehr über Auftragszugriffstoken. Diese Änderung wirkt sich nicht auf vorhandene Pipelines aus. Dies wirkt sich nur auf neue klassische Buildpipelines aus, die Sie ab diesem Zeitpunkt erstellen.

Azure Pipelines-Unterstützung für ServiceNow-Versionen von San Diego, Tokyo & Utah

Azure Pipelines verfügt über eine vorhandene Integration mit ServiceNow. Die Integration basiert auf einer App in ServiceNow und einer Erweiterung in Azure DevOps. Wir haben die App jetzt so aktualisiert, dass sie mit den ServiceNow-Versionen von San Diego, Tokyo & Utah funktioniert. Um sicherzustellen, dass diese Integration funktioniert, führen Sie aus dem ServiceNow Store ein Upgrade auf die neue Version der App (4.215.2) aus.

Weitere Informationen finden Sie in der Dokumentation Integrieren in ServiceNow Change Management.

Verwenden von Proxy-URLs für die GitHub Enterprise-Integration

Azure Pipelines kann in lokale GitHub Enterprise Server integriert werden, um Continuous Integration und PR-Builds auszuführen. In einigen Fällen befindet sich gitHub Enterprise Server hinter einer Firewall und erfordert, dass der Datenverkehr über einen Proxyserver weitergeleitet wird. Zur Unterstützung dieses Szenarios können Sie mit den GitHub Enterprise Server-Dienstverbindungen in Azure DevOps eine Proxy-URL konfigurieren. Bisher wurde nicht der gesamte Datenverkehr von Azure DevOps über diese Proxy-URL weitergeleitet. Mit diesem Update stellen wir sicher, dass wir den folgenden Datenverkehr von Azure Pipelines weiterleiten, um die Proxy-URL zu durchlaufen:

• Abrufen von Branches
• Abrufen von Pull Request-Informationen
• Buildstatus melden

Container Registry-Dienstverbindungen können jetzt verwaltete Azure-Identitäten verwenden.

Sie können eine systemseitig zugewiesene verwaltete Identität verwenden, wenn Sie Docker Registry-Dienstverbindungen für Azure Container Registry erstellen. Dadurch können Sie mithilfe einer verwalteten Identität, die einem selbstgehosteten Azure Pipelines-Agent zugeordnet ist, auf Azure Container Registry zugreifen, sodass Anmeldeinformationen nicht mehr verwaltet werden müssen.

Hinweis

Die verwaltete Identität, die für den Zugriff auf Azure Container Registry verwendet wird, benötigt die entsprechende RBAC-Zuweisung (Azure Role Based Access Control), z. B. die Rolle AcrPull oder AcrPush.

Automatische Token, die für die Kubernetes Service-Verbindung erstellt wurden

Seit Kubernetes 1.24 wurden Token beim Erstellen einer neuen Kubernetes Service-Verbindung nicht mehr automatisch erstellt. Wir haben diese Funktionalität wieder hinzugefügt. Es wird jedoch empfohlen, die Azure-Dienstverbindung beim Zugriff auf AKS zu verwenden. Weitere Informationen finden Sie im Blogbeitrag Dienstverbindungsanleitung für AKS-Kunden, die Kubernetes-Aufgaben verwenden.

Kubernetes-Aufgaben unterstützen jetzt kubelogin

Wir haben die Aufgaben KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 und AzureFunctionOnKubernetes@1 aktualisiert, um kubelogin zu unterstützen. Dadurch können Sie Azure Kubernetes Service (AKS) als Ziel verwenden, der mit Azure Active Directory-Integration konfiguriert ist.

Kubelogin ist auf gehosteten Images nicht vorinstalliert. Um sicherzustellen, dass oben genannte Aufgaben kubelogin verwenden, installieren Sie es, indem Sie den KubeloginInstaller@0 Task vor dem Task einfügen, der davon abhängt:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Verbesserungen bei Pipelineberechtigungen

Wir haben die Verwaltung von Pipelineberechtigungen verbessert, damit das Berechtigungssystem daran erinnert, ob eine Pipeline zuvor eine geschützte Ressource verwendet hat, z. B. eine Dienstverbindung.

Wenn Sie in der Vergangenheit beim Erstellen einer geschützten Ressource "Zugriffsberechtigung für alle Pipelines erteilen" aktiviert haben, dann aber den Zugriff auf die Ressource eingeschränkt haben, benötigte Ihre Pipeline eine neue Autorisierung, um die Ressource zu verwenden. Dieses Verhalten war mit dem nachfolgenden Öffnen und Schließen des Zugriffs auf die Ressource inkonsistent, bei dem keine neue Autorisierung erforderlich war. Dieses Problem wurde nun behoben.

Neuer PAT-Bereich für die Verwaltung von Pipelineautorisierungen und -genehmigungen und -überprüfungen

Wir haben einen neuen PAT-Bereich mit dem Namen Pipeline Resourceshinzugefügt, um schäden zu begrenzen, die durch das Verlusten eines PAT-Tokens verursacht werden. Sie können diesen PAT-Bereich verwenden, wenn Sie die Pipelineautorisierung mithilfe einer geschützten Ressource verwalten, z. B. eine Dienstverbindung, oder um Genehmigungen und Überprüfungen für diese Ressource zu verwalten.

Die folgenden REST-API-Aufrufe unterstützen den neuen PAT-Bereich wie folgt:

• Aktualisieren des Bereichs "Genehmigungs unterstützt" Pipeline Resources Use
• Verwalten von Überprüfungen unterstützt den Bereich Pipeline Resources Use and Manage
• Aktualisieren des Bereichs "Pipelineberechtigungen für Ressourcen unterstützen" Pipeline Resources Use and Manage
• Autorisieren von Definitionsressourcen , die den Bereich unterstützen Pipeline Resources Use and Manage
• Autorisieren von Projektressourcen mit Unterstützung des Bereichs Pipeline Resources Use and Manage

Einschränken des Öffnens geschützter Ressourcen für Ressourcenadministratoren

Um die Sicherheit von Ressourcen zu verbessern, die für die sichere Erstellung und Bereitstellung Ihrer Anwendungen von entscheidender Bedeutung sind, benötigt Azure Pipelines jetzt die Rolle "Ressourcentypadministrator", wenn der Zugriff auf eine Ressource für alle Pipelines geöffnet wird.

Beispielsweise ist eine allgemeine Dienst-Connections-Administratorrolle erforderlich, damit jede Pipeline eine Dienstverbindung verwenden kann. Diese Einschränkung gilt beim Erstellen einer geschützten Ressource oder beim Bearbeiten ihrer Sicherheitskonfiguration.

Darüber hinaus ist die Option Zugriffsberechtigung für alle Pipelines gewähren deaktiviert, wenn Sie eine Dienstverbindung erstellen und nicht über ausreichende Rechte verfügen.

Wenn Sie versuchen, den Zugriff auf eine vorhandene Ressource zu öffnen, und Sie nicht über ausreichende Rechte verfügen, erhalten Sie außerdem die Meldung Sie sind nicht autorisiert, den Zugriff für diese Ressource zu öffnen.

Verbesserungen der Pipelines-REST-API-Sicherheit

Die meisten REST-APIs in Azure DevOps verwenden bereichsbezogene PAT-Token. Einige von ihnen erfordern jedoch vollständig bereichsbezogene PAT-Token. Anders ausgedrückt: Sie müssen ein PAT-Token erstellen, indem Sie "Vollzugriff" auswählen, um einige dieser APIs verwenden zu können. Solche Token stellen ein Sicherheitsrisiko dar, da sie zum Aufrufen einer beliebigen REST-API verwendet werden können. Wir haben Verbesserungen in Azure DevOps vorgenommen, um die Notwendigkeit vollständiger Token zu beseitigen, indem wir jede REST-API in einen bestimmten Bereich integrieren. Im Rahmen dieser Bemühungen erfordert die REST-API zum Aktualisieren von Pipelineberechtigungen für eine Ressource jetzt einen bestimmten Bereich. Der Bereich hängt vom Typ der Ressource ab, die für die Verwendung autorisiert wird:

• Code (read, write, and manage) für Ressourcen vom Typ repository
• Agent Pools (read, manage) oder Environment (read, manage) für Ressourcen vom Typ queue und agentpool
• Secure Files (read, create, and manage) für Ressourcen vom Typ securefile
• Variable Groups (read, create and manage) für Ressourcen vom Typ variablegroup
• Service Endpoints (read, query and manage) für Ressourcen vom Typ endpoint
• Environment (read, manage) für Ressourcen vom Typ environment

Für die Massenbearbeitung von Pipelineberechtigungen benötigen Sie weiterhin ein vollständiges PAT-Token. Weitere Informationen zum Aktualisieren von Pipelineberechtigungen für Ressourcen finden Sie in der Dokumentation Pipelineberechtigungen – Aktualisieren von Pipelineberechtigungen für Ressourcen .

Differenzierte Zugriffsverwaltung für Agentpools

Mit Agentpools können Sie die Computer angeben und verwalten, auf denen Ihre Pipelines ausgeführt werden.

Wenn Sie zuvor einen benutzerdefinierten Agent-Pool verwendet haben, wurde die Verwaltung, welche Pipelines darauf zugreifen können, grob abgestutzt. Sie können allen Pipelines die Verwendung gestatten, oder Sie können verlangen, dass jede Pipeline um eine Berechtigung fragt. Nachdem Sie einer Pipeline zugriffsberechtigung für einen Agentpool erteilt haben, konnten Sie diese leider nicht über die Benutzeroberfläche für Pipelines widerrufen.

Azure Pipelines bietet jetzt eine differenzierte Zugriffsverwaltung für Agentpools. Die Benutzeroberfläche ähnelt der Verwaltung von Pipelineberechtigungen für Service Connections.

Verhindern, dass allen Pipelines Zugriff auf geschützte Ressourcen gewährt wird

Wenn Sie eine geschützte Ressource wie eine Dienstverbindung oder eine Umgebung erstellen, können Sie das Kontrollkästchen Zugriffsberechtigung für alle Pipelines erteilen aktivieren. Bisher war diese Option standardmäßig aktiviert.

Dies erleichtert pipelines zwar die Verwendung neuer geschützter Ressourcen, aber das Gegenteil ist, dass versehentlich zu vielen Pipelines das Recht zum Zugriff auf die Ressource gewährt wird.

Um eine standardmäßig sichere Auswahl zu fördern, lässt Azure DevOps das Kontrollkästchen jetzt deaktiviert.

Möglichkeit zum Deaktivieren der Maskierung für kurze Geheimnisse

Azure Pipelines maskiert Geheimnisse in Protokollen. Geheimnisse können variablen sein, die als Geheimnis markiert sind, Variablen aus Variablengruppen, die mit Azure Key Vault verknüpft sind, oder Elemente einer Dienstverbindung, die vom Dienstanbieter als Geheimnis gekennzeichnet sind.

Alle Vorkommen von Geheimniswerten werden maskiert. Das Maskieren kurzer Geheimnisse wie "1", "2", "", "Dev" macht es leicht, deren Werte zu erraten, z. B. in einem Datum: "Jan 3, 202***"
Es ist jetzt klar, dass "3" ein Geheimnis ist. In solchen Fällen können Sie es vorziehen, das Geheimnis nicht vollständig zu maskieren. Wenn es nicht möglich ist, den Wert nicht als Geheimnis zu markieren (z. B. wird der Wert von Key Vault genommen), können Sie den AZP_IGNORE_SECRETS_SHORTER_THAN Knopf auf einen Wert von bis zu 4 festlegen.

Aufgabe zum Herunterladen des Knotenläufers

Wenn Sie Agent-Releases übernehmen, die den Knoten 6-Aufgabenrunner ausschließen, müssen Sie möglicherweise gelegentlich Aufgaben ausführen, die nicht aktualisiert wurden, um einen neueren Node-Runner zu verwenden. Für dieses Szenario bieten wir eine Methode, um weiterhin Aufgaben zu verwenden, die von Node-End-of-Life-Runnern abhängig sind, siehe Blogbeitrag Node Runner-Anleitungen.

Die folgende Aufgabe ist eine Methode zum Just-in-Time-Installieren des Node 6-Runners, sodass eine alte Aufgabe weiterhin ausgeführt werden kann:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Überprüfung des TFX-Knotenläufers aktualisiert

Aufgabenautoren verwenden das Erweiterungsverpackungstool (TFX), um Erweiterungen zu veröffentlichen. TFX wurde aktualisiert, um Überprüfungen für Node-Runner-Versionen durchzuführen. Weitere Informationen finden Sie im Blogbeitrag "Node Runner-Anleitung".

Bei Erweiterungen, die Aufgaben mit dem Node 6-Runner enthalten, wird die folgende Warnung angezeigt:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Anweisungen für die manuelle Vorinstallation von Knoten 6 auf Pipeline-Agents

Wenn Sie den pipeline- Agent-Feed verwenden, ist Knoten 6 nicht im Agent enthalten. In einigen Fällen, bei denen eine Marketplace-Aufgabe weiterhin von Node 6 abhängig ist und der Agent den NodeTaskRunnerInstaller-Task nicht verwenden kann (z. B. aufgrund von Konnektivitätseinschränkungen), müssen Sie Node 6 unabhängig vorinstallieren. Lesen Sie dazu die Anweisungen zur manuellen Installation von Node 6 Runner.

Änderungsprotokoll für Pipelineaufgaben

Wir veröffentlichen Änderungen an Pipelinetasks jetzt in diesem Änderungsprotokoll. Dies ist die vollständige Liste der Änderungen, die an integrierten Pipelinetasks vorgenommen wurden. Wir haben frühere Änderungen rückwirkend veröffentlicht, sodass das Änderungsprotokoll einen verlaufsbezogenen Datensatz der Taskaktualisierungen bereitstellt.

Freigabetasks verwenden Microsoft Graph-API

Wir haben unsere Releaseaufgaben so aktualisiert, dass sie die Microsoft-Graph-API verwenden. Dadurch wird die Verwendung des AAD-Graph-API aus unseren Aufgaben entfernt.

Windows PowerShell Aufgabenleistungsverbesserung

Sie können Aufgaben verwenden, um die Automatisierung in einer Pipeline zu definieren. Eine dieser Aufgaben ist der PowerShell@2 Hilfsprogrammtask, mit dem Sie PowerShell-Skripts in Ihrer Pipeline ausführen können. Um powerShell-Skripts für eine Azure-Umgebung zu verwenden, können Sie die AzurePowerShell@5 Aufgabe verwenden. Einige PowerShell-Befehle, die Statusaktualisierungen drucken können, z. B Invoke-WebRequest. , werden jetzt schneller ausgeführt. Die Verbesserung ist wichtiger, wenn Sie viele dieser Befehle in Ihrem Skript haben oder wenn sie lange ausgeführt werden. Mit diesem Update ist die progressPreference Eigenschaft der PowerShell@2 Aufgaben und AzurePowerShell@5 jetzt standardmäßig auf SilentlyContinue festgelegt.

Pipelines-Agent v3 unter .NET 6

Der Pipeline-Agent wurde aktualisiert, um .NET 3.1 Core auf .NET 6 als Runtime zu verwenden. Dadurch wird native Unterstützung für Apple Silicon und Windows Arm64 eingeführt.

Die Verwendung von .NET 6 wirkt sich auf die Systemanforderungen für den Agent aus. Insbesondere werden die folgenden Betriebssysteme nicht mehr unterstützt: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Weitere Informationen finden Sie in der Dokumentation zur Agent-Softwareversion 3.

Dieses Skript kann verwendet werden, um Pipelines zu identifizieren, die Agents mit nicht unterstützten Betriebssystemen verwenden.

Wichtig

Beachten Sie, dass Agents, die unter einem der oben genannten Betriebssysteme ausgeführt werden, entweder nicht mehr aktualisiert werden oder fehlschlagen, sobald wir den .NET 6-basierten Agent ausrollen.

Angeben der Agentversion in der Agent-VM-Erweiterung

Azure-VMs können mithilfe einer VM-Erweiterung in Bereitstellungsgruppen einbezogen werden. Die VM-Erweiterung wurde aktualisiert, um optional die gewünschte Agent-Version anzugeben, die installiert werden soll:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Neue Umschalter zum Steuern der Erstellung von klassischen Pipelines

Mit Azure DevOps können Sie jetzt sicherstellen, dass Ihre Projektsammlung nur YAML-Pipelines verwendet, indem Sie die Erstellung von klassischen Buildpipelines, klassischen Releasepipelines, Taskgruppen und Bereitstellungsgruppen deaktivieren. Ihre vorhandenen klassischen Pipelines werden weiterhin ausgeführt, und Sie können sie bearbeiten, aber sie können keine neuen Pipelines erstellen.

Mit Azure DevOps können Sie jetzt sicherstellen, dass Ihre organization nur YAML-Pipelines verwendet, indem Sie die Erstellung von klassischen Buildpipelines, klassischen Releasepipelines, Taskgruppen und Bereitstellungsgruppen deaktivieren. Ihre vorhandenen klassischen Pipelines werden weiterhin ausgeführt, und Sie können sie bearbeiten, aber sie können keine neuen Pipelines erstellen.

Sie können die Erstellung von klassischen Pipelines auf Projektsammlungsebene oder Projektebene deaktivieren, indem Sie die entsprechenden Umschaltvorgänge aktivieren. Die Umschaltmöglichkeiten finden Sie unter Projekt-/Projekteinstellungen –> Pipelines –> Einstellungen. Es gibt zwei Umschalter: einen für klassische Buildpipelines und einen für klassische Releasepipelines , Bereitstellungsgruppen und Taskgruppen.

Der Umschaltzustand ist standardmäßig deaktiviert, und Sie benötigen Administratorrechte, um den Zustand zu ändern. Wenn der Umschalter auf organization-Ebene aktiviert ist, wird die Deaktivierung für alle Projekte erzwungen. Andernfalls kann jedes Projekt frei entscheiden, ob die Deaktivierung erzwungen werden soll oder nicht.

Wenn die Deaktivierung der Erstellung von klassischen Pipelines erzwungen wird, schlagen REST-APIs im Zusammenhang mit der Erstellung klassischer Pipelines, Aufgabengruppen und Bereitstellungsgruppen fehl. REST-APIs, die YAML-Pipelines erstellen, funktionieren.

Updates zum Diensthakenereignis "Ausführungszustand geändert"

Mithilfe von Diensthaken können Sie Aufgaben für andere Dienste ausführen, wenn Ereignisse in Ihrem Projekt in Azure DevOps auftreten. Der Zustand der Ausführungsphase wurde geändert ist eines dieser Ereignisse. Das Ereignis run stage state changed muss Informationen zur Ausführung enthalten, einschließlich des Namens der Pipeline. Zuvor enthielt sie nur Informationen zur ID und zum Namen der Ausführung. Mit diesem Update haben wir Änderungen am Ereignis vorgenommen, um fehlende Informationen einzuschließen.

Deaktivieren der Anzeige der letzten Commitnachricht für eine Pipelineausführung

Zuvor wurde die Pipelines-Benutzeroberfläche verwendet, um die letzte Commitmeldung beim Anzeigen der Ausführung einer Pipeline anzuzeigen.

Diese Meldung kann beispielsweise verwirrend sein, wenn sich der Code Ihrer YAML-Pipeline in einem anderen Repository befindet als in dem, das den erstellten Code enthält. Wir haben Ihr Feedback von der Entwicklercommunity um eine Möglichkeit gebeten, das Anfügen der neuesten Commitnachricht an den Titel jeder Pipelineausführung zu aktivieren/deaktivieren.

Mit diesem Update haben wir eine neue YAML-Eigenschaft namens appendCommitMessageToRunNamehinzugefügt, mit der Sie genau dies tun können. Standardmäßig ist die -Eigenschaft auf truefestgelegt. Wenn Sie es auf falsefestlegen, zeigt die Pipelineausführung nur den BuildNumberan.

Erhöhte Azure Pipeline-Grenzwerte, um die maximale Größe der Arm-Vorlage (4 MB) von 4 MB (Azure Resource Manager) zu verwenden.

Sie können den Task Azure Resource Manager Vorlagenbereitstellung verwenden, um eine Azure-Infrastruktur zu erstellen. Als Reaktion auf Ihr Feedback haben wir das Integrationslimit für Azure Pipelines von 2 MB auf 4 MB erhöht. Dies entspricht der maximalen Größe von ARM-Vorlagen von 4 MB , die Größeneinschränkungen während der Integration großer Vorlagen auflösen.

Übersichtssymbol status Pipelineausführung

Mit diesem Release machen wir es einfacher, die gesamte status einer Pipelineausführung zu kennen.

Bei YAML-Pipelines mit vielen Phasen war es früher schwierig, die status einer Pipelineausführung zu kennen, d. h. wird sie noch ausgeführt oder ist sie fertig. Und wenn es abgeschlossen ist, was ist der Gesamtzustand: erfolgreich, fehlgeschlagen oder abgebrochen. Dieses Problem wurde behoben, indem wir ein Run status Übersichtssymbol hinzugefügt haben.

Seitenbereich "Pipelinephasen"

YAML-Pipelines können Dutzende von Phasen aufweisen, und nicht alle passen auf Ihren Bildschirm. Während das Übersichtssymbol der Pipelineausführung den Gesamtzustand Ihrer Ausführung anzeigt, ist es immer noch schwierig zu wissen, welche Phase fehlgeschlagen ist oder welche Phase noch ausgeführt wird.

In dieser Version haben wir einen Seitenbereich für Pipelinephasen hinzugefügt, mit dem Sie schnell den Status aller Phasen anzeigen können. Sie können dann auf eine Phase klicken und direkt zu den zugehörigen Protokollen gelangen.

Suchen nach Phasen im Seitenbereich

Wir haben es einfacher gemacht, die gewünschten Etappen im Seitenbereich der Etappen zu finden. Sie können jetzt schnell nach Phasen basierend auf ihren status filtern, z. B. nach Ausführungsphasen oder solchen, die einen manuellen Eingriff erfordern. Sie können auch nach Phasen nach ihrem Namen suchen.

Schnelle Aktionen inszen

Mit dem Bildschirm "Ausführung" einer Pipeline können Sie schnell auf alle Ausführungsphasen zugreifen. In dieser Version haben wir einen Stufenbereich hinzugefügt, in dem Sie Aktionen für jede Phase ausführen können. Beispielsweise können Sie fehlgeschlagene Aufträge einfach erneut ausführen oder die gesamte Phase erneut ausführen. Der Bereich ist verfügbar, wenn nicht alle Phasen in die Benutzeroberfläche passen, wie Sie im folgenden Screenshot sehen können.

Wenn Sie in der Spalte "Phasen" auf das Zeichen "+" klicken, wird der Abschnitt "Phasen" angezeigt, und Sie können dann Bühnenaktionen ausführen.

Überprüft Verbesserungen der Benutzerfreundlichkeit

Wir erleichtern das Lesen von Prüfprotokollen. Überprüfungsprotokolle enthalten Informationen, die für den Erfolg Ihrer Bereitstellung wichtig sind. Sie können Ihnen mitteilen, ob Sie vergessen haben, ein Arbeitselementticket zu schließen, oder dass Sie ein Ticket in ServiceNow aktualisieren müssen. Früher war es schwierig zu wissen, dass eine Überprüfung solche wichtigen Informationen lieferte.

Auf der Seite mit den Pipelineausführungsdetails wird nun das neueste Prüfprotokoll angezeigt. Dies gilt nur für Überprüfungen, die unserer empfohlenen Verwendung entsprechen.

Um versehentlich genehmigte Genehmigungen zu verhindern, zeigt Azure DevOps die Anweisungen für genehmigende Personen im Seitenbereich Genehmigungen und Überprüfungen auf der Detailseite einer Pipelineausführung an.

Deaktivieren einer Überprüfung

Das Debuggen von Überprüfungen wurde weniger langwierig. Manchmal funktioniert eine Überprüfung von Azure-Funktion aufrufen oder REST-API aufrufen nicht ordnungsgemäß, und Sie müssen sie beheben. Zuvor mussten Sie solche Überprüfungen löschen, um zu verhindern, dass sie eine Bereitstellung fälschlicherweise blockieren. Nachdem Sie die Überprüfung behoben haben, mussten Sie sie wieder hinzufügen und ordnungsgemäß konfigurieren, um sicherzustellen, dass alle erforderlichen Header festgelegt oder die Abfrageparameter korrekt sind. Das ist mühsam.

Jetzt können Sie einfach eine Überprüfung deaktivieren. Die deaktivierte Überprüfung wird in nachfolgenden Check Suite-Auswertungen nicht ausgeführt.

Nachdem Sie die fehlerhafte Überprüfung behoben haben, können Sie sie einfach aktivieren.

Verbrauchte Ressourcen und Vorlagenparameter in der Rest-API für Pipelinesausführungen

Die REST-API für erweiterte Pipelineausführungen gibt jetzt weitere Arten von Artefakten zurück, die von einer Pipelineausführung verwendet werden, und die Parameter, die zum Auslösen dieser Ausführung verwendet werden. Wir haben die API verbessert, um die container Ressourcen und pipeline und die Vorlagenparameter zurückzugeben, die in einer Pipelineausführung verwendet werden. Sie können jetzt beispielsweise Konformitätsprüfungen schreiben, die die Repositorys, Container und andere Pipelineausführungen einer Pipeline auswerten.

Hier sehen Sie ein Beispiel für den neuen Antworttext.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Unterstützung von Vorlagen für allgemeine Verfügbarkeit im YAML-Editor

Vorlagen sind ein häufig verwendetes Feature in YAML-Pipelines. Sie sind eine einfache Möglichkeit, Pipelineausschnitte freizugeben. Sie sind auch ein leistungsstarker Mechanismus zum Überprüfen oder Erzwingen von Sicherheit und Governance über Ihre Pipeline.

Azure Pipelines unterstützt einen YAML-Editor, der beim Bearbeiten Ihrer Pipeline hilfreich sein kann. Der Editor hat jedoch bis jetzt keine Vorlagen unterstützt. Autoren von YAML-Pipelines konnten keine Unterstützung über intellisense erhalten, wenn sie eine Vorlage verwenden. Vorlagenautoren konnten den YAML-Editor nicht verwenden. In diesem Release wird unterstützung für Vorlagen im YAML-Editor hinzugefügt.

Beim Bearbeiten der YAML-Hauptdatei in Azure Pipelines können Sie eine Vorlage entweder einschließen oder erweitern. Wenn Sie den Namen Ihrer Vorlage eingeben, werden Sie aufgefordert, Ihre Vorlage zu überprüfen. Nach der Überprüfung versteht der YAML-Editor das Schema der Vorlage einschließlich der Eingabeparameter.

Nach der Überprüfung können Sie zur Vorlage navigieren. Sie können Änderungen an der Vorlage vornehmen, indem Sie alle Features des YAML-Editors verwenden.

Es gibt bekannte Einschränkungen:

• Wenn die Vorlage über erforderliche Parameter verfügt, die nicht als Eingaben in der Standard YAML-Datei bereitgestellt werden, schlägt die Überprüfung fehl, und Sie werden aufgefordert, diese Eingaben bereitzustellen. Idealerweise sollte die Überprüfung nicht blockiert werden, und Sie sollten in der Lage sein, die Eingabeparameter mithilfe von intellisense auszufüllen.
• Sie können keine neue Vorlage im Editor erstellen. Sie können nur vorhandene Vorlagen verwenden oder bearbeiten.

Neue vordefinierte Systemvariable

Wir haben eine neue vordefinierte Systemvariable namens Build.DefinitionFolderPatheingeführt, deren Wert der Ordnerpfad einer Buildpipelinedefinition ist. Die Variable ist sowohl in YAML- als auch in klassischen Buildpipelines verfügbar.

Wenn Ihre Pipeline beispielsweise unter dem FabrikamFiber\Chat Ordner in Azure Pipelines untergebracht ist, ist FabrikamFiber\Chatder Wert von Build.DefinitionFolderPath .

Hinzufügen von Unterstützung für die Zeichenfolgenaufteilungsfunktion in YAML-Vorlagenausdrücken

YAML-Pipelines bieten praktische Möglichkeiten, codeduplizieren zu können, z. B. das Durchlaufen each des Werts einer Liste oder Eigenschaft eines Objekts.

Manchmal wird der Satz von Elementen, durch die durchlaufen werden soll, als Zeichenfolge dargestellt. Beispielsweise, wenn die Liste der Umgebungen, in die bereitgestellt werden soll, durch die Zeichenfolge integration1, integration2definiert wird.

Als wir Ihr Feedback vom Entwicklercommunity gehört haben, haben wir gehört, dass Sie eine Zeichenfolgenfunktion split in YAML-Vorlagenausdrücken wünschen.

Nun können split Sie eine Zeichenfolge durchlaufen und ihre Teilzeichenfolgen durchlaufen each .

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Vorlagenausdrücke in der Repositoryressourcendefinition

Wir haben Unterstützung für Vorlagenausdrücke hinzugefügt, wenn die ref Eigenschaft einer repository Ressource in einer YAML-Pipeline definiert wird. Dies war ein von unserem Entwicklercommunity dringend angefordertes Feature.

Es gibt Anwendungsfälle, wenn Ihre Pipeline verschiedene Branches derselben Repositoryressource auschecken soll.

Angenommen, Sie verfügen über eine Pipeline, die ein eigenes Repository erstellt, und dazu muss sie eine Bibliothek aus einem Ressourcenrepository auschecken. Angenommen, Sie möchten, dass Ihre Pipeline denselben Bibliotheksbranch auscheckt, den sie selbst verwendet. Wenn Ihre Pipeline beispielsweise auf dem main Branch ausgeführt wird, sollte sie den main Branch des Bibliotheksrepositorys auschecken. Wenn die Pipelines auf dem dev Branch ausgeführt werden, sollte der Bibliotheksbranch dev ausgecheckt werden.

Bis heute mussten Sie den auszucheckenden Branch explizit angeben und den Pipelinecode ändern, wenn sich der Branch ändert.

Jetzt können Sie Vorlagenausdrücke verwenden, um den Branch einer Repositoryressource auszuwählen. Sehen Sie sich das folgende Beispiel für YAML-Code an, der für die nicht Standard Branches Ihrer Pipeline verwendet werden soll:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Wenn Sie die Pipeline ausführen, können Sie den Branch angeben, der nach dem library Repository ausgecheckt werden soll.

Angeben der Version einer Vorlage, die zur Buildwarteschlangenzeit erweitert werden soll

Vorlagen stellen eine hervorragende Möglichkeit dar, um Die Duplizierung von Code zu reduzieren unddie Sicherheit Ihrer Pipelines zu verbessern.

Ein beliebter Anwendungsfall ist das Speichern von Vorlagen in einem eigenen Repository. Dies reduziert die Kopplung zwischen einer Vorlage und den Pipelines, die sie erweitern, und erleichtert die eigenständige Weiterentwicklung der Vorlage und der Pipelines.

Betrachten Sie das folgende Beispiel, in dem eine Vorlage verwendet wird, um die Ausführung einer Liste von Schritten zu überwachen. Der Vorlagencode befindet sich im Templates Repository.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Angenommen, Sie verfügen über eine YAML-Pipeline, die diese Vorlage erweitert, die sich im Repository FabrikamFiberbefindet. Bis heute war es nicht möglich, die ref Eigenschaft der templates Repositoryressource dynamisch anzugeben, wenn das Repository als Vorlagenquelle verwendet wurde. Dies bedeutete, dass Sie den Code der Pipeline ändern mussten, wenn Sie möchten, dass ihre Pipeline eine Vorlage aus einem anderen Branch erweitert, um eine Vorlage mit demselben Branchnamen wie Ihre Pipeline zu erweitern, unabhängig davon, auf welchem Branch Sie Ihre Pipeline ausgeführt haben.

Mit der Einführung von Vorlagenausdrücken in der Repositoryressourcendefinition können Sie Ihre Pipeline wie folgt schreiben:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Dadurch erweitert Ihre Pipeline die Vorlage im selben Branch wie der Branch, auf dem die Pipeline ausgeführt wird, sodass Sie sicherstellen können, dass die Branches Ihrer Pipeline und der Vorlage immer übereinstimmen. Das heißt, wenn Sie Ihre Pipeline in einem Branch devausführen, wird die von der template.yml Datei im dev Branch des templates Repositorys angegebene Vorlage erweitert.

Alternativ können Sie während der Buildwarteschlange auswählen, welcher Vorlagenrepository-Branch verwendet werden soll, indem Sie den folgenden YAML-Code schreiben.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Jetzt können Sie für Ihre Pipeline in einem Branch main eine Vorlage aus einem Branch dev in einer Ausführung erweitern und eine Vorlage aus einem Branch main in einer anderen Ausführung erweitern, ohne den Code Ihrer Pipeline zu ändern.

Wenn Sie einen Vorlagenausdruck für die ref Eigenschaft einer Repositoryressource angeben, können Sie vordefinierte Variablen und vom System verwenden parameters , sie können jedoch keine durch YAML oder Pipelines benutzerdefinierte Variablen verwenden.

Vorlagenausdrücke in der Containerressourcendefinition

Wir haben Unterstützung für Vorlagenausdrücke hinzugefügt, wenn die endpointEigenschaften , volumes, portsund options einer container Ressource in einer YAML-Pipeline definiert werden. Dies war ein von unserem Entwicklercommunity dringend angefordertes Feature.

Jetzt können Sie YAML-Pipelines wie folgt schreiben.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Sie können und variables. in Ihren Vorlagenausdrücken verwendenparameters.. Für Variablen können Sie nur diejenigen verwenden, die in der YAML-Datei definiert sind, aber nicht die in der Pipelines-Benutzeroberfläche definierten. Wenn Sie die Variable neu definieren, z. B. mithilfe von Agentprotokollbefehlen, hat dies keine Auswirkung.

Verbesserungen geplanter Builds

Es wurde ein Problem behoben, das dazu führte, dass die Zeitplaninformationen einer Pipeline beschädigt wurden und die Pipeline nicht geladen wurde. Dies wurde beispielsweise verursacht, wenn der Name des Branch eine bestimmte Anzahl von Zeichen überschritten hat.

Verbesserte Fehlermeldung beim Nichtladen von Pipelines

Azure Pipelines bietet mehrere Arten von Triggern, mit denen Sie konfigurieren können, wie Ihre Pipeline gestartet wird. Eine Möglichkeit zum Ausführen einer Pipeline ist die Verwendung geplanter Trigger. Manchmal werden die Informationen zur geplanten Ausführung einer Pipeline beschädigt und können dazu führen, dass ein Ladevorgang fehlschlägt. Zuvor haben wir eine irreführende Fehlermeldung angezeigt, in der behauptet wurde, dass die Pipeline nicht gefunden wurde. Mit diesem Update haben wir dieses Problem behoben und geben eine informative Fehlermeldung zurück. In Zukunft erhalten Sie eine Meldung ähnlich der folgenden: Buildzeitplandaten sind beschädigt , wenn eine Pipeline nicht geladen werden kann.

Keine Synchronisierung von Tags beim Abrufen eines Git-Repositorys

Der Auschecktask verwendet --tags die Option zum Abrufen des Inhalts eines Git-Repositorys. Dies bewirkt, dass der Server alle Tags und alle Objekte abruft, auf die von diesen Tags verwiesen wird. Dies erhöht die Zeit zum Ausführen der Aufgabe in einer Pipeline , insbesondere wenn Sie über ein großes Repository mit einer Reihe von Tags verfügen. Darüber hinaus synchronisiert der Auschecktask Tags, auch wenn Sie die Option für den flachen Abruf aktivieren, wodurch möglicherweise derEn Zweck verfehlt wird. Um die Menge der Daten zu reduzieren, die aus einem Git-Repository abgerufen oder abgerufen werden, haben wir der Aufgabe jetzt eine neue Option hinzugefügt, um das Verhalten der Synchronisierung von Tags zu steuern. Diese Option ist sowohl in klassischen als auch in YAML-Pipelines verfügbar.

YAML

Dieses Verhalten kann entweder über die YAML-Datei oder über die Benutzeroberfläche gesteuert werden.

Um die Synchronisierung der Tags über die YAML-Datei zu deaktivieren, fügen Sie dem Auscheckschritt hinzu fetchTags: false . Wenn die fetchTags Option nicht angegeben ist, entspricht sie dem, wenn fetchTags: true verwendet wird.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Wenn Sie das Verhalten vorhandener YAML-Pipelines ändern möchten, ist es möglicherweise praktischer, diese Option auf der Benutzeroberfläche festzulegen, anstatt die YAML-Datei zu aktualisieren. Um zur Benutzeroberfläche zu navigieren, öffnen Sie den YAML-Editor für die Pipeline, wählen Sie Trigger, dann Verarbeiten und dann den Schritt Auschecken aus.

Wenn Sie diese Einstellung sowohl in der YAML-Datei als auch in der Benutzeroberfläche angeben, hat der in der YAML-Datei angegebene Wert Vorrang.

Klassisch

Um die Synchronisierung der Tags zu deaktivieren, deaktivieren Sie das Kontrollkästchen Tags synchronisieren im Schritt Quellen abrufen.

Für alle neuen Pipelines, die Sie erstellen (YAML oder Klassisch), werden Tags weiterhin standardmäßig synchronisiert. Diese Option ändert nicht das Verhalten vorhandener Pipelines. Tags werden in diesen Pipelines weiterhin synchronisiert, es sei denn, Sie ändern die Option explizit wie oben beschrieben.

Artifacts

Aktualisierte Standardfeedberechtigungen

Project Collection Build Service-Konten verfügen jetzt standardmäßig über die Rolle "Mitarbeiter ", wenn ein neuer Azure Artifacts-Feed im Bereich der Projektsammlung anstelle der aktuellen Rolle Mitwirkender erstellt wird.

Neue Benutzeroberfläche für Upstream Paketsuche

Zuvor konnten Sie Upstream Pakete sehen, wenn Sie über eine Kopie des Feeds verfügen. Der Problempunkt war, dass Sie nicht nach Paketen suchen konnten, die im Upstream verfügbar sind und noch nicht im Feed gespeichert sind. Jetzt können Sie mit der neuen Feed-Benutzeroberfläche nach verfügbaren Upstream-Paketen suchen.

Azure Artifacts bietet jetzt eine Benutzeroberfläche, mit der Sie in Ihren Upstream Quellen nach Paketen suchen und Paketversionen in Ihrem Feed speichern können. Dies entspricht dem Ziel von Microsoft, unsere Produkte und Dienste zu verbessern.

Berichterstellung

Übergeordnetes Element im Widget "Abfrageergebnisse anzeigen"

Das Abfrageergebniswidget unterstützt jetzt den Namen des übergeordneten Elements und einen direkten Link zu diesem übergeordneten Element.

Dashboard kopieren

In dieser Version wird das Kopierdashboard hinzugefügt.

Dashboards: Datum des letzten Zugriffs und Änderung von

Eine der Herausforderungen bei der Erstellung mehrerer Dashboards durch Teams besteht darin, veraltete und nicht verwendete Dashboards zu verwalten und zu bereinigen. Es ist wichtig zu wissen, wann ein Dashboard zuletzt besucht oder geändert wurde, um zu verstehen, welche entfernt werden können. In dieser Version haben wir zwei neue Spalten auf der Verzeichnisseite Dashboards hinzugefügt. Datum des letzten Zugriffs wird nachverfolgt, wann die Dashboard zuletzt besucht wurde. Modified By verfolgt, wann die Dashboard zuletzt bearbeitet wurde und von wem.

Die Informationen Geändert von werden auch auf der Seite Dashboard selbst angezeigt.

Wir hoffen, dass diese neuen Felder Projektadministratoren helfen, die Aktivitätsebene für Dashboards zu verstehen, um eine fundierte Entscheidung zu treffen, ob sie entfernt werden sollen oder nicht.

Analyseansichten sind jetzt verfügbar

Das Feature "Analyseansichten " befindet sich in unserer gehosteten Version des Produkts für einen längeren Zeitraum in einem Vorschauzustand. Mit dieser Version freuen wir uns, ihnen mitteilen zu können, dass dieses Feature jetzt für alle Projektsammlungen verfügbar ist.

In der Navigation wurden die Analyseansichten von der Registerkarte Übersicht auf die Registerkarte Boards verschoben.

Eine Analyseansicht bietet eine vereinfachte Möglichkeit, die Filterkriterien für einen Power BI-Bericht basierend auf Analysedaten anzugeben. Wenn Sie mit Analyseansichten nicht vertraut sind, finden Sie hier eine Dokumentation, die Sie nachholen kann:

• Informationen zu Analytics-Ansichten
• Erstellen einer Analyseansicht in Azure DevOps
• Verwalten von Analytics-Ansichten
• Erstellen eines Power BI-Berichts mit einer standardmäßigen Analyseansicht
• Herstellen einer Verbindung mit Analytics mit dem Power BI-Datenconnector

Pull Request-Widget für mehrere Repositorys jetzt verfügbar

Wir freuen uns, ihnen mitteilen zu können, dass das Pull Request-Widget für mehrere Repositorys in Azure DevOps Server 2022.1 verfügbar ist. Mit diesem neuen Widget können Sie Pull Requests aus bis zu 10 verschiedenen Repositorys mühelos in einer einzigen, optimierten Liste anzeigen, sodass Sie ihre Pull Requests einfacher als je zuvor auf dem neuesten Stand halten können.

Community-Vorschlagsticket

Einführung der Auflösung als abgeschlossen in Burndown- und Burnupdiagrammen

Wir wissen, wie wichtig es ist, den Teamfortschritt genau widerzuspiegeln, einschließlich der aufgelösten Elemente, die in den Diagrammen abgeschlossen sind. Mit einer einfachen Umschaltoption können Sie jetzt festlegen, dass aufgelöste Elemente als abgeschlossen angezeigt werden sollen, sodass der Burndownzustand des Teams wirklich widergespiegelt wird. Diese Erweiterung ermöglicht eine genauere Nachverfolgung und Planung, sodass Teams fundierte Entscheidungen basierend auf dem tatsächlichen Fortschritt treffen können. Mit den aktualisierten Burndown- und Burnupdiagrammen in der Berichterstellung erhalten Sie eine verbesserte Transparenz und bessere Erkenntnisse.

Wiki

Unterstützung für zusätzliche Diagrammtypen auf Wiki-Seiten

Wir haben die Version von Meerjungfrauendiagrammen, die auf Wiki-Seiten verwendet werden, auf 8.13.9 aktualisiert. Mit diesem Upgrade können Sie jetzt die folgenden Diagramme und Visualisierungen in Ihre Azure DevOps-Wikiseiten einfügen:

• Flussdiagramm
• Sequenzdiagramme
• Gantt-Diagramme
• Kreisdiagramme
• Anforderungsdiagramme
• Zustandsdiagramme
• User Journey

Diagramme, die sich im experimentellen Modus befinden, z. B. Entitätsbeziehung und Git Graph, sind nicht enthalten. Weitere Informationen zu den neuen Features finden Sie in den Versionshinweisen zu Meerjungfrauen.

---

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen, es über Entwicklercommunity nachverfolgen und Sich zu Stack Overflow beraten lassen.

---

Seitenanfang