Versionshinweise zu Azure DevOps Server 2022 Update 1

---

| Entwickler-Community | Systemanforderungen und Kompatibilität | Lizenzbedingungen | DevOps-Blog | SHA-256-Hashes |

---

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

Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server-Bereitstellung finden Sie unter Azure DevOps Server Requirements.

Informationen zum Herunterladen von Azure DevOps Server-Produkten finden Sie auf der Seite "Azure DevOps Server-Downloads".

Direktes Upgrade auf Azure DevOps Server 2022 Update 1 wird von Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2013 oder einer früheren Version befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2022 durchführen. Weitere Informationen finden Sie auf der Seite "Installieren" .

---

Azure DevOps Server 2022 Update 1 Patch 4 Veröffentlichungsdatum: 11. Juni 2024

Datei	SHA-256 Hash-Wert
devops2022.1patch4.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Wir haben Patch 4 für Azure DevOps Server 2022 Update 1 veröffentlicht, das einen Fix für Folgendes enthält.

• Es wurde ein Problem mit Wiki- und Arbeitsaufgaben gelöst, bei dem Suchergebnisse für Projekte mit dem türkischen Buchstaben "I" in ihrem Namen im türkischen Gebietsschema nicht verfügbar waren.

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

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

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

• Ein Problem wurde behoben, bei dem der Proxyserver nach der Installation von Patch 2 nicht mehr funktionierte.
• Es wurde ein Renderingproblem auf der Erweiterungsdetailseite 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-Wert
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

• Behebung des Problems beim Rendern der Detailseite in der Sucherweiterung.
• Ein Fehler wurde behoben, bei dem der vom Proxycacheordner verwendete Speicherplatz falsch berechnet wurde und der Ordner nicht ordnungsgemäß bereinigt wurde.
• CVE-2024-20667: Sicherheitsanfälligkeit in Azure DevOps Server bezüglich Remotecodeausführung.

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

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

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

• Verhindern Sie die Einstellung von requested for, wenn Sie einen Pipeline-Run starten.

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 die Verwendung des Update-Agents in der Agentpoolkonfiguration nicht aktualisiert. Wir arbeiten derzeit an einem Patch, um dieses Problem zu beheben, und werden Updates in der Entwicklercommunity teilen, während wir Fortschritte machen. In der Zwischenzeit finden Sie eine Problemumgehung für dieses Problem in diesem Entwickler-Community-Ticket.
2. Maven 3.9.x-Kompatibilität. Maven 3.9.x führte bahnbrechende Änderungen mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport auf systemeigene HTTP von Wagon aktualisiert wird. Dies führt zu 401 Authentifizierungsproblemen für Kunden, die http anstelle von https verwenden. Weitere Details zu diesem Problem finden Sie hier. Als Problemumgehung können Sie maven 3.9.x weiterhin mit der Eigenschaft -Dmaven.resolver.transport=wagonverwenden. Diese Änderung zwingt Maven, den Wagon Resolver Transport zu verwenden. Weitere Details finden Sie in der Dokumentation.

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

Hinweis

Es gibt ein bekanntes Problem mit der Maven 3.9.x-Kompatibilität. Maven 3.9.x führte bahnbrechende Änderungen mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport auf systemeigene HTTP von Wagon aktualisiert wird. Dies führt zu 401 Authentifizierungsproblemen für Kunden, die http anstelle von https verwenden. Weitere Details zu diesem Problem finden Sie hier.

Als Problemumgehung können Sie maven 3.9.x weiterhin mit der Eigenschaft -Dmaven.resolver.transport=wagonverwenden. Diese Änderung bringt Maven dazu, den "Wagon Resolver Transport" zu verwenden. Weitere Details finden Sie in der Dokumentation.

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

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

Hinweis

Es gibt ein bekanntes Problem mit der Maven 3.9.x-Kompatibilität. Maven 3.9.x führte bahnbrechende Änderungen mit Azure Artifacts ein, indem der Standardmäßige Maven Resolver-Transport auf systemeigene HTTP von Wagon aktualisiert wird. Dies führt zu 401 Authentifizierungsproblemen für Kunden, die http anstelle von https verwenden. Weitere Details zu diesem Problem finden Sie hier.

Als Problemumgehung können Sie maven 3.9.x weiterhin mit der Eigenschaft -Dmaven.resolver.transport=wagonverwenden. Diese Änderung zwingt Maven zur Verwendung des Wagon Resolver Transport. Weitere Details finden Sie in der Dokumentation.

Folgendes wurde mit dieser Version behoben:

• Ein Problem in lokalen Feeds wurde behoben, bei dem Einträge im Upstream nicht auf Anzeigenamenänderungen reagierten.
• Ein unerwarteter Fehler ist aufgetreten, als Sie von der Registerkarte 'Code' zu einer anderen auf der Suchseite gewechselt haben.
• Fehler beim Erstellen eines neuen Arbeitsaufgabentyps mit Chinesisch, Japanisch und Koreanisch (CJK) Unified Ideographen. Ein Fragezeichen wurde im RAW-Protokoll bei gated check-in angezeigt, wenn der Name des Teamprojekts oder die Dateien CJK enthalten.
• Es wurde ein Problem bei der Installation von Search behoben, bei dem der Java Virtual Machine (JVM) nicht genügend Arbeitsspeicher für den elastic Search-Prozess zuordnen konnte. Das Suchkonfigurations-Widget verwendet nun Java Development Kit (JDK), das mit Elastic Search 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. Zu den Highlights gehören:

• Alle öffentlichen REST-APIs unterstützen granulare PAT-Bereiche
• Spalte "Letzter Zugriff" auf der Seite "Übermittlungspläne"
• Visualisieren aller Abhängigkeiten von Übermittlungsplänen
• @CurrentIteration Makro in Übermittlungsplänen
• Aktueller Projektsatz als Standardbereich für Buildzugriffstoken in klassischen Pipelines
• Übergeordnetes Element im Abfrageergebnis-Widget anzeigen
• Dashboard kopieren
• Unterstützung für zusätzliche Diagrammtypen auf Wiki-Seiten
• Dienstverbindungen der Container-Registry 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
• Tafeln
• Repos
• Pipelines
• Artefakte
• Berichterstellung
• Wiki

---

Allgemein

Alle öffentlichen REST-APIs unterstützen granulare PAT-Bereiche

Bisher waren eine Reihe öffentlich dokumentierter Azure DevOps-REST-APIs nicht mit Bereichen (z. B. Arbeitsobjektlesevorgänge) verknüpft, was dazu führte, dass Kunden umfassende Bereiche verwendeten, um auf diese APIs über nicht interaktive Authentifizierungsmechanismen wie persönliche Zugriffstoken (PAT) zuzugreifen. Die Verwendung eines vollständigen Persönlichen Zugriffstokens erhöht das Risiko, wenn sie in den Händen eines böswilligen Benutzers landen können. Dies ist einer der Hauptgründe, warum viele unserer Kunden die Steuerungsebenenrichtlinien nicht vollständig nutzen, um die Nutzung und das Verhalten des PAT einzuschränken.

Jetzt sind alle öffentlichen Azure DevOps-REST-APIs mit einem granularen PAT-Bereich verknüpft und unterstützen diesen. 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 spezifischen Bereich in Betracht ziehen, der von der API akzeptiert wird, 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 gibt es hier eine Tabelle mit Bereichen.

Erweiterungen sollten ihre Bereiche anzeigen

Beim Installieren von Erweiterungen in Ihrer Azure DevOps-Sammlung können Sie die Berechtigungen überprüfen, die die Erweiterung als Teil der Installation benötigt. Sobald sie jedoch installiert wurden, sind die Erweiterungsberechtigungen in den Erweiterungseinstellungen nicht sichtbar. Dies stellt eine Herausforderung für Administratoren dar, die eine regelmäßige Überprüfung der installierten Erweiterungen durchführen müssen. Jetzt haben wir die Erweiterungsberechtigungen für Erweiterungseinstellungen hinzugefügt, um Sie bei der Überprüfung und Entscheidung darüber zu unterstützen, ob sie beibehalten werden sollen oder nicht.

Boards

Spalte „Letzter Zugriff” auf der Seite „Übermittlungspläne”

Auf der Verzeichnisseite "Übermittlungspläne" finden Sie eine Liste der pläne, die für Ihr Projekt definiert sind. Sie können sortieren nach: Name, Erstellt von, Beschreibung, Zuletzt konfiguriert oder Favoriten. Mit diesem Update haben wir der Verzeichnisseite eine Spalte "Letzter Zugriff" hinzugefügt. Dadurch wird angezeigt, 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 bereitgestellt, die Abhängigkeiten über Arbeitsaufgaben hinweg anzuzeigen. Sie können die Abhängigkeitslinien nacheinander visualisieren. Mit dieser Version haben wir die Benutzererfahrung verbessert, indem wir es ermöglicht haben, dass alle Abhängigkeitslinien über alle Arbeitsaufgaben auf dem Bildschirm angezeigt werden können. Klicken Sie einfach auf die Umschaltfläche "Abhängigkeiten" oben rechts im Lieferplan. Klicken Sie erneut darauf, um die Linien zu deaktivieren.

Überarbeitungsbeschränkungen für neue Arbeitselemente

In den letzten Jahren haben wir Projektsammlungen mit automatisierten Tools gesehen, die Zehntausende von Überarbeitungen von Arbeitsaufgaben generieren. Dadurch werden Probleme mit Leistung und Benutzerfreundlichkeit im Arbeitselementformular und den REST-APIs für die Berichterstellung verursacht. Um das Problem zu beheben, haben wir eine Überarbeitungsgrenze von 10.000 Arbeitsaufgaben für den Azure DevOps-Dienst implementiert. Der Grenzwert wirkt sich nur auf Updates mit der REST-API aus, nicht auf das Arbeitsaufgabenformular.

Klicken Sie hier , um mehr über das Revisionslimit und die Handhabung in Ihren automatisierten Tools zu erfahren.

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

Mit Übermittlungsplänen können Sie mehrere Backlogs und mehrere Teams in Ihrer Projektsammlung anzeigen. Zuvor konnten Sie 15 Team-Backlogs anzeigen, einschließlich einer Mischung aus Backlogs und Teams aus verschiedenen Projekten. Mit dieser Version haben wir die Höchstgrenze von 15 auf 20 erhöht.

Fehler beim Melden der Arbeitselementlinks in der Get-API behoben

Wir haben einen Fehler in der API "Berichtsarbeitselementverknüpfungen abrufen" behoben, um den richtigen remoteUrl-Wert für System.LinkTypes.Remote.Related Verknüpfungstypen zurückzugeben. Vor diesem Fix haben wir den falschen Projektsammlungsnamen und eine fehlende Projekt-ID zurückgegeben.

Erstellen eines temporären REST-Abfrageendpunkts

Wir haben mehrere Fälle beobachtet, in denen Erweiterungsautoren versucht haben, nicht gespeicherte Abfragen auszuführen, indem sie die WIQL-Anweisung (Work Item Query Language) über den Query-String übergeben. Dies funktioniert einwandfrei, es sei denn, Sie haben eine große WIQL-Anweisung, die die Browsergrenzwerte für die Länge der Abfragezeichenfolge erreicht. Um dies zu lösen, haben wir einen neuen REST-Endpunkt erstellt, damit Toolautoren eine temporäre Abfrage generieren können. Wenn Sie die ID aus der Antwort verwenden, um sie per Abfragezeichenfolge zu übergeben, wird dieses Problem beseitigt.

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

API zum Löschen im Batch

Derzeit ist die einzige Möglichkeit, Arbeitselemente aus dem Papierkorb zu entfernen, die Verwendung dieser REST-API zum Löschen jeweils eines Elements. Dies kann ein langsamer Prozess sein und unterliegt einer Drosselung, wenn versucht wird, jegliche Art von Massenbereinigung durchzuführen. Als Reaktion darauf haben wir einen neuen REST-API-Endpunkt hinzugefügt, um Arbeitsaufgaben 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.

Kartenänderungslogik in Übermittlungsplänen

Nicht jeder verwendet das Zieldatum und/oder das Startdatum, wenn Features und Epics nachverfolgt werden. Einige wählen eine Kombination aus Datumsangaben und Iterationspfad. In dieser Version wurde die Logik verbessert, um die Iterationspfad- und Datumsfeldkombinationen entsprechend festzulegen, je nachdem, wie sie verwendet werden.

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

Verbesserungen bei Batchaktualisierungen

Wir haben mehrere Änderungen an der Version 7.1 der Batch-Aktualisierungs-API für Arbeitselemente vorgenommen. Dazu gehören geringfügige Leistungsverbesserungen und die Behandlung teilweiser Fehler. Wenn ein Patch fehlschlägt, die anderen jedoch nicht, werden die anderen erfolgreich abgeschlossen.

Klicken Sie hier , um mehr über die REST-API zum Batchupdate zu erfahren.

API zum Löschen im Batch

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

Verhindern Sie die Bearbeitung von teilbaren Auswahllistenfeldern

Benutzerdefinierte Felder werden über Prozesse hinweg freigegeben. Dies kann ein Problem für Auswahllistenfelder erstellen, da wir es Administratoren ermöglichen, Werte aus dem Feld hinzuzufügen oder daraus zu entfernen. Dabei wirken sich die Änderungen auf dieses Feld für jeden Prozess aus, der es verwendet.

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

Neue Berechtigung zum Speichern von Kommentaren

Die Möglichkeit, nur Kommentare zu Arbeitsaufgaben zu speichern, war eine oberste Anforderung in der Entwicklercommunity. Wir freuen uns, Ihnen mitzuteilen, dass wir dieses Feature implementiert haben. Sehen wir uns zunächst das am häufigsten verwendete Szenario an:

"Ich möchte verhindern, dass einige Benutzer Arbeitsaufgabenfelder bearbeiten, aber zulassen, dass sie zur Diskussion beitragen."

Um dies zu erreichen, müssen Sie zu Project Settings > Project Configuration > Area Path wechseln. Wählen Sie dann den Bereichspfad aus, und klicken Sie auf "Sicherheit".

Beachten Sie die neue Berechtigung "Kommentare zu Arbeitsaufgaben in diesem Knoten bearbeiten". Standardmäßig ist die Berechtigung auf "Nicht festgelegt" festgelegt. Das heißt, die Arbeitsaufgabe verhält sich genau wie zuvor. Um einer Gruppe oder Benutzern das Speichern von Kommentaren zu ermöglichen, wählen Sie diese Gruppe/Benutzer aus, und ändern Sie die Berechtigung auf "Zulassen".

Wenn der Benutzer das Arbeitsaufgabenformular 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 lassen Sie uns wissen, wenn Sie Feedback oder Vorschläge haben.

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 das ältere kumulative Flussdiagramm, Geschwindigkeits- und Sprint-Burndown-Diagramm. Mit dieser Version machen wir sie verfügbar.

Um diese Diagramme anzuzeigen, klicken Sie auf die Registerkarte " Analyse " auf den Seiten Kanban Board, Backlog und Sprints.

Repos

Entfernen der Berechtigung „Richtlinien bearbeiten“ für den Branchersteller

Früher, wenn Sie einen neuen Zweig erstellt haben, wurden Ihnen die Berechtigungen zum Bearbeiten von Richtlinien für diesen Zweig erteilt. Mit diesem Update ändern wir das Standardverhalten, um diese Berechtigung nicht zu erteilen, auch 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.

Rohrleitungen

Aktueller Projektsatz als Standardbereich für Buildzugriffstoken in klassischen Pipelines

Azure Pipelines verwendet zur Laufzeit Auftragszugriffstoken, um auf andere Ressourcen in Azure DevOps zuzugreifen. Ein Auftragszugriffstoken ist ein Sicherheitstoken, das dynamisch von Azure Pipelines für jeden Auftrag zur Laufzeit 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 das aktuelle Projekt als Standard fest, wenn eine neue klassische Pipeline erstellt wird.

Weitere Informationen zu Zugriffstoken für Aufträge finden Sie in den Dokumentationen zu Zugriff auf Repositorys, Artefakte und andere Ressourcen.

Änderung des Standardumfangs von Zugriffstoken in klassischen Build-Pipelines

Um die Sicherheit klassischer Buildpipelines zu verbessern, lautet der Autorisierungsbereich des Buildauftrags standardmäßig Project. Bisher war es project Collection. Weitere Informationen zu Jobzugriffstoken. Diese Änderung wirkt sich nicht auf eine der vorhandenen Pipelines aus. Es betrifft nur neue klassische Build-Pipelines, die Sie ab jetzt erstellen.

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

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

Weitere Informationen finden Sie in der Dokumentation zur Integration in serviceNow Change Management.

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

Azure Pipelines integrieren sich mit lokalen GitHub Enterprise-Servern, um kontinuierliche Integrations- und PR-Builds auszuführen. In einigen Fällen liegt der GitHub Enterprise Server hinter einer Firewall und erfordert, dass der Datenverkehr über einen Proxyserver weitergeleitet wird. Um dieses Szenario zu unterstützen, 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 Verzweigungen
• Abrufen von Pull-Request-Informationen
• Buildstatus melden

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

Sie können eine vom System zugewiesene verwaltete Identität verwenden, wenn Sie Docker Registry-Dienstverbindungen für Azure Container Registry erstellen. Auf diese Weise können Sie mithilfe einer verwalteten Identität, die einem selbst gehosteten Azure Pipelines-Agent zugeordnet ist, auf die Azure-Containerregistrierung zugreifen, sodass keine Anmeldeinformationen mehr verwaltet werden müssen.

Hinweis

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

Automatische Token, die für Kubernetes-Dienstverbindung erstellt wurden

Seit Kubernetes 1.24 wurden Token beim Erstellen einer neuen Kubernetes-Dienstverbindung nicht mehr automatisch erstellt. Wir haben diese Funktionalität wieder hinzugefügt. Es wird jedoch empfohlen, die Azure Service-Verbindung beim Zugriff auf AKS zu verwenden, um mehr über die Dienstverbindungsanleitung für AKS-Kunden zu erfahren, die Kubernetes-Aufgabenblogbeitrag 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. Auf diese Weise können Sie azure Kubernetes Service (AKS) als Ziel festlegen, das mit der Azure Active Directory-Integration konfiguriert ist.

Kubelogin ist nicht auf gehosteten Images vorinstalliert. Um sicherzustellen, dass oben erwähnte Aufgaben kubelogin verwenden, installieren Sie sie, indem Sie den KubeloginInstaller@0 Vorgang vor dem vorgang 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 Erfahrung beim Verwalten von Pipelineberechtigungen verbessert, um das Berechtigungssystem daran zu erinnern, ob eine Pipeline zuvor eine geschützte Ressource verwendet hatte, z. B. eine Dienstverbindung.

Wenn Sie bei der Erstellung einer geschützten Ressource die Option "Zugriffsberechtigung für alle Pipelines erteilen" deaktiviert haben, aber dann 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 behoben.

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

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

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

• Aktualisieren eines GenehmigungsbereichsPipeline Resources Use
• Verwalten von Prüfungen unterstützt den Bereich Pipeline Resources Use and Manage
• Aktualisieren von Pipelineberechtigungen für Ressourcen unterstützt den Bereich Pipeline Resources Use and Manage
• Autorisieren von Definitionsressourcen unterstützt den Bereich Pipeline Resources Use and Manage
• Autorisieren von Project-Ressourcen unterstützt den Bereich 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 ihre Fähigkeit zum sicheren Erstellen und Bereitstellen Ihrer Anwendungen von entscheidender Bedeutung sind, erfordert Azure Pipelines jetzt die Rolle des Ressourcentypadministrators beim Öffnen des Zugriffs auf eine Ressource für alle Pipelines.

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

Darüber hinaus ist beim Erstellen einer Dienstverbindung, und Sie verfügen nicht über ausreichende Rechte, die Berechtigung zum Erteilen der Zugriffsberechtigung für alle Pipelines ist deaktiviert.

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

Verbesserungen der Sicherheit der Pipelines-REST-API

Der Großteil der REST-APIs in Azure DevOps verwenden bereichsbezogene PAT-Token. Einige von ihnen erfordern jedoch voll bereichsbezogene PAT-Token. Mit anderen Worten, Sie müssten ein PAT-Token erstellen, indem Sie "Vollzugriff" auswählen, um einige dieser APIs zu verwenden. 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 entfernen, indem wir jede REST-API in einen bestimmten Bereich integrieren. Im Rahmen dieses Aufwands 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

Um Berechtigungen für Pipelines in großen Mengen zu bearbeiten, benötigen Sie weiterhin ein vollständiges PAT-Token. Weitere Informationen zum Aktualisieren von Pipelineberechtigungen für Ressourcen finden Sie in der Dokumentation zu Pipelineberechtigungen – Aktualisieren von Pipelineberechtigungen für Ressourcen .

Detaillierte Zugriffsverwaltung für Agenten-Pools

Agenten-Pools bieten Ihnen die Möglichkeit, die Maschinen, auf denen Ihre Pipelines ausgeführt werden, festzulegen und zu verwalten.

Wenn Sie bisher einen angepassten Agenten-Pool verwendet haben, war die Verwaltung der Pipelines, die darauf zugreifen können, grob abgestuft. Sie können zulassen, dass alle Pipelines sie verwenden, oder Sie können verlangen, dass jede Pipeline um Erlaubnis bittet. Wenn Sie einem Agentpool eine Pipelinezugriffsberechtigung erteilt haben, konnten Sie sie leider nicht mithilfe der Pipeline-UI widerrufen.

Azure Pipelines bietet jetzt eine differenzierte Zugriffsverwaltung für Agentpools. Die Erfahrung ist ähnlich wie bei der Verwaltung von Pipeline-Berechtigungen für Dienstverbindungen.

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

Wenn Sie eine geschützte Ressource wie z. B. eine Dienstverbindung oder eine Umgebung erstellen, haben Sie die Möglichkeit, das Kontrollkästchen Zugriffsberechtigung für alle Pipelines gewähren zu aktivieren. Bisher wurde diese Option standardmäßig ausgewählt.

Dies erleichtert den Pipelines zwar die Nutzung neuer geschützter Ressourcen, begünstigt aber im Umkehrschluss, dass versehentlich zu vielen Pipelines das Recht auf Zugriff auf die Ressource gewährt wird.

Um eine sichere Standardauswahl zu fördern, lässt Azure DevOps das Kontrollkästchen jetzt nicht mehr aktiviert.

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

Azure Pipelines maskiert geheime Schlüssel in Protokollen. Geheime Schlüssel können Variablen sein, die als geheim gekennzeichnet sind, Variablen aus variablen Gruppen, die mit Azure Key Vault oder Elementen einer Dienstverbindung verknüpft sind, die vom Dienstverbindungsanbieter als geheim gekennzeichnet sind.

Alle Vorkommen von geheimen Werten werden maskiert. Das Maskieren von kurzen Geheimnissen z. B. '1', 'Dev2' macht es einfach, ihre Werte z.B. in einem Datum zu erraten: 'Jan 3, 202***'
Es ist jetzt klar "3" ist ein Geheimnis. In solchen Fällen möchten Sie das Geheimnis möglicherweise nicht vollständig maskieren. Wenn es nicht möglich ist, den Wert nicht als geheim zu kennzeichnen (z. B. der Wert wird aus dem Key Vault entnommen), können Sie den AZP_IGNORE_SECRETS_SHORTER_THAN Knopf auf einen Wert von bis zu 4 festlegen.

Node Runner-Download-Aufgabe

Wenn Sie Agent-Releases einführen, die den Node 6-Aufgabenläufer ausschließen, müssen Sie möglicherweise gelegentlich Aufgaben ausführen, die nicht aktualisiert wurden, um einen neueren Node-Läufer zu verwenden. Für dieses Szenario stellen wir eine Methode bereit, um Aufgaben, die von Node End-of-Life-Läufern abhängig sind, weiterhin zu verwenden, finden Sie im Blogbeitrag "Node runner guidance".

Die folgende Aufgabe ist eine Methode zum Installieren des Knoten 6-Läufers just-in-time, sodass eine alte Aufgabe weiterhin ausgeführt werden kann:

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

Überprüfung des TFX-Knoten-Runners aktualisiert

Aufgabenautoren verwenden das Erweiterungspakettool (TFX), um Erweiterungen zu veröffentlichen. TFX wurde aktualisiert, um Überprüfungen für Node-Runner-Versionen durchzuführen, siehe Node runner Guidance Blogbeitrag.

Erweiterungen, die Aufgaben mit dem Node 6-Läufer enthalten, sehen diese Warnung:

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 Node 6 für Pipeline-Agents

Wenn Sie den pipeline- Agentfeed verwenden, ist Node 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 jetzt Änderungen an Pipeline-Aufgaben in diesem Änderungsprotokoll. Dies ist die vollständige Liste der Änderungen, die an integrierten Pipeline-Aufgaben vorgenommen wurden. Wir haben frühere Änderungen rückwirkend veröffentlicht, sodass das Änderungsprotokoll einen verlaufsbezogenen Datensatz der Taskaktualisierungen bereitstellt.

Freigabeaufgaben verwenden die Microsoft Graph-API

Wir haben unsere Releaseaufgaben aktualisiert und verwenden jetzt die Microsoft Graph-API. Dadurch wird die Verwendung der AAD Graph-API aus unseren Aufgaben entfernt.

Leistungsverbesserung von Windows PowerShell-Aufgaben

Mithilfe von Aufgaben können Sie die Automatisierung in einer Pipeline definieren. Eine dieser Aufgaben ist die PowerShell@2 Hilfsaufgabe, mit der Sie ein PowerShell-Skript in Ihrer Pipeline ausführen können. Um ein PowerShell-Skript für eine Azure-Umgebung zu verwenden, können Sie die AzurePowerShell@5 Aufgabe verwenden. Einige PowerShell-Befehle, mit denen Statusaktualisierungen gedruckt werden können, werden Invoke-WebRequestjetzt 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- und AzurePowerShell@5-Aufgaben 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 Laufzeit zu verwenden. Dies führt native Unterstützung für Apple Silicon sowie Windows Arm64 ein.

Die Verwendung von .NET 6 wirkt sich auf systemanforderungen für den Agent aus. Insbesondere setzen wir die Unterstützung für die folgenden Betriebssysteme ab: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Weitere Informationen finden Sie in der Dokumentation der Agent-Software, Version 3.

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

Wichtig

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

Angeben der Agentversion in der Agent-VM-Erweiterung

Azure-VM-Computer können in Bereitstellungsgruppen mit einer VM-Erweiterung eingeschlossen werden. Die VM-Erweiterung wurde aktualisiert, um optional die gewünschte Agentversion anzugeben, die installiert werden soll:

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

Neue Umschaltfläche zum Steuern der Erstellung klassischer Pipelines

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

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

Sie können die Erstellung von klassischen Pipelines auf Projektsammlungsebene oder Projektebene deaktivieren, indem Sie die entsprechenden Umschaltfläche aktivieren. Die Umschaltflächen finden Sie unter Project / Project Settings - Pipelines -> Einstellungen. Es gibt zwei Umschaltfläche: eine für klassische Buildpipelinen und eine für klassische Releasepipelinen , Bereitstellungsgruppen und Aufgabengruppen.

Der Umschaltstatus ist standardmäßig deaktiviert, und Sie benötigen Administratorrechte, um den Status zu ändern. Wenn der Schalter auf Organisationsebene aktiviert ist, gilt die Deaktivierung für alle Projekte. Ansonsten ist es jedem Projekt freigestellt, ob es die Deaktivierung erzwingen möchte oder nicht.

Wenn das Deaktivieren der Erstellung klassischer Pipelines erzwungen wird, werden REST-APIs im Zusammenhang mit der Erstellung klassischer Pipelines, Aufgabengruppen und Bereitstellungsgruppen fehlschlagen. REST-APIs, mit denen YAML-Pipelines erstellt werden, funktionieren.

Updates für das Dienst-Hook-Ereignis „Ausführungsphasenstatus geändert”

Mit Service Hooks können Sie Aufgaben in anderen Diensten ausführen, wenn Ereignisse in Ihrem Azure DevOps-Projekt auftreten. Der Status der Ausführungsphase ist eines dieser Ereignisse. Das Ereignis "Status der Ausführungsphase geändert" muss Informationen über die Ausführung enthalten, einschließlich des Namens der Pipeline. Zuvor wurden nur Informationen zur ID und zum Namen des Laufs enthalten. Mit diesem Update haben wir Änderungen am Ereignis vorgenommen, um fehlende Informationen einzuschließen.

Deaktivieren der Anzeige der letzten Commit-Nachricht für eine Pipeline-Ausführung

Zuvor wurde die Pipelines-Benutzeroberfläche verwendet, um die letzte Commitmeldung anzuzeigen, wenn die Ausführung einer Pipeline angezeigt wird.

Diese Meldung kann zum Beispiel verwirrend sein, wenn sich der Code Ihrer YAML-Pipeline in einem anderen Repository befindet als dem, in dem sich der Build-Code befindet. Wir haben Ihr Feedback aus der Entwicklercommunity gehört, in dem Sie uns um eine Möglichkeit gebeten haben, das Anfügen der neuesten Commit-Nachricht an den Titel jeder Pipeline-Ausführung zu aktivieren oder zu deaktivieren.

Mit diesem Update haben wir eine neue YAML-Eigenschaft namens appendCommitMessageToRunNamehinzugefügt, mit der Sie genau das tun können. Standardmäßig ist die Eigenschaft auf true gesetzt. Wenn Sie ihn auf .

Die Grenzen für Azure-Pipelines wurden erhöht, um sie an die maximale Größe von 4 MB für Azure Resource Manager (ARM)-Vorlagen anzupassen.

Sie können die Azure Resource Manager-Vorlagenbereitstellungsaufgabe zum Erstellen der Azure-Infrastruktur verwenden. Als Reaktion auf Ihr Feedback haben wir die Integrationsgrenze von Azure Pipelines von 2 MB auf 4 MB erhöht. Dies wird mit der maximalen Größe von 4 MB der ARM-Vorlagen übereinstimmen und dadurch die Größenbeschränkungen bei der Integration großer Vorlagen auflösen.

Symbol "Übersicht" für die Pipelineausführung status

Mit dieser Version machen wir es einfacher, den Gesamtstatus einer Pipelineausführung zu kennen.

Für YAML-Pipelines mit vielen Stufen war es schwierig, den Status eines Pipeline-Durchlaufs zu erfahren, d. h., ob er noch läuft oder bereits beendet ist. Und wenn sie abgeschlossen ist, was der Gesamtzustand ist: erfolgreich, fehlgeschlagen oder abgebrochen. Dieses Problem wurde behoben, indem ein Übersichtssymbol für den Ausführungsstatus hinzugefügt wurde.

Seitenbereich „Pipeline-Stufen“

YAML-Pipelines können zehn Phasen aufweisen, und nicht alle davon passen auf Ihren Bildschirm. Das Status-Icon des Pipeline-Runs informiert Sie zwar über den Gesamtzustand des Laufs, aber es ist nach wie vor schwierig zu wissen, welche Stufe fehlgeschlagen ist oder welche noch läuft.

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

Suchen nach Bühnen im Seitenpanel

Wir haben es einfacher gemacht, die Stufen zu finden, die Sie in der Seitenleiste suchen. Sie können jetzt schnell nach Phasen filtern, die auf ihrem Status basieren, z. B. nach Ausführungsphasen oder nach Stufen, die manuell eingreifen müssen. Sie können auch nach Stufen nach ihrem Namen suchen.

Phasenschnellaktionen

Der Bildschirm Läufe einer Pipeline bietet Ihnen schnellen Zugriff auf alle Phasen. 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 problemlos erneut ausführen oder die gesamte Phase erneut ausführen. Das Panel ist verfügbar, wenn nicht alle Phasen in die Benutzeroberfläche passen, wie Sie im folgenden Screenshot sehen können.

Wenn Sie auf die Spalte "+" klicken, wird der Stufenbereich angezeigt, und Sie können Phasenaktionen ausführen.

Überprüft Verbesserungen der Benutzererfahrung

Wir erleichtern das Lesen von Prüfprotokollen. Überprüfungsprotokolle stellen Informationen bereit, die für den Erfolg Ihrer Bereitstellung wichtig sind. Sie können Ihnen mitteilen, ob Sie vergessen haben, ein Arbeitsartikelticket zu schließen oder ein Ticket in ServiceNow zu aktualisieren. Es war früher schwierig zu wissen, dass eine Überprüfung solche kritischen Informationen bereitstellt.

Nun zeigt die "Details zur Pipelineausführung"-Seite das neueste Prüfprotokoll an. Dies gilt nur für Überprüfungen, die unserer empfohlenen Nutzung folgen.

Um versehentlich genehmigte Genehmigungen zu verhindern, zeigt Azure DevOps die Anweisungen für genehmigende Personen in der Genehmigungs- und Prüfseite der Detailseite einer Pipelineausführung an.

Deaktivieren einer Prüfung

Wir haben die Debugging-Checks weniger mühsam gemacht. Manchmal funktioniert eine Aufruf-Azure-Funktion oder die REST-API-Überprüfung nicht ordnungsgemäß, und Sie müssen sie beheben. Zuvor mussten Sie solche Überprüfungen löschen, um zu verhindern, dass sie eine Bereitstellung versehentlich blockieren. Nachdem Sie die Prüfung behoben haben, mussten Sie sie wieder hinzufügen und richtig konfigurieren, um sicherzustellen, dass alle erforderlichen Header festgelegt sind 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 Überprüfungssuite-Auswertungen nicht ausgeführt.

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

wird

Verbrauchte Ressourcen und Vorlagenparameter in der REST-API für Pipelineausführungen

Die erweiterte Pipelines Runs REST-API gibt jetzt mehr 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 erweitert, um die Vorlagenparameter pipeline zurückzugeben, die container in einer Pipelineausführung verwendet werden. Sie können jetzt z. B. Complianceprüfungen schreiben, die die Repositorys, Container und andere Pipelineausführungen auswerten, die von einer Pipeline verwendet werden.

Hier ist 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 für allgemeine Verfügbarkeitsvorlagen im YAML-Editor

Vorlagen sind ein häufig verwendetes Feature in YAML-Pipelines. Sie sind eine einfache Möglichkeit, Pipelineausschnitte zu teilen. 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 unterstützt jedoch noch keine Vorlagen. Autoren von YAML-Pipelines konnten beim Verwenden einer Vorlage keine Unterstützung durch IntelliSense erhalten. Vorlagenautoren konnten den YAML-Editor nicht verwenden. In dieser Version fügen wir Unterstützung für Vorlagen im YAML-Editor hinzu.

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 auswählen, ob Sie zu der Vorlage navigieren möchten. Mit allen Features des YAML-Editors können Sie Änderungen an der Vorlage vornehmen.

Es gibt bekannte Einschränkungen:

• Wenn die Vorlage über erforderliche Parameter verfügt, die nicht als Eingaben in der Haupt-YAML-Datei bereitgestellt werden, schlägt die Überprüfung fehl und fordert Sie auf, diese Eingaben bereitzustellen. In einer idealen Erfahrung 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 aus dem Editor erstellen. Sie können nur vorhandene Vorlagen verwenden oder bearbeiten.

Neue vordefinierte Systemvariable

Wir haben eine neue vordefinierte Systemvariable namens Build.DefinitionFolderPath eingeführt, deren Wert der Ordnerpfad einer Buildpipeline-Definition ist. Die Variable ist sowohl in YAML- als auch in klassischen Buildpipelinen verfügbar.

Wenn Ihre Pipeline beispielsweise unter dem FabrikamFiber\Chat-Ordner in Azure Pipelines gespeichert ist, lautet der Wert von Build.DefinitionFolderPathFabrikamFiber\Chat.

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

YAML-Pipelines bieten Ihnen bequeme Möglichkeiten, Code-Vervielfältigung zu reduzieren, wie etwa das Durchlaufen each eines Listenwerts oder einer Objekt-Eigenschaft.

Manchmal wird der Satz von Elementen, die durchlaufen werden sollen, als Zeichenfolge dargestellt. Beispiel: Wenn die Liste der bereitzustellenden Umgebungen durch die Zeichenfolge integration1, integration2definiert wird.

Während wir Ihr Feedback aus der Entwicklercommunity hören, haben wir gehört, dass Sie eine Zeichenfolgenfunktion split in YAML-Vorlagenausdrücken wollten.

Jetzt können Sie eine Zeichenfolge split durchlaufen und über ihre Teilzeichenfolgen each iterieren.

variables:
  environments: integration1, integration2

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

Vorlagen-Ausdrücke in der Definition von Repository-Ressourcen

Wir haben Unterstützung für Vorlagenausdrücke beim Definieren der ref Eigenschaft einer repository Ressource in einer YAML-Pipeline hinzugefügt. Dies war ein sehr angefordertes Feature unserer Entwicklercommunity.

Es gibt Anwendungsfälle, wenn Ihre Pipeline unterschiedliche Verzweigungen derselben Repositoryressource auschecken soll.

Angenommen, Sie haben eine Pipeline, die ein eigenes Repository erstellt, und dafür muss sie eine Bibliothek aus einem Ressourcen-Repository auschecken. Außerdem möchten Sie, dass Ihre Pipeline denselben Bibliothekszweig auscheckt, den sie selbst verwendet. Beispielsweise sollte die Pipeline, wenn sie auf der main Branch ausgeführt wird, die main Branch des Bibliotheksrepositorys auschecken. Wenn die Pipelines auf dem dev Branch ausgeführt werden, sollten sie den dev Bibliothekszweig auschecken.

Bis heute mussten Sie die zu auscheckende Verzweigung explizit angeben und den Pipelinecode ändern, wenn sich die Verzweigung ändert.

Jetzt können Sie Vorlagenausdrücke verwenden, um den Zweig einer Repositoryressource auszuwählen. Sehen Sie sich das folgende Beispiel von YAML-Code an, der für die nicht wichtigsten Zweigstellen 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 die Verzweigung angeben, die für das library Repository ausgecheckt werden soll.

Geben Sie die Version einer Vorlage an, die zur Bauzeit der Warteschlange erweitert werden soll.

Vorlagen stellen eine hervorragende Möglichkeit dar, die Codeduplizierung zu reduzieren unddie Sicherheit Ihrer Pipelines zu verbessern.

Ein beliebter Anwendungsfall besteht darin, Vorlagen in ihrem eigenen Repository zu speichern. Dies reduziert die Kopplung zwischen einer Vorlage und den Pipelines, die sie erweitern, und erleichtert die Entwicklung der Vorlage und der Pipelines unabhängig voneinander.

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 haben 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 wird. Dies bedeutete, dass Sie den Code der Pipeline ändern mussten, wenn Sie Ihre Pipeline dazu bringen wollten, eine Vorlage aus einer anderen Verzweigung oder aus derselben Verzweigung, je nach dem Namen Ihrer Pipeline, einzubinden, unabhängig davon, auf welcher Verzweigung 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

Auf diese Weise erweitert Ihre Pipeline die Vorlage in derselben Verzweigung wie die Verzweigung, auf der die Pipeline ausgeführt wird, sodass Sie sicherstellen können, dass die Verzweigungen ihrer Pipeline und der Vorlage immer übereinstimmen. Wenn Sie Ihre Pipeline auf einem Branch dev ausführen, erweitert sich die Vorlage, die durch die Datei template.yml im Branch dev des templates Repositories angegeben wird.

Alternativ können Sie beim Erstellen der Warteschlangenzeit auswählen, welche Vorlagenrepository-Verzweigung 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 die Pipeline auf Verzweigung main erweitern eine Vorlage von Verzweigung dev in einer Ausführung erweitern und eine Vorlage aus Verzweigung main in einer anderen Ausführung erweitern, ohne den Code der Pipeline zu ändern.

Wenn Sie einen Vorlagenausdruck für die Eigenschaft ref einer Repository-Ressource angeben, können Sie vordefinierte Variablen und systeminterne Variablen parameters verwenden, aber keine YAML- oder Pipelines-UI-definierten Variablen.

Vorlagenausdrücke in der Containerressourcendefinition

Wir haben Unterstützung für Vorlagenausdrücke beim Definieren der Eigenschaften endpoint, volumes, ports und options einer Ressource in einer container YAML-Pipeline hinzugefügt. Dies war ein sehr angefordertes Feature unserer Entwicklercommunity.

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 parameters. und variables. in Ihren Vorlagenausdrücken verwenden. Für Variablen können Sie nur die in der YAML-Datei definierten, aber nicht die in der Pipelines-Benutzeroberfläche definierten verwenden. Wenn Sie die Variable z. B. mithilfe von Agentprotokollbefehlen neu definieren, hat sie keine Auswirkung.

Verbesserungen geplanter Builds

Wir haben ein Problem behoben, das dazu führte, dass die Zeitplaninformationen einer Pipeline beschädigt wurden und die Pipeline nicht geladen werden konnte. Dies wurde beispielsweise ausgelöst, wenn der Name der Verzweigung eine bestimmte Anzahl von Zeichen überschritten hat.

Verbesserte Fehlermeldung, wenn das Laden von Pipelines fehlschlägt

Azure Pipelines bietet mehrere Arten von Triggern, um zu konfigurieren, wie Ihre Pipeline gestartet wird. Eine Möglichkeit zum Ausführen einer Pipeline ist die Verwendung geplanter Auslöser. Manchmal werden die Informationen zur geplanten Ausführung einer Pipeline beschädigt und können dazu führen, dass eine Last fehlschlägt. Zuvor wurde eine irreführende Fehlermeldung angezeigt, die behauptete, dass die Pipeline nicht gefunden wurde. Mit diesem Update haben wir dieses Problem behoben und eine informative Fehlermeldung zurückgegeben. Wenn eine Pipeline nicht geladen werden kann, erhalten Sie in Zukunft eine Nachricht ähnlich wie folgt: Die Zeitplandaten des Builds sind beschädigt.

Tags beim Abrufen eines Git-Repositorys nicht synchronisieren

Die Auscheckaufgabe verwendet --tags die Option zum Abrufen des Inhalts eines Git-Repositorys. Dadurch ruft der Server alle Tags sowie alle Objekte ab, 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 Auscheckprozess Tags, selbst wenn Sie die Option für den flachen Abruf aktivieren, und damit möglicherweise ihren Zweck verfehlt. Um die Datenmenge zu reduzieren, die aus einem Git-Repository abgerufen oder abgerufen wurde, haben wir der Aufgabe nun eine neue Option hinzugefügt, um das Verhalten der Synchronisierungstags 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 den Tag fetchTags: false zum Checkout-Schritt hinzu. Wenn die fetchTags Option nicht angegeben wird, ist sie identisch mit der Verwendung fetchTags: true .

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 in 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 "Trigger" und 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

Möchten Sie die Synchronisierung der Tags verhindern, entfernen Sie das Häkchen im Kontrollkästchen "Tags synchronisieren" im Schritt "Quellen abrufen".

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

Artefakte

Aktualisierte Standardfeedberechtigungen

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

Neue Benutzeroberfläche für die Upstream-Paketsuche

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

Azure Artifacts bieten jetzt eine Benutzeroberfläche, über die Sie nach Paketen in Ihren Upstreamquellen suchen und Paketversionen in Ihrem Feed speichern können. Dies entspricht dem Ziel von Microsoft, unsere Produkte und Dienste zu verbessern.

Berichterstattung

Anzeigen des übergeordneten Elements im Abfrageergebnis-Widget

Das Abfrageergebnisse-Widget unterstützt jetzt den Namen des übergeordneten Objekts und einen direkten Link zu diesem übergeordneten Objekt.

Dashboard kopieren

Mit dieser Version beziehen wir das Kopierdashboard ein.

Dashboards, zuletzt zugegriffen am und geändert von

Eine der Herausforderungen, teams das Erstellen mehrerer Dashboards zu ermöglichen, ist die Verwaltung und Bereinigung der veralteten und nicht verwendeten. Das Wissen, wann ein Dashboard zuletzt besucht oder geändert wurde, ist ein wichtiger Bestandteil, um zu verstehen, welche elemente entfernt werden können. In dieser Version haben wir zwei neue Spalten auf die Dashboard-Verzeichnisseite aufgenommen. Das Datum des letzten Zugriffs verfolgt, wann das Dashboard zuletzt besucht wurde. Geändert von verfolgt, wann das Dashboard zuletzt bearbeitet wurde und von wem.

Die Informationen "Geändert von" werden auch auf der Dashboardseite selbst angezeigt.

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

Analyseansichten sind jetzt verfügbar

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

In der Navigation wurden 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 einige Dokumentationen, die Sie auf den neuesten Stand bringen:

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

Das Pull Request-Widget für mehrere Repositories ist jetzt verfügbar.

Wir freuen uns, ihnen mitzuteilen, 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 mühelos Pull-Anfragen von bis zu 10 verschiedenen Repositories in einer einzigen, übersichtlichen Liste anzeigen, wodurch es einfacher denn je ist, den Überblick über Ihre Pull-Anfragen zu behalten.

Community-Vorschlagsticket

Einführung von „gelöst“ als „abgeschlossen“ in Burndown- und Burnup-Diagrammen

Wir wissen, wie wichtig es ist, den Teamfortschritt genau darzustellen, einschließlich der Erfassung abgeschlossener Elemente in den Diagrammen. Mit einer einfachen Umschaltoption können Sie jetzt festlegen, dass aufgelöste Elemente als abgeschlossen angezeigt werden, was eine echte Abbildung des Burndown-Status des Teams darstellt. Diese Erweiterung ermöglicht eine genauere Nachverfolgung und Planung, sodass Teams fundierte Entscheidungen basierend auf dem tatsächlichen Fortschritt treffen können. Erfahren Sie verbesserte Transparenz sowie bessere Einblicke mit den aktualisierten Burndown- und Burnup-Diagrammen in der Berichterstattung.

Wiki

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

Wir haben die Version der in Wiki-Seiten verwendeten mermaid-Diagramme auf 8.13.9 aktualisiert. Mit diesem Upgrade können Sie jetzt die folgenden Diagramme und Visualisierungen in Ihre Azure DevOps-Wiki-Seiten einschließen:

• Flussdiagramm
• Sequenzdiagramme
• Gantt-Diagramme
• Kreisdiagramme
• Anforderungsdiagramme
• Zustandsdiagramme
• Nutzerreise

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 Anmerkungen zur Mermaid-Version.

---

Feedback

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

---

Seitenanfang