Versionshinweise zu Azure DevOps Server 2022

---

| 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 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 0.1 Patch 5 Veröffentlichungsdatum: 14. November 2023

Datei	SHA-256 Hash
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

• Erweiterte Liste der zulässigen PowerShell-Aufgaben für die Parameterüberprüfung von Argumenten zum Aktivieren von Shellaufgabenargumenten.
• Behebung eines Problems, durch das Dienstverbindungen bearbeitet wurden, nachdem sie auf die Schaltfläche "Abbrechen" geklickt haben.

Azure DevOps Server 2022 Update 0.1 Patch 4 Veröffentlichungsdatum: 10. Oktober 2023

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

• Ein Fehler wurde behoben, der dazu führte, dass Pipelines beim Upgrade des Pipelineausführungsmodells hängen geblieben sind.
• Ein Fehler wurde behoben, bei dem die Identität "Analysebesitzer" auf Patchupgradecomputern als Inaktive Identität angezeigt wurde.
• Der Buildbereinigungsauftrag enthält viele Aufgaben, von denen jeder ein Artefakt für einen Build löscht. Wenn eine dieser Vorgänge fehlgeschlagen ist, wurde keines der nachfolgenden Vorgänge ausgeführt. Wir haben dieses Verhalten geändert, um Vorgangsfehler zu ignorieren und so viele Artefakte wie möglich zu bereinigen.

Azure DevOps Server 2022 Update 0.1 Patch 3 Veröffentlichungsdatum: 12. September 2023

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

• CVE-2023-33136; Sicherheitsrisiko bei der Azure DevOps Server-Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server zur Erhöhung von Berechtigungen.

Azure DevOps Server 2022 Update 0.1 Patch 2 Veröffentlichungsdatum: 8. August 2023

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

• CVE-2023-36869: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• Ein Fehler in SOAP-Aufrufen wurde behoben, bei dem ArithmeeticException für die XML-Antwort mit großen Metadaten ausgelöst werden kann.
• Implementierte Änderungen am Dienstverbindungen-Editor, sodass der Endpunktzustand beim Schließen der Komponente geleert wird.
• Es wurde ein Problem behoben, bei dem relative Links nicht in Markdowndateien funktionieren.
• Es wurde ein Leistungsproblem im Zusammenhang mit der Anwendungsebene behoben, das länger als der normale Start dauert, wenn eine große Anzahl von Tags definiert ist.
• Es wurden TF400367 Fehler auf der Seite "Agentpools" behoben.
• Ein Fehler wurde behoben, bei dem die Identität des Analysebesitzers als inaktive Identität angezeigt wurde.
• Es wurde ein Endlosschleifenfehler auf CronScheduleJobExtension behoben.

Azure DevOps Server 2022 Update 0.1 Patch 1 Veröffentlichungsdatum: 13. Juni 2023

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

• CVE-2023-21565: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• CVE-2023-21569: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• Ein Fehler mit dem Dienstverbindungen-Editor wurde behoben. Entwurf des Endpunktzustands wird nun beim Schließen der Komponente geleert.
• Ein Fehler wurde behoben, bei dem beim Trennen oder Anfügen der Auflistung der folgende Fehler gemeldet wurde: "TF246018: Der Datenbankvorgang hat das Timeoutlimit überschritten und wurde abgebrochen.

Veröffentlichungsdatum von Azure DevOps Server 2022 Update 0.1: 9. Mai 2023

Azure DevOps Server 2022.0.1 ist ein Rollup von Fehlerbehebungen. Es enthält alle Fixes in azure DevOps Server 2022.0.1 RC, die zuvor veröffentlicht wurden. Sie können Azure DevOps Server 2022.0.1 oder ein Upgrade von Azure DevOps Server 2022 oder Team Foundation Server 2015 oder höher direkt installieren.

Azure DevOps Server 2022 Update 0.1 RC Veröffentlichungsdatum: 11. April 2023

Azure DevOps Server 2022.0.1 RC ist ein Rollup von Fehlerbehebungen. Es enthält alle Fixes in den zuvor veröffentlichten Azure DevOps Server 2022-Patches. Sie können Azure DevOps Server 2022.0.1 oder ein Upgrade von Azure DevOps Server 2022 oder Team Foundation Server 2015 oder höher direkt installieren.

Diese Version enthält Korrekturen für folgende Fehler:

• Aktualisiertes Git Virtual File System (GVFS) von v2.39.1.1-micorosoft.2, um eine Sicherheitslücke zu beheben.
• Testdaten wurden nicht gelöscht, wodurch die Datenbank vergrößert wurde. Mit diesem Fix haben wir die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.
• Updates für AnalyticCleanupJob, der Auftragsstatus wurde beendet, und jetzt melden wir "Erfolgreich".
• Der Befehl "tfx extension publish" wurde mit dem Fehler "Der angegebene Schlüssel war im Wörterbuch nicht vorhanden" behoben.
• Es wurde eine Problemumgehung zum Beheben und Fehler beim Zugriff auf die Teamkalendererweiterung implementiert.
• CVE-2023-21564: Sicherheitsanfälligkeit in Azure DevOps Server bezüglich standortübergreifendem Skripting
• CVE-2023-21553: Sicherheitsanfälligkeit in Azure DevOps Server bezüglich Remotecodeausführung
• MsBuild- und VSBuild-Aufgaben wurden aktualisiert, um Visual Studio 2022 zu unterstützen.
• Aktualisieren Sie die Methodik des Ladens der erneuten Authentifizierung, um den XSS-Angriffsvektor zu verhindern.
• Azure DevOps Server 2022 Proxy meldet den folgenden Fehler: VS800069: Dieser Dienst ist nur in lokalen Azure DevOps verfügbar.
• Problem mit der Barrierefreiheit von Regalen über die Web-UI wurde behoben.
• Es wurde ein Problem behoben, das einen Neustart des Tfsjobagent-Diensts und des Azure DevOps Server-Anwendungspools nach dem Aktualisieren der SMTP-bezogenen Einstellung in der Azure DevOps Server Management Console erforderte.
• Benachrichtigungen wurden für PAT sieben Tage vor dem Ablaufdatum nicht gesendet.

Azure DevOps Server 2022 Patch 4 Veröffentlichungsdatum: 13. Juni 2023

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

• CVE-2023-21565: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• CVE-2023-21569: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing.
• Ein Fehler mit dem Dienstverbindungen-Editor wurde behoben. Entwurf des Endpunktzustands wird nun beim Schließen der Komponente geleert.
• Ein Fehler wurde behoben, bei dem beim Trennen oder Anfügen der Auflistung der folgende Fehler gemeldet wurde: "TF246018: Der Datenbankvorgang hat das Timeoutlimit überschritten und wurde abgebrochen.

Azure DevOps Server 2022 Patch 3 Veröffentlichungsdatum: 21. März 2023

Wir haben einen Patch (19.205.33506.1) für Azure DevOps Server 2022 veröffentlicht, der Fixes für Folgendes enthält.

• Es wurde ein Problem behoben, das einen Neustart des Tfsjobagent-Diensts und des Azure DevOps Server-Anwendungspools nach dem Aktualisieren der SMTP-bezogenen Einstellung in der Azure DevOps Server Management Console erforderte.
• Kopieren Sie den Endpunktstatus in den Bearbeitungsbereich des Dienstendpunkts, anstatt ihn per Verweis zu übergeben.
• Beim Bearbeiten von Dienstverbindungen wurden die Bearbeitungen zuvor auf der Benutzeroberfläche beibehalten, nachdem sie die Schaltfläche "Abbrechen" ausgewählt haben. Mit diesem Patch wurde das Benachrichtigungs-SDK behoben, wenn für ein Team die Benachrichtigungsübermittlung auf "Nicht liefern" festgelegt ist. Wenn das Benachrichtigungsabonnement in diesem Szenario mit der Einstellungszustellungsoption "Team" konfiguriert ist, erhalten Teammitglieder die Benachrichtigungen nicht. Es ist nicht erforderlich, die Identitäten unter dem Team weiter zu erweitern, um die Einstellungen der Mitglieder zu überprüfen.

Azure DevOps Server 2022 Patch 2 Veröffentlichungsdatum: 14. Februar 2023

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

• CVE-2023-21564: Sicherheitsanfälligkeit in Azure DevOps Server bezüglich standortübergreifendem Skripting
• MsBuild- und VSBuild-Aufgaben wurden aktualisiert, um Visual Studio 2022 zu unterstützen.
• Aktualisieren Sie die Methodik des Ladens der erneuten Authentifizierung, um mögliche XSS-Angriffsvektoren zu verhindern.
• Azure DevOps Server 2022 Proxy meldet den folgenden Fehler: VS800069: Dieser Dienst ist nur in lokalen Azure DevOps verfügbar.

Azure DevOps Server 2022 Patch 1 Veröffentlichungsdatum: 24. Januar 2023

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

• Testdaten wurden nicht gelöscht, wodurch die Datenbank vergrößert wurde. Mit diesem Fix haben wir die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.
• Updates für AnalyticCleanupJob, der Auftragsstatus wurde beendet, und jetzt melden wir "Erfolgreich".
• Der Befehl "tfx extension publish" wurde mit dem Fehler "Der angegebene Schlüssel war im Wörterbuch nicht vorhanden" behoben.
• Es wurde eine Problemumgehung zum Beheben und Fehler beim Zugriff auf die Teamkalendererweiterung implementiert.

Veröffentlichungsdatum von Azure DevOps Server 2022: 6. Dezember 2022

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

Veröffentlichungsdatum von Azure DevOps Server 2022 RC2: 25. Oktober 2022

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

Die Unterstützung öffentlicher RSA-Schlüssel wurde verbessert, um ZUSÄTZLICH zu den zuvor unterstützten SHA1 SSH-RSA-Typen SHA2 zu unterstützen.

Zu den nun unterstützten Öffentlichen Schlüsseltypen gehören:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Erforderliche Aktion

Wenn Sie die Umgehung implementiert haben, um SSH-RSA zu aktivieren, indem Sie sie explizit in der .ssh/config1 Datei angeben, müssen Sie die PubkeyAcceptedTypesDatei entweder entfernen oder ändern, um entweder RSA-SHA2-256 oder RSA-SHA2-512 oder beides zu verwenden. Details dazu finden Sie, was Sie tun müssen, wenn Sie weiterhin zur Eingabe Ihres Kennworts aufgefordert werden und GIT_SSH_COMMAND="ssh -v" git fetch in der Dokumentation hier keinen algorithmus für gegenseitige Signaturen angezeigt werden.

Elliptical Key-Unterstützung wurde noch nicht hinzugefügt und bleibt ein sehr angefordertes Feature in unserem Backlog.

Veröffentlichungsdatum von Azure DevOps Server 2022 RC1: 9. August 2022

Zusammenfassung der Neuerungen in Azure DevOps Server 2022

Azure DevOps Server 2022 führt viele neue Features ein. Einige der Highlights sind unter anderem:

• Lieferpläne
• Anzeigen der richtigen Persona auf Commit-Links
• Neue Steuerelemente für Umgebungsvariablen in Pipelines
• Generieren eines uneingeschränkten Tokens für Freihandbuilds
• Neue TFVC-Seiten
• Gruppieren nach Tags, die in Diagramm-Widgets verfügbar sind

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

• Boards
• Repos
• Pipelines
• Berichterstellung

---

Boards

Lieferpläne

Wir freuen uns, ihnen mitzuteilen, dass Übermittlungspläne jetzt in Azure DevOps Server enthalten sind. Übermittlungspläne bieten drei wichtige Szenarien:

• Eine Zeitachsenansicht des Plans
• Fortschritt der Arbeit
• Abhängigkeitsüberwachung

Nachfolgend sind die wichtigsten Features aufgeführt. Filterung, Markierungen und Feldkriterien sind ebenfalls Teil von Übermittlungsplänen.

Es gibt zwei Hauptansichten: kondensiert und erweitert

Übermittlungspläne 2.0 ermöglichen das Anzeigen aller Arbeitsaufgaben in Ihrem Plan auf einer Zeitachse mithilfe von Anfangs- und Zieldaten oder Iterationsterminen. Die Reihenfolge der Rangfolge ist Start- und Zieltermine, gefolgt von Iteration. Auf diese Weise können Sie Arbeitsaufgaben auf Portfolioebene wieEpic hinzufügen, die häufig nicht zu einer Iteration definiert sind.

Es gibt zwei Hauptansichten der komprimierten Ansicht und der erweiterten Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe in der ight-hand-Seite des Plans klicken.

Es gibt zwei Hauptansichten der komprimierten Ansicht und der erweiterten Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe auf der rechten Seite des Plans klicken.

• Kondensierte Ansicht

  In der komprimierten Ansicht sind alle Arbeitsaufgabenkarten reduziert, was bedeutet, dass nicht alle Karteninformationen angezeigt werden. Diese Ansicht ist nützlich für eine Gesamtansicht der Arbeit im Plan. Um die Kartenfelder zu reduzieren, klicken Sie auf das Kartensymbol neben den Lupensymbolen auf der rechten Seite des Plans.

  Hier ist ein Beispiel für einen Plan zum Umschalten zwischen den komprimierten und erweiterten Ansichten.

  

• Erweiterte Ansicht

  In der erweiterten Ansicht wird der Fortschritt einer Arbeitsaufgabe angezeigt, indem die Anzahl der untergeordneten und verknüpften Elemente gezählt und der Prozentsatz abgeschlossen angezeigt wird. Der Aktuelle Fortschritt wird durch die Anzahl der Arbeitsaufgaben bestimmt.

  Hier ist ein Beispiel für einen Plan mit einer erweiterten Ansicht. Beachten Sie die Statusanzeigen und den Prozentsatz abgeschlossen.

  

Abhängigkeitsüberwachung

Die Abhängigkeitsnachverfolgung basiert auf Vorgänger- und Nachfolgerlinks, die in Arbeitsaufgaben definiert werden. Wenn diese Verknüpfungen nicht definiert sind, werden keine Abhängigkeitslinien angezeigt. Wenn ein Abhängigkeitsproblem mit einer Arbeitsaufgabe besteht, wird das Symbol für Abhängigkeitslinks rot gefärbt.

• Anzeigen von Abhängigkeiten

  Bestimmte Abhängigkeiten werden über den Abhängigkeitsbereich angezeigt, in dem alle Abhängigkeiten für diese Arbeitsaufgabe einschließlich der Richtung angezeigt werden. Ein rotes Ausrufezeichen weist auf ein Abhängigkeitsproblem hin. Wenn Sie den Bereich aufrufen möchten, klicken Sie einfach auf das Symbol für Abhängigkeitslinks in der oberen rechten Ecke der Karte. Hier sind Beispiele für Abhängigkeiten.

  

  

• Abhängigkeitslinien

  Abhängigkeiten zwischen Arbeitsaufgaben werden mit direktionalen Pfeillinien zwischen den jeweiligen Arbeitsaufgaben visualisiert. Mehrere Abhängigkeiten werden als mehrere Zeilen angezeigt. Eine rote, farbige Linie weist auf ein Problem hin.

  Nachfolgend finden Sie einige Beispiele.

  

  Hier ist ein Beispiel für eine Arbeitsaufgabe mit mehreren Abhängigkeiten, und es funktioniert auch mit einer komprimierten Ansicht.

  

  Wenn ein Problem besteht, ist die Linienfarbe rot, und dies ist das Abhängigkeitssymbol.

  Beispiel:

  

Kartenformat

Karten können jetzt mithilfe von Regeln wie den Kanban-Boards formatiert werden. Öffnen Sie die Planeinstellungen, und klicken Sie auf "Formatvorlagen". Klicken Sie im Bereich "Formatvorlagen" auf " +Formatierungsregel hinzufügen", um die Regel hinzuzufügen, und klicken Sie dann auf " Speichern". Es können bis zu 10 Regeln vorhanden sein, und jede Regel kann bis zu 5 Klauseln aufweisen.

• Vorher

• After

Weitere Informationen zu Übermittlungsplänen finden Sie hier in der Dokumentation.

Entfernte Elemente auf dem Arbeitsaufgabenhub

Der Arbeitsaufgabenhub ist der Ort, an dem eine Liste der von Ihnen erstellten Oder Ihnen zugewiesenen Elemente angezeigt wird. Sie bietet mehrere personalisierte Pivot- und Filterfunktionen, um die Auflistung von Arbeitsaufgaben zu optimieren. Eine der wichtigsten Beschwerden des Pivots "Zugewiesen an mich " besteht darin, dass entfernte Arbeitsaufgaben angezeigt werden. Wir stimmen zu, dass entfernte Arbeitsaufgaben nicht mehr von Wert sind und nicht im Backlog enthalten sein sollten. In diesem Sprint werden alle entfernten Elemente aus den Ansichten "Zugewiesen für mich " im Arbeitsaufgabenhub ausgeblendet.

Anzeigen der richtigen Persona auf Commit-Links

Im Abschnitt "Entwicklung" in einer Arbeitsaufgabe wird die Liste der relevanten Commits und Pullanforderungen angezeigt. Sie können den Autor der Commit- oder Pullanforderung zusammen mit der zugehörigen Zeit anzeigen. Mit diesem Update wurde ein Problem behoben, bei dem der Avatar des Autors in der Ansicht falsch angezeigt wurde.

Entfernen der Möglichkeit zum Herunterladen einer gelöschten Anlage aus dem Arbeitsaufgabenverlauf

Es wurde ein kleines Problem behoben, bei dem Benutzer Anlagen aus dem Arbeitsaufgabenverlauf herunterladen konnten, auch nachdem die Anlage aus dem Formular entfernt wurde. Nachdem die Anlage entfernt wurde, kann sie nicht aus dem Verlauf heruntergeladen werden, noch ist die Download-URL aus der REST-API-Antwort verfügbar.

Wert "Will not Fix" zum Fehlerursachenfeld hinzugefügt

Wie bei allen anderen Arbeitselementtypen verfügt auch der Fehler-Arbeitselementtyp über einen klar definierten Workflow. Jeder Workflow besteht aus drei oder mehr Zuständen und einem Grund. Gründe geben an, warum das Element von einem Zustand in einen anderen gewechselt ist. Mit diesem Update haben wir einen Will not fix reason value for the Bug work item types in the Agile process hinzugefügt. Der Wert ist als Grund verfügbar, wenn Fehler von "Neu" oder "Aktiv" in "Gelöst" verschoben werden. Weitere Informationen zum Definieren, Erfassen, Triagen und Verwalten von Softwarefehlern finden Sie in der Dokumentation zu Azure Boards.

Pipelines

Entfernen von Aufbewahrungsrichtlinien pro Pipeline in klassischen Builds

Sie können jetzt Aufbewahrungsrichtlinien für klassische Builds und YAML-Pipelines in den Azure DevOps-Projekteinstellungen konfigurieren. Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines werden nicht mehr unterstützt. Obwohl dies die einzige Möglichkeit ist, die Aufbewahrung für YAML-Pipelines zu konfigurieren, können Sie die Aufbewahrung auch für klassische Buildpipelines pro Pipeline konfigurieren. Wir haben alle Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines in einer bevorstehenden Version entfernt.

Was dies für Sie bedeutet: Jede klassische Buildpipeline, die für aufbewahrungsregeln pro Pipeline verwendet wurde, wird von den Aufbewahrungsregeln auf Projektebene gesteuert.

Um sicherzustellen, dass beim Upgrade keine Builds verloren gehen, erstellen wir eine Lease für alle Builds, die zum Zeitpunkt des Upgrades vorhanden sind, die nicht über eine Lease verfügen.

Es wird empfohlen, die Aufbewahrungseinstellungen auf Projektebene nach dem Upgrade zu überprüfen. Wenn Ihre Pipeline speziell benutzerdefinierte Regeln erfordert, können Sie einen benutzerdefinierten Vorgang in Ihrer Pipeline verwenden. Informationen zum Hinzufügen von Aufbewahrungsleases über eine Aufgabe finden Sie in den festgelegten Aufbewahrungsrichtlinien für Builds, Versionen und Tests.

Neue Steuerelemente für Umgebungsvariablen in Pipelines

Der Azure Pipelines-Agent überprüft die Standardausgabe auf spezielle Protokollierungsbefehle und führt sie aus. Der setVariable Befehl kann verwendet werden, um eine Variable festzulegen oder eine zuvor definierte Variable zu ändern. Dies kann potenziell von einem Akteur außerhalb des Systems ausgenutzt werden. Wenn Ihre Pipeline beispielsweise über einen Schritt verfügt, der die Liste der Dateien auf einem FTP-Server druckt, kann eine Person mit Zugriff auf den FTP-Server eine neue Datei hinzufügen, deren Name den setVariable Befehl enthält und dazu führt, dass die Pipeline ihr Verhalten ändert.

Wir haben viele Benutzer, die darauf angewiesen sind, Variablen mithilfe des Protokollierungsbefehls in ihrer Pipeline festzulegen. Mit dieser Version nehmen wir die folgenden Änderungen vor, um das Risiko unerwünschter Verwendungen des setVariable Befehls zu verringern.

• Wir haben ein neues Konstrukt für Aufgabenautoren hinzugefügt. Durch Einschließen eines Codeausschnitts wie der folgenden in task.jsonkann ein Aufgabenautor steuern, ob variablen von ihrer Aufgabe festgelegt werden.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Darüber hinaus aktualisieren wir eine Reihe integrierter Aufgaben wie ssh, sodass sie nicht ausgenutzt werden können.

• Schließlich können Sie jetzt YAML-Konstrukte verwenden, um zu steuern, ob ein Schritt Variablen festlegen kann.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generieren eines uneingeschränkten Tokens für Freihandbuilds

GitHub Enterprise-Benutzer verwenden häufig Forks, um zu einem Upstream-Repository beizutragen. Wenn Azure Pipelines Beiträge aus einer Verzweigung eines GitHub Enterprise-Repositorys erstellt, schränkt es die Berechtigungen ein, die dem Auftragszugriffstoken gewährt wurden, und lässt keinen Zugriff auf Pipelineschlüssel durch solche Aufträge zu. Weitere Informationen zur Sicherheit von Baufarben finden Sie in unserer Dokumentation.

Dies kann restriktiver als gewünscht in solchen geschlossenen Umgebungen sein, in denen Benutzer weiterhin von einem Modell für die zusammenarbeitende Interne Quelle profitieren können. Sie können eine Einstellung in einer Pipeline zwar so konfigurieren, dass geheime Schlüssel für Freihandvorgänge verfügbar gemacht werden, aber es gibt keine Einstellung zum Steuern des Auftragszugriffstokenbereichs. Mit dieser Version geben wir Ihnen die Kontrolle, ein reguläres Auftragszugriffstoken auch für Builds von Forks zu generieren.

Sie können diese Einstellung über Trigger im Pipeline-Editor ändern. Bevor Sie diese Einstellung ändern, stellen Sie sicher, dass Sie die Sicherheitsauswirkungen der Aktivierung dieser Konfiguration vollständig verstehen.

Als geschützte Ressource in YAML-Pipelines erstellen

Sie können Ihr Azure DevOps-Projekt organisieren, um viele Unterprojekte zu hosten – jeweils mit einem eigenen Azure DevOps Git-Repository und einer oder mehreren Pipelines. In dieser Struktur möchten Sie möglicherweise steuern, welche Pipelines auf welche Repositorys zugreifen können. Angenommen, Sie haben zwei Repositorys A und B im selben Projekt und zwei Pipelines X und Y, die diese Repositorys normalerweise erstellen. Möglicherweise möchten Sie verhindern, dass Pipeline Y auf Repository A zugreift. Im Allgemeinen möchten Sie, dass die Mitwirkenden von A steuern, auf welche Pipelines sie Zugriff gewähren möchten.

Obwohl dies teilweise mit Azure Git-Repositorys und -Pipelines möglich war, gab es keine Erfahrung für die Verwaltung. Dieses Feature behebt diese Lücke. Azure Git-Repositorys können jetzt wie Dienstverbindungen und Agentpools als geschützte Ressourcen in YAML-Pipelines behandelt werden.

Als Mitwirkender von Repo A können Sie Ihrem Repository Überprüfungen und Pipelineberechtigungen hinzufügen. Navigieren Sie dazu zu den Projekteinstellungen, wählen Sie Repositorys und dann Ihr Repository aus. Sie sehen ein neues Menü mit dem Namen "Prüfungen", in dem Sie eine der in-the-Box- oder benutzerdefinierten Prüfungen in Form von Azure-Funktionen konfigurieren können.

Auf der Registerkarte "Sicherheit" können Sie die Liste der Pipelines verwalten, die auf das Repository zugreifen können.

Wenn eine YAML-Pipeline ein Repository verwendet, überprüft und stellt die Azure Pipelines-Infrastruktur sicher, dass alle Prüfungen und Berechtigungen erfüllt sind.

Berechtigungen und Überprüfungen auf variablen Gruppen und sichere Dateien

Sie können verschiedene Arten von freigegebenen Ressourcen in YAML-Pipelines verwenden. Beispiele sind Dienstverbindungen, variable Gruppen, sichere Dateien, Agentpools, Umgebungen oder Repositorys. Um einen Zugriff auf eine Ressource durch eine Pipeline zu schützen, kann der Besitzer der Ressource Berechtigungen konfigurieren und diese Ressource überprüfen. Jedes Mal, wenn eine Pipeline versucht, auf die Ressource zuzugreifen, werden alle konfigurierten Berechtigungen und Prüfungen ausgewertet. Diese Schutzmaßnahmen sind für Dienstverbindungen, Umgebungen und Agentpools für eine Weile verfügbar. Sie wurden kürzlich zu Repositorys hinzugefügt. Mit dieser Version fügen wir den gleichen Schutz zu variablen Gruppen und sicheren Dateien hinzu.

Um den Zugriff auf eine Variablegruppe oder eine sichere Datei auf eine kleine Gruppe von Pipelines einzuschränken, verwenden Sie das Feature "Pipelines-Berechtigungen" .

Um Überprüfungen oder Genehmigungen zu konfigurieren, die jedes Mal ausgewertet werden sollen, wenn eine Pipeline ausgeführt wird, verwenden Sie die Genehmigungen und sucht nach dem Bibliotheksfeature .

Änderungen an der automatischen Erstellung von Umgebungen

Wenn Sie eine YAML-Pipeline erstellen und auf eine umgebung verweisen, die nicht vorhanden ist, erstellt Azure Pipelines automatisch die Umgebung. Diese automatische Erstellung kann entweder im Benutzerkontext oder im Systemkontext erfolgen. In den folgenden Flüssen kennt Azure Pipelines den Benutzer, der den Vorgang ausführt:

• Sie verwenden den Assistenten für die YAML-Pipelineerstellung in der Azure Pipelines-Weboberfläche und verweisen auf eine Umgebung, die noch nicht erstellt wurde.
• Sie aktualisieren die YAML-Datei mithilfe des Azure Pipelines-Webeditors und speichern die Pipeline, nachdem Sie einen Verweis auf eine Umgebung hinzugefügt haben, die nicht vorhanden ist. In jedem der oben genannten Fälle verfügt Azure Pipelines über ein klares Verständnis des Benutzers, der den Vorgang ausführt. Daher wird die Umgebung erstellt und der Benutzer der Administratorrolle für die Umgebung hinzugefügt. Dieser Benutzer verfügt über alle Berechtigungen zum Verwalten der Umgebung und/oder zum Einschließen anderer Benutzer in verschiedene Rollen für die Verwaltung der Umgebung.

In den folgenden Flüssen enthält Azure Pipelines keine Informationen zum Benutzer, der die Umgebung erstellt: Sie aktualisieren die YAML-Datei mit einem anderen externen Code-Editor, fügen einen Verweis auf eine Umgebung hinzu, die nicht vorhanden ist, und führen dann dazu, dass eine fortlaufende Integrationspipeline ausgelöst wird. In diesem Fall kennt Azure Pipelines den Benutzer nicht. Zuvor haben wir diesen Fall behandelt, indem wir alle Projektmitwirkenden der Administratorrolle der Umgebung hinzugefügt haben. Jedes Mitglied des Projekts konnte dann diese Berechtigungen ändern und verhindern, dass andere auf die Umgebung zugreifen.

Wir haben Ihr Feedback dazu erhalten, allen Mitgliedern eines Projekts Administratorberechtigungen für eine Umgebung zu erteilen. Da wir Ihr Feedback gehört haben, haben wir gehört, dass wir nicht automatisch eine Umgebung erstellen sollten, wenn es nicht klar ist, wer der Benutzer die Operation ausführt. Mit dieser Version haben wir Änderungen daran vorgenommen, wie Umgebungen automatisch erstellt werden:

• In Zukunft wird eine Pipelineausführung nicht automatisch eine Umgebung erstellen, wenn sie nicht vorhanden ist und wenn der Benutzerkontext nicht bekannt ist. In solchen Fällen schlägt die Pipeline fehl, wenn ein Fehler in der Umgebung nicht gefunden wurde. Sie müssen die Umgebungen mit der richtigen Sicherheit vorab erstellen und die Konfiguration überprüfen, bevor Sie sie in einer Pipeline verwenden.
• Pipelines mit bekanntem Benutzerkontext erstellen weiterhin Umgebungen automatisch wie in der Vergangenheit.
• Schließlich sollte darauf hingewiesen werden, dass das Feature zum automatischen Erstellen einer Umgebung nur hinzugefügt wurde, um den Prozess der ersten Schritte mit Azure Pipelines zu vereinfachen. Es wurde für Testszenarien und nicht für Produktionsszenarien gedacht. Sie sollten immer Produktionsumgebungen mit den richtigen Berechtigungen und Überprüfungen erstellen und diese dann in Pipelines verwenden.

Insights-Dialog aus Build Pipeline entfernen

Basierend auf Ihrem Feedback wurde das Dialogfeld "Aufgaben-/Pipelineeinblicke", das beim Navigieren in der Buildpipeline angezeigt wird, entfernt, um den Workflow zu verbessern. Die Pipelineanalysen sind weiterhin verfügbar, damit Sie über die benötigten Erkenntnisse verfügen.

Unterstützung für sequenzielle Bereitstellungen anstelle der neuesten nur bei Verwendung exklusiver Sperrprüfungen

In YAML-Pipelines werden Prüfungen verwendet, um die Ausführung von Stufen für geschützte Ressourcen zu steuern. Eine der allgemeinen Prüfungen, die Sie verwenden können, ist eine exklusive Sperrüberprüfung. Mit dieser Überprüfung kann nur eine einzelne Ausführung aus der Pipeline fortgesetzt werden. Wenn mehrere Ausführungen versuchen, gleichzeitig in einer Umgebung bereitzustellen, bricht die Überprüfung alle alten Ausführungen ab und lässt die neueste Ausführung zu.

Das Abbrechen alter Läufe ist ein guter Ansatz, wenn Ihre Versionen kumulativ sind und alle Codeänderungen aus vorherigen Ausführungen enthalten. Es gibt jedoch einige Pipelines, in denen Codeänderungen nicht kumulativ sind. Mit diesem neuen Feature können Sie festlegen, dass alle Ausführungen fortgesetzt und sequenziell in einer Umgebung bereitgestellt werden können, oder das vorherige Verhalten beim Abbrechen alter Ausführungen beibehalten und nur die neueste Ausführung zulassen. Sie können dieses Verhalten mithilfe einer neuen Eigenschaft angeben, die in der Pipeline-YAML-Datei aufgerufen wird lockBehavior . Ein Wert von sequential impliziert, dass alle Ausgeführten die Sperre sequenziell an die geschützte Ressource abrufen. Ein Wert von runLatest impliziert, dass nur die neueste Ausführung die Sperre für die Ressource erwirbt.

Führen Sie die folgenden Schritte aus, um die Überprüfung „Exklusive Sperre“ mit sequenziellen Bereitstellungen (sequential) oder mit runLatest zu verwenden:

1. Aktivieren Sie die Überprüfung „Exklusive Sperre“ für die Umgebung (oder für eine andere geschützte Ressource).
2. Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft an, die aufgerufen wird lockBehavior. Diese kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:

Festlegen für eine Phase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Festlegen für die Pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Wenn Sie keinen Wert angeben lockBehavior, wird davon ausgegangen runLatest, dass sie .

Unterstützung für Quebec-Version 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 nun die App aktualisiert, um mit der Quebec-Version von ServiceNow zu arbeiten. Sowohl klassische als auch YAML-Pipelines funktionieren jetzt mit Quebec. Um sicherzustellen, dass diese Integration funktioniert, führen Sie ein Upgrade auf die neue Version der App (4.188.0) aus dem Service Now Store durch. Weitere Informationen finden Sie unter Integration in ServiceNow Change Management.

Neue bedingte YAML-Ausdrücke

Das Schreiben von bedingten Ausdrücken in YAML-Dateien wurde mit der Verwendung von ${{ else }} und ${{ elseif }} Ausdrücken noch einfacher. Im Folgenden finden Sie Beispiele für die Verwendung dieser Ausdrücke in YAML-Pipelinesdateien.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Unterstützung für Platzhalter in Pfadfiltern

Wildcards können verwendet werden, wenn Sie Ein- und Ausschlusszweige für CI- oder PR-Trigger in einer YaML-Pipelinedatei angeben. Sie können jedoch nicht verwendet werden, wenn Pfadfilter angegeben werden. Sie können beispielsweise nicht alle Pfade einschließen, die übereinstimmen src/app/**/myapp*. Dies wurde von mehreren Kunden als Unannehmlichkeiten herausgestellt. Dieses Update füllt diese Lücke. Jetzt können Sie beim Angeben von Pfadfiltern Wildcardzeichen (**, *oder ?) verwenden.

Die Standard-Agent-Spezifikation für Pipelines lautet Windows-2022.

Das windows-2022 Image ist bereit, die Standardversion für die windows-latest Bezeichnung in Von Microsoft gehosteten Azure Pipelines-Agents zu sein. Bis jetzt verweist diese Bezeichnung auf Windows-2019-Agents. Diese Änderung wird über einen Zeitraum von mehreren Wochen ab dem 17. Januar eingeführt. Wir planen, die Migration bis März abzuschließen.

Azure Pipelines wird seit September 2021 unterstützt windows-2022 . Wir haben Ihr Feedback überwacht, um die windows-2022 Bildstabilität zu verbessern, und jetzt sind wir bereit, es als neueste festzulegen.

Das windows-2022 Bild enthält Visual Studio 2022. Eine vollständige Liste der Unterschiede zwischen windows-2022 und windows-2019, besuchen Sie das GitHub-Problem. Eine vollständige Liste der auf dem Image installierten Software finden Sie hier.

Umbenennung des Pipelineordners überprüft Berechtigungen

Ordner, die Pipelines enthalten, können umbenannt werden. Das Umbenennen eines Ordners ist jetzt nur erfolgreich, wenn der Benutzer über Bearbeitungsberechtigungen für mindestens eine Pipeline verfügt, die im Ordner enthalten ist.

Planung des Pipelines-Agent-Laufzeitupgrades

Was ist der Pipeline-Agent?

Der Azure DevOps-Pipeline-Agent ist das Softwareprodukt, das auf einem Pipelinehost ausgeführt wird, um Pipelineaufträge auszuführen. Sie wird auf von Microsoft gehosteten Agents, Scale Set-Agents und selbst gehosteten Agents ausgeführt. In letzterem Fall installieren Sie sie selbst. Der Pipeline-Agent besteht aus einem Listener und Worker (implementiert in .NET), der Worker führt Aufgaben aus, die entweder in Node oder PowerShell implementiert sind, und hostet diese Laufzeiten für sie.

Bevorstehendes Upgrade auf .NET 6 & Red Hat 6 veraltet

Mit der Veröffentlichung von .NET 6 können wir die neuen plattformübergreifenden Funktionen nutzen. Insbesondere können wir systemeigene Kompatibilität für Apple Silicon und Windows Arm64 bereitstellen. Daher planen wir, in den kommenden Monaten zu .NET 6 für Pipeline-Agent (Listener und Worker) zu wechseln.

Aufgrund einer Reihe von Einschränkungen, die dies auferlegt, fallen wir red Hat Enterprise Linux 6 Support vom 30. April 2022.

Aktualisierungen der Azure-Dateikopie-Aufgabe

Wir werden eine neue Version der Azure-Dateikopie-Aufgabe einführen. Diese Aufgabe wird verwendet, um Dateien in Microsoft Azure-Speicherblobs oder virtuelle Computer (VMs) zu kopieren. Die neue Version verfügt über mehrere Updates, die häufig von der Community angefordert wurden:

• Die Version des AzCopy-Tools wurde auf 10.12.2 aktualisiert, das Unterstützung für Dateiinhaltstypen hat. Wenn Sie pdf, Excel, PPT oder einen der unterstützten MIME-Typen kopieren, wird der Inhaltstyp der Datei ordnungsgemäß festgelegt.

• Mit der neuen Version von AzCopy können Sie auch eine Einstellung konfigurieren, um das Ziel zu bereinigen, wenn der Zieltyp Azure Blob ist. Wenn Sie diese Option festlegen, werden alle Ordner/Dateien in diesem Container gelöscht. Oder wenn ein Blobpräfix bereitgestellt wird, werden alle Ordner/Dateien in diesem Präfix gelöscht.

• Die neue Version der Aufgabe basiert auf Az-Modulen, die auf dem Agent anstelle von AzureRM-Modulen installiert sind. Dadurch wird bei Verwendung der Aufgabe eine unnötige Warnung entfernt.

Die Änderungen sind Teil eines Hauptversionsupdates für diese Aufgabe. Sie müssen Ihre Pipelines explizit aktualisieren, um die neue Version zu verwenden. Wir haben diese Option getroffen, die Hauptversion zu aktualisieren, um sicherzustellen, dass wir keine Pipelines unterbrechen, die noch von AzureRM-Modulen abhängig sind.

Neue Erweiterungspunkte für die Detailansicht von Pipelines

Wir haben zwei neue Erweiterungspunkte hinzugefügt, auf die Sie in Ihren Erweiterungen abzielen können. Mit diesen Erweiterungspunkten können Sie eine benutzerdefinierte Schaltfläche im Pipelineheader und ein benutzerdefiniertes Menü in einem Pipelineordner hinzufügen:

• Benutzerdefinierte Schaltfläche im Pipelineheader: ms.vss-build-web.pipelines-header-menu
• Benutzerdefiniertes Menü in einem Pipelineordner: ms.vss-build-web.pipelines-folder-menu

Um diese neuen Erweiterungspunkte zu verwenden, fügen Sie einfach einen neuen Beitrag hinzu, der auf sie in der Manifestdatei Ihrer Azure DevOps-Erweiterung vss-extension.json ausgerichtet ist.

Zum Beispiel:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Das Ergebnis lautet:

• Benutzerdefinierte Schaltfläche im Pipelineheader

  

• Benutzerdefiniertes Menü in einem Pipelineordner

  

Verbesserte Migration zu Azure DevOps Services

Wenn Sie einen Import von Azure DevOps Server zu Azure DevOps Services ausführen, müssen Sie berücksichtigen, dass Azure DevOps keine Aufbewahrungsregeln pro Pipeline mehr unterstützt. Mit diesem Update haben wir diese Richtlinien entfernt, wenn Sie von Ihrem lokalen Azure DevOps-Server zu Azure DevOps Services migrieren. Weitere Informationen zum Konfigurieren von Aufbewahrungsrichtlinien finden Sie in unserer Dokumentation zum Festlegen von Aufbewahrungsrichtlinien für Builds, Versionen und Tests.

Verbesserung der Pipelines führt REST-API aus

Zuvor hat die Pipelines REST-API nur das self Repository zurückgegeben. Mit diesem Update gibt die Pipelines REST-API alle Repositoryressourcen eines Builds zurück.

Erweiterte YAML-Pipelines-Vorlagen können jetzt Kontextinformationen für Phasen, Aufträge und Bereitstellungen übergeben werden.

Mit diesem Update fügen wir eine neue templateContext Eigenschaft für job, deploymentund stage YAML-Pipelinekomponenten hinzu, die in Verbindung mit Vorlagen verwendet werden sollen.

Hier ist ein Szenario für die Verwendung templateContext:

• Sie verwenden Vorlagen, um die Codeduplizierung zu reduzieren oder die Sicherheit Ihrer Pipelines zu verbessern

• Ihre Vorlage verwendet als Parameter eine Liste von stages, , jobsoder deployments

• Die Vorlage verarbeitet die Eingabeliste und führt einige Transformationen für die einzelnen Phasen, Aufträge oder Bereitstellungen durch. Beispielsweise wird die Umgebung festgelegt, in der jeder Auftrag ausgeführt wird, oder zusätzliche Schritte zum Erzwingen der Compliance

• Für die Verarbeitung sind zusätzliche Informationen erforderlich, die vom Pipelineautor für jede Phase, jeden Auftrag oder die Bereitstellung in der Liste an die Vorlage übergeben werden.

Betrachten wir dazu ein Beispiel. Angenommen, Sie erstellen eine Pipeline, die End-to-End-Tests für die Überprüfung der Pull-Anforderung ausführt. Ihr Ziel besteht darin, nur eine Komponente Ihres Systems zu testen. Da Sie jedoch End-to-End-Tests ausführen möchten, benötigen Sie eine Umgebung, in der mehr Komponenten des Systems verfügbar sind, und Sie müssen ihr Verhalten angeben.

Sie erkennen, dass andere Teams ähnliche Anforderungen haben, daher entscheiden Sie sich, die Schritte zum Einrichten der Umgebung in eine Vorlage zu extrahieren. Der Code sieht wie folgt aus:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Was die Vorlage tut, wird für jeden Auftrag im testSet Parameter die Antwort der Systemkomponenten festgelegt, die durch ${{ testJob.templateContext.requiredComponents }} angegeben wurden, um ${{ testJob.templateContext.expectedHTTPResponseCode }} zurückzugeben.

Anschließend können Sie eine eigene Pipeline erstellen, die wie im folgenden Beispiel erweitert wird testing-template.yml .

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Diese Pipeline führt zwei Tests durch, eine positive und eine negative. Beide Tests erfordern, dass die dimensionsapi Komponente verfügbar ist. Der positive_test Auftrag erwartet den dimensionsapi zurückgegebenen HTTP-Code 200, während negative_test er HTTP-Code 500 zurückgibt.

Unterstützen von gruppenverwalteten Dienstkonten als Agentdienstkonto

Der Azure Pipelines-Agent unterstützt jetzt gruppenverwaltete Dienstkonten auf selbst gehosteten Agents unter Windows.

Gruppenverwaltete Dienstkonten bieten eine zentrale Kennwortverwaltung für Domänenkonten, die als Dienstkonten fungieren. Der Azure Pipelines-Agent kann diesen Kontotyp erkennen, sodass während der Konfiguration kein Kennwort erforderlich ist:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Informationsläufe

Eine Informationsausführung teilt Ihnen mit, dass Azure DevOps den Quellcode einer YAML-Pipeline nicht abrufen konnte. Eine solche Ausführung sieht wie folgt aus.

Azure DevOps ruft den Quellcode einer YAML-Pipeline als Reaktion auf externe Ereignisse ab, z. B. einen pushed commit oder als Reaktion auf interne Trigger, um beispielsweise zu überprüfen, ob Codeänderungen vorhanden sind und eine geplante Ausführung starten oder nicht. Wenn bei diesem Schritt ein Fehler auftritt, erstellt das System eine Informationsausführung. Diese Ausführungen werden nur erstellt, wenn sich der Code der Pipeline in einem GitHub- oder Bitbucket-Repository befindet.

Beim Abrufen des YAML-Codes einer Pipeline können aus folgenden Gründen Fehler auftreten:

• Ausfall beim Repositoryanbieter
• Anforderungsdrosselung
• Authentifizierungsprobleme
• Der Inhalt der .yml Datei der Pipeline kann nicht abgerufen werden.

Weitere Informationen zu Informationsläufen.

Die REST-API-Eigenschaft retentionRules der Builddefinition ist veraltet.

Im Antworttyp der Rest-APIBuildDefinition der Builddefinition ist die retentionRules Eigenschaft jetzt als veraltet gekennzeichnet, da diese Eigenschaft immer einen leeren Satz zurückgibt.

Repos

Neue TFVC-Seiten

Wir haben verschiedene Seiten in Azure DevOps aktualisiert, um eine neue Webplattform zu verwenden, um die Erfahrung konsistenter und barrierefreier für die verschiedenen Dienste zu machen. TFVC-Seiten wurden aktualisiert, um die neue Webplattform zu verwenden. Mit dieser Version stellen wir die neuen TFVC-Seiten allgemein zur Verfügung.

Deaktivieren eines Repositorys

Kunden haben häufig eine Möglichkeit zum Deaktivieren eines Repositorys angefordert und benutzer am Zugriff auf ihre Inhalte gehindert. Sie können dies beispielsweise in folgenden Fällen tun:

• Sie haben einen geheimen Schlüssel im Repository gefunden.
• Ein Drittanbieter-Scantool hat ein Repository gefunden, das nicht konform ist.

In solchen Fällen können Sie das Repository vorübergehend deaktivieren, während Sie an der Lösung des Problems arbeiten. Mit diesem Update können Sie ein Repository deaktivieren, wenn Sie über Lösch-Repositoryberechtigungen verfügen. Durch Deaktivieren eines Repositorys:

• Kann das Repository in der Liste der Repositorys auflisten
• Der Inhalt des Repositorys kann nicht gelesen werden.
• Der Inhalt des Repositorys kann nicht aktualisiert werden.
• Anzeigen einer Meldung, dass das Repository deaktiviert wurde, wenn er versucht, auf das Repository in der Azure Repos-Benutzeroberfläche zuzugreifen

Nachdem die erforderlichen Entschärfungsschritte ausgeführt wurden, können Benutzer mit der Berechtigung "Repository löschen" das Repository erneut aktivieren. Um ein Repository zu deaktivieren oder zu aktivieren, wechseln Sie zu "Projekteinstellungen", wählen Sie "Repositorys" und dann das spezifische Repository aus.

Konfigurationsmöglichkeit, dass Branchersteller nicht die Berechtigung „Berechtigungen verwalten“ in ihren Branches erhalten

Wenn Sie eine neue Verzweigung erstellen, erhalten Sie "Berechtigungen verwalten" für diese Verzweigung. Mit dieser Berechtigung können Sie die Berechtigungen anderer Benutzer ändern oder zusätzliche Benutzer zulassen, um zu dieser Verzweigung beizutragen. Beispielsweise kann ein Verzweigungsersteller diese Berechtigung verwenden, um einem anderen externen Benutzer das Vornehmen von Änderungen am Code zu ermöglichen. Sie können auch zulassen, dass eine Pipeline (Builddienstidentität) den Code in dieser Verzweigung ändert. In bestimmten Projekten mit höheren Complianceanforderungen sollten Benutzer solche Änderungen nicht vornehmen können.

Mit diesem Update können Sie alle Repositorys in Ihrem Teamprojekt konfigurieren und verzweigte Ersteller daran hindern, die Berechtigung "Berechtigungen verwalten" zu erhalten. Navigieren Sie hierzu zu den Projekteinstellungen, wählen Sie Repositorys und dann Einstellungen für alle Repositorys oder ein bestimmtes Repository aus.

Diese Einstellung ist standardmäßig aktiviert, um das vorhandene Verhalten nachzuahmen. Sie können es jedoch deaktivieren, wenn Sie dieses neue Sicherheitsfeature verwenden möchten.

Forkbenutzer können nicht mehr für eigene Upstream-PRs abstimmen

Mit Azure Repos können Benutzer mit der Berechtigung "Lesen" in einem Repository das Repository verzweigen und Änderungen an ihrer Verzweigung vornehmen. Um eine Pull-Anforderung mit ihren Änderungen an den Upstream zu übermitteln, benötigen Benutzer die Berechtigung "Mitwirken an Pullanforderungen" für den Upstream. Diese Berechtigung regelt jedoch auch, wer über Pull-Anfragen im upstream-Repository abstimmen kann. Daher können Sie in Situationen auftreten, in denen ein Benutzer, der kein Mitwirkender am Repository ist, eine Pullanforderung übermitteln und dazu führen kann, dass sie zusammengeführt wird, je nachdem, wie Sie die Verzweigungsrichtlinien einrichten.

Bei Projekten, die ein Modell der inneren Quelle fördern, ist Fork-and-Contribute ein gängiges Muster. Um dieses Muster weiter zu sichern und zu fördern, ändern wir die Berechtigung zur Abstimmung über einen Pull-Antrag von "Mitwirken an Pull-Anfragen" in "Mitwirken". Diese Änderung wird jedoch nicht standardmäßig in allen Projekten vorgenommen. Sie müssen sich anmelden und eine neue Richtlinie für Ihr Repository auswählen, die als "Strenger Abstimmungsmodus" bezeichnet wird, um diese Berechtigung zu wechseln. Es wird empfohlen, dies zu tun, wenn Sie auf Forks in Azure Repos angewiesen sind.

Reporting

Gruppieren nach Tags, die in Diagramm-Widgets verfügbar sind

Das Diagramm-Widget "Nach Kategorien gruppieren" ist jetzt standardmäßig für alle Kunden verfügbar. Bei Verwendung des Diagramm-Widgets ist jetzt eine Option für Tags verfügbar. Benutzer können ihre Informationen visualisieren, indem sie alle Tags oder eine Gruppe von Tags im Widget auswählen.

Anzeigen von benutzerdefinierten Arbeitsaufgabentypen im Burndown-Widget

Zuvor konnten Sie keine benutzerdefinierten Arbeitsaufgabentypen sehen, die im Burn down-Widget konfiguriert sind und von einem benutzerdefinierten Feld summiert oder gezählt wurden. Mit diesem Update wurde dieses Problem behoben, und jetzt können Sie benutzerdefinierte Arbeitsaufgabentypen im Burndown-Widget sehen.

---

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