Versionshinweise zu Azure DevOps Server 2022 Update 1

---

| Entwicklercommunity Systemanforderungen und Kompatibilitätslizenzbedingungen | | 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
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 in Wiki- und Arbeitsaufgaben behoben, bei denen Suchergebnisse für Projekte mit türkischem "I" in ihrem Namen für türkische Gebietsschemas nicht verfügbar waren.

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 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
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A541

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
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 requested for beim Ansetzen 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 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 Entwicklercommunity 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 zur Verwendung des Wagon Resolver Transport. 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 zwingt Maven zur Verwendung des Wagon Resolver Transport. 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 die Upstreameinträge keine Anzeigenamenänderungen behoben haben.
• Unerwarteter Fehler beim Wechseln von Registerkarten von Code zu einer anderen Registerkarte auf der Suchseite.
• 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. Einige der Highlights sind unter anderem:

• 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
• Containerregistrierungsdienstverbindungen können jetzt Azure Managed Identities 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 granulare PAT-Bereiche

Bisher waren eine Reihe öffentlich dokumentierter Azure DevOps-REST-APIs nicht mit Bereichen (z. B. Arbeitsaufgabenlesevorgängen) verknüpft, die kunden, die vollständige Bereiche verwenden, um diese APIs über nicht interaktive Authentifizierungsmechanismen wie persönliche Zugriffstoken (PAT) zu nutzen. 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 jetzt mit einem granularen PAT-Bereich verknüpft und unterstützen. 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 Sie alle Abhängigkeiten über alle Arbeitsaufgaben auf dem Bildschirm anzeigen 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 Arbeitsaufgaben

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.

Teamlimit für Lieferpläne von 15 auf 20 erhöhen

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 von Arbeitsaufgabenverknüpfungs-API

Es wurde ein Fehler in der Api zum Abrufen von Berichtsarbeitselementen 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.

Temporärer REST-Abfrageendpunkt erstellen

Wir haben mehrere Instanzen von Erweiterungsautoren gesehen, die versuchen, nicht gespeicherte Abfragen auszuführen, indem die WIQL-Anweisung (Work Item Query Language) über die Abfragezeichenfolge übergeben wird. 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.

Batchlösch-API

Derzeit wird die einzige Möglichkeit zum Entfernen von Arbeitselementen aus dem Papierkorb diese REST-API zum gleichzeitigen Löschen verwendet. Dies kann ein langsamer Prozess sein und unterliegt der Begrenzung der Rate, wenn versucht wird, jede Art von Massenreinigung zu erledigen. 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 Arbeitsaufgabenbatchaktualisierungs-API 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.

Batchlösch-API

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 der Bearbeitung freigegebener Auswahllistenfelder

Benutzerdefinierte Felder werden prozessübergreifend gemeinsam verwendet. Dies kann zu einem Problem für Picklistfelder 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 für den Sammlungsadministrator hinzugefügt, ein Feld für die Bearbeitung zu "sperren". Wenn das Auswahllistenfeld gesperrt ist, kann der Administrator des lokalen Prozesses die Werte dieser Auswahlliste nicht ändern. Sie können das Feld nur dem Prozess hinzufügen oder daraus entfernen.

Berechtigung zum Neuen 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 "Arbeitsaufgabenkommentare 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 die älteren Diagramme für kumulative Flussdiagramme, Geschwindigkeiten und Sprint-Burndowndiagramme. Mit dieser Version stellen wir sie zur Verfügung.

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

Repos

Entfernen der Berechtigung "Richtlinien bearbeiten" für Zweigstellenersteller

Wenn Sie zuvor eine neue Verzweigung erstellt haben, erhalten Sie die Berechtigung zum Bearbeiten von Richtlinien für diese Verzweigung. 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

Aktueller Projektsatz als Standardbereich für Buildzugriffstoken in klassischen Pipelines

Azure Pipelines verwendet Auftragszugriffstoken für den Zugriff auf andere Ressourcen in Azure DevOps zur Laufzeit. 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 das aktuelle Projekt als Standard fest, wenn eine neue klassische Pipeline erstellt wird.

Weitere Informationen zu Auftragszugriffstoken finden Sie in den Access-Repositorys, Artefakten und anderen Ressourcendokumentationen.

Ändern des Standardumfangs von Zugriffstoken in klassischen Buildpipelinen

Um die Sicherheit klassischer Buildpipelines zu verbessern, lautet der Autorisierungsbereich des Buildauftrags standardmäßig Project. Bisher war es project Collection. Weitere Informationen zu Auftragszugriffstoken. Diese Änderung wirkt sich nicht auf eine der vorhandenen Pipelines aus. Es wirkt sich nur auf neue klassische Buildpipelines aus, die Sie ab diesem Zeitpunkt 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 sind in lokale GitHub Enterprise-Server integriert, um fortlaufende 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 Pullanforderungsinformationen
• Buildstatus melden

Containerregistrierungsdienstverbindungen können jetzt Azure Managed Identities 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. AcrPull- oder AcrPush-Rolle.

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. Dadurch können Sie Azure Kubernetes Service (AKS) als Ziel verwenden, der mit 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 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 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

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

Feinkörnige 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 Agentpool verwendet haben, wurde die Verwaltung, auf welche Pipelines zugegriffen werden kann, grob gekörnt. Sie könnten zulassen, dass alle Pipelines sie verwenden können, oder Sie können jede Pipeline um Erlaubnis bitten. 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 Benutzeroberfläche ähnelt dem Für die Verwaltung von Pipelineberechtigungen für Dienstverbindungen.

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, haben Sie die Möglichkeit, das Kontrollkästchen "Zugriffsberechtigung für alle Pipelines gewähren" auszuwählen. Bisher wurde diese Option standardmäßig aktiviert.

Dies erleichtert zwar die Verwendung neuer geschützter Ressourcen durch Pipelines, umgekehrt ist jedoch der Vorteil, dass versehentlich zu viele Pipelines das Recht auf Zugriff auf die Ressource gewährt werden.

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

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 Dienstverbindungsanbieter als Geheimnis gekennzeichnet sind.

Alle Vorkommen des Geheimniswerts werden maskiert. Das Maskieren kurzer Geheimnisse, z. B. "1", "2", "", "Dev" erleichtert das Erraten ihrer Werte, z. B. in einem Datum: "Jan 3, 202***"
Es ist jetzt klar, dass "3" ein Geheimnis ist. In solchen Fällen ziehen Sie es möglicherweise vor, 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 übernommen), können Sie den AZP_IGNORE_SECRETS_SHORTER_THAN Regler auf einen Wert von bis zu 4 festlegen.

Node Runner-Downloadtask

Bei der Einführung von Agent-Releases, die den Node 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 stellen wir eine Methode bereit, um weiterhin Aufgaben zu verwenden, die von Node End-of-Life-Runnern abhängig sind. Weitere Informationen finden Sie im Blogbeitrag Node Runner-Anleitung.

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-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. Weitere Informationen finden Sie im Blogbeitrag node runner guidance (Anleitungen zu Node-Runnern).

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 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 Ä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.

Freigabeaufgaben verwenden die Microsoft Graph-API

Wir haben unsere Releaseaufgaben aktualisiert, um die Microsoft Graph-API zu verwenden. 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 Hilfsaufgabe, mit der PowerShell@2 Sie PowerShell-Skripts 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 und AzurePowerShell@5 der PowerShell@2 Aufgaben jetzt standardmäßig festgelegtSilentlyContinue.

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 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 Organisation nur YAML-Pipelines verwendet, indem Sie die Erstellung von klassischen Buildpipelines, klassischen Release-Pipelines, Aufgabengruppen 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 Umschaltfläche aktivieren. Die Umschaltfläche finden Sie unter "Project/Project Settings " - Pipelines -> Settings.The toggles can be found in Project / Project Settings -> Pipelines - Settings. 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 die Umschaltfläche auf Organisationsebene aktiviert ist, wird die Deaktivierung für alle Projekte erzwungen. Andernfalls kann jedes Projekt auswählen, ob die Deaktivierung erzwungen werden soll oder nicht.

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

Updates für das Dienst-Hook-Ereignis "Phase geändert ausführen"

Mit Dienst-Hooks können Sie Aufgaben für andere Dienste ausführen, wenn Ereignisse in Ihrem Projekt in Azure DevOps auftreten, der Status " Phase ausführen" 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 über die ID und den Namen der Ausführung enthalten. 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 anzuzeigen, wenn die Ausführung einer Pipeline angezeigt wird.

Diese Meldung kann z. B. verwirrend sein, wenn sich der Code Ihrer YAML-Pipeline in einem Repository befindet, das vom Code abweicht, der den erstellten Code enthält. Wir haben Ihr Feedback von der Entwicklercommunity gehört, die uns um eine Möglichkeit gebeten hat, 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 das tun können. Standardmäßig ist die Eigenschaft auf true eingestellt. Wenn Sie ihn auf falseBuildNumber.

Erhöhte Azure Pipeline-Grenzwerte für die Anpassung an die maximale Größe von 4 MB an azure Resource Manager (ARM).

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. Dadurch wird die maximale Größe von 4 MB an den ARM-Vorlagen angepasst, wobei Größenbeschränkungen bei der Integration großer Vorlagen aufgelöst werden.

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

Mit dieser Version machen wir es einfacher, den Gesamtstatus 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., ob sie noch ausgeführt wird oder abgeschlossen ist. Und wenn der Vorgang abgeschlossen ist, wie lautet der Gesamtzustand: erfolgreich, fehlgeschlagen oder abgebrochen. Dieses Problem wurde behoben, indem sie ein Symbol für die Status-Übersicht hinzugefügt haben.

Leitungsstufen seitlich Bedienfeld

YAML-Pipelines können zehn Phasen aufweisen, und nicht alle davon passen auf Ihren Bildschirm. Das Übersichtssymbol für die Pipelineausführung informiert Sie zwar über den Gesamtzustand Ihrer Ausführung, aber es ist immer noch schwer zu wissen, welche Phase fehlgeschlagen ist oder welche Phase noch ausgeführt wird.

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 Phasen im Seitenbereich

Wir haben es einfacher gemacht, die gewünschten Phasen im Seitenbereich der Phasen zu finden. Sie können jetzt schnell nach Phasen basierend auf ihrem Status filtern, z. B. ausgeführte Phasen oder Phasen, die manuell eingreifen müssen. Sie können auch nach Phasen nach ihrem Namen suchen.

Phasenschnellaktionen

Der Bildschirm "Ausführung" einer Pipeline bietet Ihnen schnellen Zugriff auf alle Ausführungsphasen. 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. Zuvor war die Kenntnis, dass eine Überprüfung, die solche kritischen Informationen bereitgestellt hat, schwierig war.

Nun zeigt die Seite "Details zur Pipelineausführung" 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 Debuggingprüfungen weniger mühsam durchgeführt. 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.

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

Verbrauchte Ressourcen und Vorlagenparameter in pipelines Runs Rest API

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 " eingeführt, Build.DefinitionFolderPathderen Wert der Ordnerpfad einer Buildpipelinedefinition 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 FabrikamFiber\Chatder Wert von Build.DefinitionFolderPath .

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

YAML-Pipelines bieten Ihnen bequeme Möglichkeiten, die Codeduplizierung zu reduzieren, z . B. das Durchlaufen each des Werts einer Liste oder Eigenschaft eines Objekts.

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 von der Entwicklercommunity hören, haben wir gehört, dass Sie eine Zeichenfolgenfunktion split in YAML-Vorlagenausdrücken wollten.

Jetzt 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 Repositoryressourcendefinition

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 wie selbst auscheckt. Wenn Ihre Pipeline beispielsweise auf der main Verzweigung ausgeführt wird, sollte die main Verzweigung des Bibliotheks-Repositorys ausgecheckt werden. Wenn die Pipelines auf der dev Verzweigung ausgeführt werden, sollte 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 Erstellung der Warteschlangenzeit erweitert werden soll.

Vorlagen stellen eine hervorragende Möglichkeit dar, die Codeduplizierung zu reduzieren und die 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 möchten, dass Die Pipeline eine Vorlage aus einer anderen Verzweigung erweitert, unabhängig davon, welche 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 die Pipeline auf einer Verzweigung devausführen, wird die vorlage erweitert, die durch die template.yml Datei im dev Verzweigung des templates Repositorys 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 ref Eigenschaft einer Repositoryressource angeben, können Sie vordefinierte Variablen verwenden und systeminterne Variablen verwenden parameters , sie können jedoch keine benutzerdefinierten VARIABLEN für YAML oder Pipelines verwenden.

Vorlagenausdrücke in der Containerressourcendefinition

Wir haben Unterstützung für Vorlagenausdrücke beim Definieren der endpointEigenschaften options volumesportseiner 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 Ihre Vorlagenausdrücke verwenden parameters. und variables. 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

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 ausgelöst, wenn der Name der Verzweigung eine bestimmte Anzahl von Zeichen überschritten hat.

Verbesserte Fehlermeldung beim Fehler beim Laden 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 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. In Zukunft erhalten Sie die Nachricht ähnlich wie: Buildzeitplandaten sind beschädigt , wenn eine Pipeline nicht geladen werden kann.

Synchronisieren von Tags beim Abrufen eines Git-Repositorys nicht

Die Auscheckaufgabe 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 die Auscheckaufgabe Tags, auch wenn Sie die Option für den flachen Abruf aktivieren, wodurch möglicherweise der Zweck besiegt wird. 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 fetchTags: false Auscheckschritt 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

Wenn Sie die Synchronisierung der Tags deaktivieren möchten, deaktivieren Sie das Kontrollkästchen "Synchronisierungstags" 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.

Artifacts

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.

Reporting

Übergeordnetes Element im Abfrageergebnis-Widget anzeigen

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

Dashboard kopieren

Mit dieser Version beziehen wir das Kopierdashboard ein.

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 die Dashboard-Verzeichnisseite aufgenommen. Datum des letzten Zugriffs wird nachverfolgt, wann das Dashboard zuletzt besucht wurde. Modified By 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 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 ü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 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

Das Pullanforderungs-Widget für mehrere Repositorys 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 Pull Requests aus bis zu 10 verschiedenen Repositorys mühelos in einer einzigen, optimierten Liste anzeigen, sodass Sie ihre Pull Requests leichter denn je im Blick behalten können.

Communityvorschlagsticket

Einführung als abgeschlossen in Burndown- und Burnupdiagrammen

Wir wissen, wie wichtig es ist, den Teamfortschritt genau zu reflektieren, einschließlich aufgelöster Elemente wie in den Diagrammen abgeschlossen. Mit einer einfachen Umschaltoption können Sie jetzt festlegen, dass aufgelöste Elemente als abgeschlossen angezeigt werden, was eine echte Spiegelung des Burndownzustands 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. Erleben Sie verbesserte Transparenz und bessere Erkenntnisse mit den aktualisierten Burndown- und Burnupdiagrammen in Der Berichterstellung.

Wiki

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

Wir haben die Version von Mermaid-Diagrammen aktualisiert, die auf Wiki-Seiten auf 8.13.9 verwendet werden. 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
• 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 Anmerkungen zur Mermaid-Version.

---

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und über Entwicklercommunity nachverfolgen und Ratschläge zu Stack Overflow erhalten.

---

Seitenanfang