Versionshinweise zu Azure DevOps Server 2022

---

| | Entwicklercommunity Systemanforderungen und Kompatibilitätslizenzbedingungen | | DevOps Blog | SHA-256 Hashes |

---

In diesem Artikel finden Sie Informationen zum neuesten Release für Azure DevOps Server.

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

Um Azure DevOps Server Produkte herunterzuladen, besuchen Sie die Seite Azure DevOps Server Downloads.

Das direkte Upgrade auf Azure DevOps Server 2022 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 früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie auf Azure DevOps Server 2022 aktualisieren. Weitere Informationen finden Sie auf der Seite "Installieren" .

---

Azure DevOps Server 2022 Update 0.1 Patch 5 Veröffentlichungsdatum: 14. November 2023

Hinweis

Azure DevOps Server Patches kumulativ sind, enthält dieser Patch Updates für den Azure Pipelines-Agent, wenn Sie Patch 3 nicht installiert haben. Die neue Version des Agents nach der Installation von Patch 5 ist 3.225.0.

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.

• Die Liste der zulässigen PowerShell-Aufgaben wurde für die Parameterüberprüfung von Argumenten für Shellaufgaben aktivieren erweitert.
• Beheben Sie ein Problem, das dazu führte, dass Dienstverbindungsbearbeitungen nach dem Klicken auf die Schaltfläche "Abbrechen" dauerhaft waren.

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

Hinweis

Azure DevOps Server Patches kumulativ sind, enthält dieser Patch Updates für den Azure Pipelines-Agent, wenn Sie Patch 3 nicht installiert haben. Die neue Version des Agents nach der Installation von Patch 5 ist 3.225.0.

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

• Es wurde ein Fehler behoben, der dazu führte, dass Pipelines durch ein Upgrade des Pipelineausführungsmodells hängen blieben.
• Es wurde ein Fehler behoben, bei dem die Identität "Analysis Owner" auf Patchupgradecomputern als inaktive Identität angezeigt wurde.
• Der Buildbereinigungsauftrag enthält viele Aufgaben, von denen jede ein Artefakt für einen Build löscht. Wenn bei einer dieser Aufgaben ein Fehler aufgetreten ist, wurde keine der nachfolgenden Aufgaben ausgeführt. Wir haben dieses Verhalten geändert, um Aufgabenfehler zu ignorieren und so viele Artefakte wie möglich sauber.

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

Hinweis

Dieser Patch enthält Updates für den Azure Pipelines-Agent. Die neue Version des Agents nach der Installation von Patch 3 ist 3.225.0.

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: Azure DevOps Server Sicherheitsanfälligkeit bezüglich Remotecodeausführung.
• CVE-2023-38155: Sicherheitsanfälligkeit in Azure DevOps Server und Team Foundation Server

Azure DevOps Server Veröffentlichungsdatum von Update 0.1 Patch 2022: 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: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Es wurde ein Fehler in SOAP-Aufrufen behoben, bei dem ArithmeticException für xml-Antworten mit großen Metadaten ausgelöst werden kann.
• Es wurden Änderungen am Dienstverbindungs-Editor implementiert, sodass der Endpunktzustand beim Schließen der Komponente geleert wird.
• Problem behoben, bei dem relative Links in Markdowndateien nicht funktionieren.
• Es wurde ein Leistungsproblem behoben, das darauf bezieht, dass der Start der Anwendungsebene länger als normal dauerte, wenn eine große Anzahl von Tags definiert ist.
• Es wurden TF400367 Fehler auf der Seite "Agentpools" behoben.
• Es wurde ein Fehler behoben, bei dem die Identität des Analysebesitzers als inaktive Identität angezeigt wurde.
• Endlosschleifenfehler bei 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: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• CVE-2023-21569: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Ein Fehler mit dem Editor für Dienstverbindungen wurde behoben. Entwurf des Endpunktzustands wird nun beim Schließen der Komponente erstellt.
• Es wurde ein Fehler behoben, bei dem das Trennen oder Anfügen der Sammlung den folgenden Fehler meldete: "TF246018: Der Datenbankvorgang hat das Timeoutlimit überschritten und wurde abgebrochen.

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

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

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 Korrekturen in den Azure DevOps Server 2022-Patches, die zuvor veröffentlicht wurden. Sie können Azure DevOps Server 2022.0.1 direkt installieren oder ein Upgrade von Azure DevOps Server 2022 oder Team Foundation Server 2015 oder höher durchführen.

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

• Git Virtual File System (GVFS) von v2.39.1.1-micorosoft.2 aktualisiert, um ein Sicherheitsrisiko zu beheben.
• Testdaten wurden nicht gelöscht, sodass die Datenbank vergrößert wurde. Mit diesem Fix wurde die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.
• Updates dem AnalyticCleanupJob wurde der Auftrag status beendet, und jetzt melden wir Erfolgreich.
• Fehler beim Befehl "tfx extension publish" mit dem Fehler "Der angegebene Schlüssel war im Wörterbuch nicht vorhanden" wurde behoben.
• Es wurde eine Problemumgehung implementiert, um Fehler und Fehler beim Zugriff auf die Teamkalendererweiterung zu beheben.
• CVE-2023-21564: Azure DevOps Server Sicherheitsrisiko für siteübergreifende Skripterstellung
• CVE-2023-21553: Sicherheitsanfälligkeit Azure DevOps Server 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 lokalem Azure DevOps verfügbar.
• Problem mit der Barrierefreiheit von Regalen über die Web-Benutzeroberfläche wurde behoben.
• Es wurde ein Problem behoben, das einen Neustart des tfsjobagent-Diensts und Azure DevOps Server Anwendungspools erforderte, nachdem die SMTP-bezogene Einstellung in der Azure DevOps Server-Verwaltungskonsole aktualisiert wurde.
• Benachrichtigungen wurden für PAT sieben Tage vor dem Ablaufdatum nicht gesendet.

Azure DevOps Server Veröffentlichungsdatum von Patch 4 2022: 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: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• CVE-2023-21569: Azure DevOps Server Sicherheitsanfälligkeit bei Spoofing.
• Ein Fehler mit dem Editor für Dienstverbindungen wurde behoben. Entwurf des Endpunktzustands wird nun beim Schließen der Komponente erstellt.
• Es wurde ein Fehler behoben, bei dem das Trennen oder Anfügen der Sammlung den folgenden Fehler meldete: "TF246018: Der Datenbankvorgang hat das Timeoutlimit überschritten und wurde abgebrochen.

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

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

• Es wurde ein Problem behoben, das einen Neustart des tfsjobagent-Diensts und Azure DevOps Server Anwendungspools erforderte, nachdem die SMTP-bezogene Einstellung in der Azure DevOps Server-Verwaltungskonsole aktualisiert wurde.
• Kopieren Sie den Endpunktstatus in den Bearbeitungsbereich des Dienstendpunkts, anstatt ihn als Verweis zu übergeben.
• Zuvor wurden beim Bearbeiten von Dienstverbindungen die Bearbeitungen auf der Benutzeroberfläche beibehalten, nachdem die Schaltfläche "Abbrechen" ausgewählt wurde. Mit diesem Patch wurde im Benachrichtigungs-SDK für den Fall behoben, dass für ein Team die Einstellung Benachrichtigungsübermittlung auf Nicht übermitteln festgelegt ist. Wenn in diesem Szenario das Benachrichtigungsabonnement mit der Option "Teameinstellungsübermittlung " konfiguriert ist, erhalten die 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 Veröffentlichungsdatum von Patch 2022: 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: Azure DevOps Server Sicherheitsanfälligkeit bei siteübergreifender Skripterstellung
• MsBuild- und VSBuild-Aufgaben wurden aktualisiert, um Visual Studio 2022 zu unterstützen.
• Aktualisieren Sie die Methodik des Ladens der erneuten Authentifizierung, um einen möglichen XSS-Angriffsvektor zu verhindern.
• Azure DevOps Server 2022-Proxy meldet den folgenden Fehler: VS800069: Dieser Dienst ist nur in lokalem Azure DevOps verfügbar.

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

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

• Testdaten wurden nicht gelöscht, sodass die Datenbank vergrößert wurde. Mit diesem Fix wurde die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.
• Updates dem AnalyticCleanupJob wurde der Auftrag status beendet, und jetzt melden wir Erfolgreich.
• Der Befehl "tfx extension publish" wurde behoben, bei dem der Fehler "Der angegebene Schlüssel war im Wörterbuch nicht vorhanden" fehlschlägt.
• Es wurde eine Problemumgehung implementiert, um fehler und beim Zugriff auf die Teamkalendererweiterung zu beheben.

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

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

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

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

Hinweis

Neue SSH-RSA-Algorithmen aktiviert

Die Unterstützung für öffentliche RSA-Schlüssel wurde verbessert, um zusätzlich zu sha1 SSH-RSA, die wir zuvor unterstützt haben, auch die Typen öffentlicher SHA2-Schlüssel zu unterstützen.

Zu den unterstützten Typen für öffentliche Schlüssel gehören jetzt:

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

Aktion erforderlich

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

Die Unterstützung für elliptische Schlüssel wurde noch nicht hinzugefügt und ist weiterhin ein stark angefordertes Feature in unserem Backlog.

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

Zusammenfassung der Neuerungen in Azure DevOps Server 2022

Wichtig

Der Warehouse- und Analysis-Dienst war in der vorherigen Version von Azure DevOps Server (2020) veraltet. In Azure DevOps Server 2022 wurde der Warehouse and Analysis Service aus dem Produkt entfernt. Analytics bietet jetzt die In-Product-Berichterstellung.

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

• Lieferpläne
• Anzeigen der richtigen Persona auf Commitlinks
• Neue Steuerelemente für Umgebungsvariablen in Pipelines
• Generieren von uneingeschränkten Token für Forkbuilds
• Neue TFVC-Seiten
• Gruppierung nach Tags, die in Diagrammwidgets 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 mitteilen zu können, dass Lieferpläne jetzt in Azure DevOps Server enthalten sind. Übermittlungspläne liefern drei wichtige Szenarien:

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

Im Folgenden finden Sie die Standard Features. Filterung, Marker und Feldkriterien sind ebenfalls Teil von Übermittlungsplänen.

Es gibt zwei Standard Ansichten: verdichtet und erweitert

Übermittlungspläne 2.0 ermöglichen das Anzeigen aller Arbeitselemente in Ihrem Plan auf einem Zeitleiste unter Verwendung von Start- und Zielterminen oder Iterationsdaten. Die Reihenfolge der Rangfolge ist start & Zieltermine, gefolgt von der Iteration. Auf diese Weise können Sie Arbeitselemente auf Portfolioebene wieEpic hinzufügen, die häufig nicht für eine Iteration definiert sind.

Es gibt zwei Standard Ansichten, die verkürzte Ansicht und die erweiterte Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe in der Ecke des Plans klicken.

Es gibt zwei Standard Ansichten, die verkürzte Ansicht und die erweiterte Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe rechts neben dem Plan klicken.

• Verkürzte Ansicht

  In der verkürzten Ansicht sind alle Arbeitselementkarten reduziert, sodass nicht alle Karte Informationen angezeigt werden. Diese Ansicht ist nützlich für eine Gesamtansicht der Arbeit im Plan. Um die Karte Felder zu reduzieren, klicken Sie auf das Karte-Symbol neben den Vergrößerungssymbolen auf der rechten Seite des Plans.

  Hier sehen Sie ein Beispiel für einen Plan, der zwischen den verkürzten und erweiterten Ansichten umgeschaltet wird.

  

• Erweiterte Ansicht

  In der erweiterten Ansicht wird der Fortschritt eines Arbeitselements angezeigt, indem die Anzahl der untergeordneten und verknüpften Elemente gezählt und der Prozentsatz der abgeschlossenen Elemente angezeigt wird. Der Aktuelle Fortschritt wird durch die Anzahl der Arbeitselemente bestimmt.

  Hier sehen Sie 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 Arbeitselementen definiert werden. Wenn diese Verknüpfungen nicht definiert sind, werden keine Abhängigkeitslinien angezeigt. Wenn ein Abhängigkeitsproblem mit einem Arbeitselement vorliegt, wird das Abhängigkeitslinksymbol rot eingefärbt.

• Anzeigen von Abhängigkeiten

  Bestimmte Abhängigkeiten werden über den Abhängigkeitsbereich angezeigt, in dem alle Abhängigkeiten für dieses Arbeitselement einschließlich der Richtung angezeigt werden. Ein rotes Ausrufezeichen weist auf ein Abhängigkeitsproblem hin. Klicken Sie zum Öffnen des Bereichs einfach auf das Abhängigkeitslinksymbol in der oberen rechten Ecke des Karte. Hier finden Sie Beispiele für Abhängigkeiten.

  

  

• Abhängigkeitslinien

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

  Hier sehen Sie einige Beispiele:

  

  Hier sehen Sie ein Beispiel für ein Arbeitselement mit mehreren Abhängigkeiten, das auch mit der verkürzten Ansicht funktioniert.

  

  Wenn ein Problem vorliegt, ist die Linienfarbe rot, ebenso das Abhängigkeitssymbol.

  Es folgt ein Beispiel.

  

Kartenformatierung

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 + Formatvorlage hinzufügen , um die Regel hinzuzufügen, und klicken Sie dann auf Speichern. Es kann bis zu 10 Regeln geben, und jede Regel kann bis zu 5 Klauseln enthalten.

• Vorher

• Nach

Weitere Informationen zu Lieferplänen finden Sie in der Dokumentation.

Entfernte Elemente im Arbeitselemente-Hub

Im Hub für Arbeitselemente wird eine Liste der Elemente angezeigt, die Sie erstellt haben oder die Ihnen zugewiesen sind. Es bietet mehrere personalisierte Pivot- und Filterfunktionen, um das Auflisten von Arbeitselementen zu optimieren. Eine der häufigsten Beschwerden des Pivots Zugewiesen für mich ist, dass entfernte Arbeitselemente angezeigt werden. Wir stimmen zu, dass entfernte Arbeitselemente nicht mehr von Wert sind und nicht im Backlog enthalten sein sollten. In diesem Sprint werden alle Entfernten Elemente aus den Ansichten Mir zugewiesen im Arbeitselemente-Hub ausgeblendet.

Anzeigen der richtigen Persona auf Commitlinks

Im Abschnitt "Entwicklung" in einem Arbeitselement wird die Liste der relevanten Commits und Pull Requests angezeigt. Sie können den Autor des Commits oder Pull Requests zusammen mit der zugeordneten 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 Arbeitselementverlauf

Es wurde ein kleines Problem behoben, bei dem Benutzer Anlagen aus dem Arbeitselementverlauf 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 in der REST-API-Antwort verfügbar.

Der Wert "Will not Fix" (Wird nicht korrigiert) wurde 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 wurde der Wert Will not fix reason für die Fehlerarbeitselementtypen im Agile-Prozess hinzugefügt. Der Wert ist als Grund verfügbar, wenn Fehler von Neu oder Aktiv in Aufgelöst verschoben werden. Weitere Informationen zum Definieren, Erfassen, Selektieren und Verwalten von Softwarefehlern finden Sie in Azure Boards Dokumentation.

Pipelines

Entfernen von Aufbewahrungsrichtlinien pro Pipeline in klassischen Builds

Sie können jetzt Aufbewahrungsrichtlinien sowohl für klassische Builds als auch für 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 auch die Aufbewahrung für klassische Buildpipelines pro Pipeline konfigurieren. Wir haben alle Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines in einem bevorstehenden Release entfernt.

Was dies für Sie bedeutet: Jede klassische Buildpipeline, die früher über Aufbewahrungsregeln pro Pipeline verfügte, wird durch die Aufbewahrungsregeln auf Projektebene gesteuert.

Um sicherzustellen, dass Sie beim Upgrade keine Builds verlieren, erstellen wir eine Lease für alle Builds, die zum Zeitpunkt des Upgrades vorhanden sind und keine Lease besitzen.

Es wird empfohlen, die Aufbewahrungseinstellungen auf Projektebene nach dem Upgrade zu überprüfen. Wenn Ihre Pipeline speziell benutzerdefinierte Regeln erfordert, können Sie eine benutzerdefinierte Aufgabe in Ihrer Pipeline verwenden. Informationen zum Hinzufügen von Aufbewahrungsleases über eine Aufgabe finden Sie in der Dokumentation zum Festlegen von Aufbewahrungsrichtlinien für Builds, Releases 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 setVariableBefehl kann verwendet werden, um eine Variable festzulegen oder eine zuvor definierte Variable zu ändern. Dies kann möglicherweise 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 ausgibt, 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 sich darauf verlassen, 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 Einfügen eines Codeausschnitts wie dem folgenden in task.jsonkann ein Aufgabenautor steuern, ob Variablen durch seine Aufgabe festgelegt werden.

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

• Darüber hinaus aktualisieren wir eine Reihe von integrierten Aufgaben, z. B. SSH, damit 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 von uneingeschränkten Token für Forkbuilds

GitHub Enterprise-Benutzer verwenden häufig Forks, um zu einem Upstream-Repository beizutragen. Wenn Azure Pipelines Beiträge aus einem Fork eines GitHub Enterprise-Repositorys erstellt, schränkt die dem Auftragszugriffstoken gewährten Berechtigungen ein und lässt den Zugriff auf Pipelinegeheimnisse durch solche Aufträge nicht zu. Weitere Informationen zur Sicherheit von Bau-Forks finden Sie in unserer Dokumentation.

Dies kann in solchen geschlossenen Umgebungen restriktiver sein als gewünscht, in denen Benutzer weiterhin von einem Modell für die Zusammenarbeit mit einer internen Quelle profitieren können. Sie können zwar eine Einstellung in einer Pipeline konfigurieren, um Geheimnisse für Forks verfügbar zu machen, es gibt jedoch keine Einstellung zum Steuern des Auftragszugriffstokenbereichs. Mit dieser Version geben wir Ihnen die Möglichkeit, 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 Auswirkungen der Aktivierung dieser Konfiguration auf die Sicherheit vollständig verstehen.

Repositorys als geschützte Ressource in YAML-Pipelines

Sie können Ihr Azure DevOps-Projekt so organisieren, dass es viele Unterprojekte hostet – jedes mit einem eigenen Azure DevOps-Git-Repository und einer oder mehreren Pipelines. In dieser Struktur können Sie 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 normalerweise diese Repositorys 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 schließt 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 Repository 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 werden ein neues Menü mit dem Namen "Checks" bemerken, in dem Sie jede der im Kontrollkästchen enthaltenen oder benutzerdefinierten Überprü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 Überprüfungen und Berechtigungen erfüllt sind.

Hinweis

Diese Berechtigungen und Überprüfungen gelten nur für YAML-Pipelines. Klassische Pipelines erkennen diese neuen Features nicht.

Berechtigungen und Überprüfungen für Variablengruppen und sichere Dateien

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

Verwenden Sie das Feature Pipelines-Berechtigungen , um den Zugriff auf eine Variablengruppe oder eine sichere Datei auf eine kleine Gruppe von Pipelines einzuschränken.

Verwenden Sie zum Konfigurieren von Überprüfungen oder Genehmigungen, die bei jeder Ausführung einer Pipeline ausgewertet werden sollen, das Feature Genehmigungen und Überprüfungen für Bibliothek .

Änderungen bei der automatischen Erstellung von Umgebungen

Wenn Sie eine YAML-Pipeline erstellen und auf eine Umgebung verweisen, die nicht vorhanden ist, erstellt Azure Pipelines die Umgebung automatisch. Diese automatische Erstellung kann entweder im Benutzerkontext oder im Systemkontext erfolgen. In den folgenden Flows 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, um die Umgebung zu verwalten und/oder andere Benutzer in verschiedene Rollen für die Verwaltung der Umgebung einzuschließen.

In den folgenden Flows verfügt Azure Pipelines nicht über Informationen zum Benutzer, der die Umgebung erstellt: Sie aktualisieren die YAML-Datei mithilfe eines anderen externen Code-Editors, fügen einen Verweis auf eine Umgebung hinzu, die nicht vorhanden ist, und führen dann dazu, dass eine Continuous Integration-Pipeline 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 über das Erteilen von Administratorberechtigungen für eine Umgebung für alle Mitglieder eines Projekts erhalten. Während wir Ihr Feedback gehört haben, haben wir gehört, dass wir keine automatische Umgebung erstellen sollten, wenn nicht klar ist, wer der Benutzer ist, der den Vorgang ausführt. Mit diesem Release haben wir Änderungen an der automatischen Erstellung von Umgebungen vorgenommen:

• In Zukunft werden Pipelineausführungen nicht automatisch eine Umgebung erstellen, wenn sie nicht vorhanden ist und der Benutzerkontext nicht bekannt ist. In solchen Fällen schlägt die Pipeline mit einem Fehler "Umgebung nicht gefunden" fehl. Sie müssen die Umgebungen mit der richtigen Sicherheits- und Überprüfungskonfiguration vorab erstellen, bevor Sie sie in einer Pipeline verwenden.
• Pipelines mit bekanntem Benutzerkontext erstellen weiterhin Umgebungen wie in der Vergangenheit automatisch.
• Abschließend ist zu beachten, dass das Feature zum automatischen Erstellen einer Umgebung nur hinzugefügt wurde, um den Prozess der ersten Schritte mit Azure Pipelines zu vereinfachen. Es war für Testszenarien und nicht für Produktionsszenarien gedacht. Sie sollten immer Produktionsumgebungen mit den richtigen Berechtigungen und Überprüfungen vorab erstellen und diese dann in Pipelines verwenden.

Entfernen des Insights-Dialogs aus Buildpipeline

Basierend auf Ihrem Feedback wurde das Dialogfeld Task/Pipeline Insights, das beim Navigieren in der Buildpipeline angezeigt wird, entfernt, um den Workflow zu verbessern. Die Pipelineanalysen sind weiterhin verfügbar, sodass Sie über die erforderlichen Erkenntnisse verfügen.

Unterstützung für sequenzielle Bereitstellungen statt nur bei verwendung exklusiver Sperrüberprüfungen

In YAML-Pipelines werden Überprüfungen verwendet, um die Ausführung von Phasen für geschützte Ressourcen zu steuern. Eine der gängigen Überprüfungen, die Sie verwenden können, ist eine exklusive Sperrprüfung. Mit dieser Überprüfung kann nur eine einzelne Ausführung aus der Pipeline fortgesetzt werden. Wenn mehrere Ausführungen versuchen, zur gleichen Zeit in einer Umgebung bereitzustellen, werden alle alten Ausführungen abgebrochen und die neueste Ausführung kann bereitgestellt werden.

Das Abbrechen alter Ausführungen ist ein guter Ansatz, wenn Ihre Releases 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 sequenziell in einer Umgebung ausgeführt und bereitgestellt werden können, oder das vorherige Verhalten beibehalten, alte Ausführungen abzubrechen und nur die neuesten zuzulassen. Sie können dieses Verhalten mithilfe einer neuen Eigenschaft angeben, die in der YAML-Pipelinedatei genannt wird lockBehavior . Ein Wert von sequential impliziert, dass alle Ausführungen die Sperre sequenziell für die geschützte Ressource abrufen. Ein Wert von runLatest impliziert, dass nur die letzte Ausführung die Sperre für die Ressource erhält.

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 mit dem Namen an 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 angeben lockBehavior, wird davon ausgegangen, dass es ist runLatest.

Unterstützung für die Quebec-Version von ServiceNow

Azure Pipelines verfügt über eine vorhandene Integration mit ServiceNow. Die Integration basiert auf einer App in ServiceNow und einer Erweiterung in Azure DevOps. Wir haben die App nun so aktualisiert, dass sie mit der Quebec-Version von ServiceNow funktioniert. 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-Speicher aus. Weitere Informationen finden Sie unter Integrieren in serviceNow Change Management.

Neue bedingte YAML-Ausdrücke

Das Schreiben bedingter Ausdrücke in YAML-Dateien wurde durch die Verwendung von ${{ else }} - und ${{ elseif }} -Ausdrücken einfacher. Im Folgenden finden Sie Beispiele für die Verwendung dieser Ausdrücke in YAML-Pipelinedateien.

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 Wildcards in Pfadfiltern

Wildcards können verwendet werden, wenn Ein- und Ausschlussäste für CI- oder PR-Trigger in einer YAML-Pipelinedatei angegeben werden. Sie können jedoch nicht zum Angeben von Pfadfiltern verwendet werden. Für instance können Sie nicht alle Pfade einschließen, die mit übereinstimmensrc/app/**/myapp*. Dies wurde von mehreren Kunden als Unannehmlichkeiten bezeichnet. Dieses Update schließt diese Lücke. Jetzt können Sie beim Angeben von Pfadfiltern Karte Zeichen (**, *oder ?) verwenden.

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

Das windows-2022 Image kann als Standardversion für die windows-latest Bezeichnung in Azure Pipelines von Microsoft gehosteten Agents verwendet werden. Bisher verweist diese Bezeichnung auf Windows-2019-Agents. Diese Änderung wird ab dem 17. Januar über einen Zeitraum von mehreren Wochen 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 neuestes festzulegen.

Das windows-2022 Image enthält Visual Studio 2022. Eine vollständige Liste der Unterschiede zwischen windows-2022 und windows-2019finden Sie im GitHub-Problem. Eine vollständige Liste der im Image installierten Software finden Sie hier.

Pipelineordnerumbenennung ü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 im Ordner verfügt.

Planung des Pipelines-Agent-Runtimeupgrades

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. Es wird auf von Microsoft gehosteten Agents, Scale Set-Agents und selbstgehosteten Agents ausgeführt. Im letzteren Fall installieren Sie es 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 daher diese Runtimes für sie hosten.

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 werden wir in der Lage sein, native Kompatibilität für Apple Silicon und Windows Arm64 bereitzustellen. Daher planen wir, in den nächsten Monaten auf .NET 6 für Pipeline-Agent (Listener und Worker) umzustellen.

Aufgrund einer Reihe von Einschränkungen, die dies mit sich bringt, wird der Support für Red Hat Enterprise Linux 6 von unserem Agent am 30. April 2022 gelöscht.

Updates zum Azure-Dateikopiervorgang

Wir stellen eine neue Version des Azure-Dateikopiertasks bereit. Mit dieser Aufgabe werden Dateien in Microsoft Azure-Speicherblobs oder virtuelle Computer (VMs) kopiert. Die neue Version enthält mehrere Updates, die häufig von der Community angefordert wurden:

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

• Mit der neuen Version von AzCopy können Sie auch eine Einstellung konfigurieren, um das Ziel zu sauber, 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 angegeben 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 werden. Dadurch wird in einigen Fällen eine unnötige Warnung entfernt, wenn Sie die Aufgabe verwenden.

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 Wahl getroffen, die Hauptversion zu aktualisieren, um sicherzustellen, dass keine Pipelines unterbrochen werden, die noch von AzureRM-Modulen abhängig sind.

Detailansicht neuer Erweiterungspunkte für Pipelines

Wir haben zwei neue Erweiterbarkeitspunkte hinzugefügt, die Sie in Ihren Erweiterungen als Ziel verwenden können. Mit diesen Erweiterbarkeitspunkten 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 Erweiterbarkeitspunkte zu verwenden, fügen Sie einfach einen neuen Beitrag hinzu, der auf sie abzielt, in der vss-extension.json Manifestdatei Ihrer Azure DevOps-Erweiterung.

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 ist:

• Benutzerdefinierte Schaltfläche im Pipelineheader

  

• Benutzerdefiniertes Menü in einem Pipelineordner

  

Verbesserte Migration zu Azure DevOps Services

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

Verbesserung der REST-API für Pipelineausführungen

Zuvor hat die REST-API für Pipelinesausführungen nur das self Repository zurückgegeben. Mit diesem Update gibt die REST-API für Pipelineausführungen 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 sehen Sie ein Szenario für die Verwendung templateContext:

• Sie verwenden Vorlagen, um 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. Sie legt beispielsweise die Umgebung fest, in der jeder Auftrag ausgeführt wird, oder fügt zusätzliche Schritte hinzu, um die Compliance zu erzwingen.

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

Schauen wir uns ein Beispiel an. Angenommen, Sie erstellen eine Pipeline, die End-to-End-Tests für die Überprüfung von Pull Request 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 deren Verhalten angeben.

Sie erkennen, dass andere Teams ähnliche Anforderungen haben werden, 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 }}

Die Vorlage legt für jeden Auftrag im testSet Parameter die Antwort der Systemkomponenten fest, 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 aus, einen positiven und einen negativen. Für beide Tests muss die dimensionsapi Komponente verfügbar sein. Der positive_test Auftrag erwartet den dimensionsapi http-Rückgabecode 200, während negative_test er HTTP-Code 500 zurückgibt.

Unterstützung von gruppenverwalteten Dienstkonten als Agent-Dienstkonto

Der Azure Pipelines-Agent unterstützt jetzt gruppenverwaltete Dienstkonten in selbstgehosteten 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>

Informationsausführungen

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. als Reaktion auf interne Trigger, z. B. als Reaktion auf interne Trigger, um zu überprüfen, ob Codeänderungen vorliegen und eine geplante Ausführung zu starten. 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 finden Sie unter Informationsausführungen.

Rest-API-Eigenschaft retentionRules der Builddefinition ist veraltet

Im Antworttyp der REST-APIBuildDefinition für Builddefinition ist die retentionRules Eigenschaft jetzt als veraltet markiert, 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, mit dem Ziel, die Benutzeroberfläche für die verschiedenen Dienste konsistenter und zugänglicher 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 oft eine Möglichkeit angefordert, ein Repository zu deaktivieren und zu verhindern, dass Benutzer auf seine Inhalte zugreifen. Dies können Sie z. B. in folgenden Fällen tun:

• Sie haben ein Geheimnis im Repository gefunden.
• Ein Überprüfungstool eines Drittanbieters hat festgestellt, dass ein Repository nicht konform ist.

In solchen Fällen können Sie das Repository vorübergehend deaktivieren, während Sie an der Behebung des Problems arbeiten. Mit diesem Update können Sie ein Repository deaktivieren, wenn Sie über die Berechtigung Repository löschen verfügen. Wenn Sie ein Repository deaktivieren, können Sie:

• 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 versucht wird, auf das Repository auf der Azure Repos-Benutzeroberfläche zuzugreifen

Nachdem die erforderlichen Maßnahmen zur Entschärfung ergriffen 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 jeweilige Repository aus.

Konfigurieren von Brancherstellern, um keine "Berechtigungen verwalten" für ihre Filialen zu erhalten

Wenn Sie einen neuen Branch erstellen, erhalten Sie "Berechtigungen verwalten" für diesen Branch. Mit dieser Berechtigung können Sie die Berechtigungen anderer Benutzer ändern oder zusätzlichen Benutzern die Möglichkeit geben, an diesem Branch mitzuwirken. Für instance kann ein Branchersteller diese Berechtigung verwenden, um einem anderen externen Benutzer zu erlauben, Änderungen am Code vorzunehmen. Oder sie ermöglichen es einer Pipeline (Builddienstidentität), den Code in diesem Branch zu ändern. 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 branch-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 nutzen möchten.

Verhindern der Abstimmung von Fork-Benutzern für ihre Upstream PRs

Mit Azure Repos können Benutzer mit der Berechtigung "Lesen" für ein Repository das Repository forken und Änderungen an ihrem Fork vornehmen. Um einen Pull Request mit ihren Änderungen an der Upstream zu übermitteln, benötigen Benutzer die Berechtigung "Mitwirken zu Pull Requests" auf dem Upstream. Diese Berechtigung bestimmt jedoch auch, wer über Pull Requests im Upstream Repository abstimmen kann. Dadurch können Sie in Situationen enden, in denen ein Benutzer, der kein Mitwirkender für das Repository ist, einen Pull Request übermitteln und ihn je nach Einrichtung der Branchrichtlinien zusammenführen kann.

In Projekten, die ein Inner-Source-Modell 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 Request von "Zu Pull Requests beitragen" in "mitwirken". Diese Änderung wird jedoch nicht standardmäßig in allen Projekten vorgenommen. Sie müssen sich für Ihr Repository anmelden und eine neue Richtlinie namens "Strict Vote Mode" (Strikter Abstimmungsmodus) auswählen, um diese Berechtigung zu ändern. Es wird empfohlen, dies zu tun, wenn Sie sich auf Forks in Azure Repos verlassen.

Berichterstellung

Gruppierung nach Tags, die in Diagrammwidgets verfügbar sind

Das Diagrammwidget Gruppierung nach Tags ist jetzt standardmäßig für alle Kunden verfügbar. Wenn Sie das Diagrammwidget verwenden, ist jetzt eine Option für Tags verfügbar. Benutzer können ihre Informationen visualisieren, indem sie alle Tags oder eine Reihe von Tags im Widget auswählen.

Anzeigen benutzerdefinierter Arbeitselementtypen im Burndownwidget

Zuvor konnten Sie keine benutzerdefinierten Arbeitselementtypen sehen, die im Burndown-Widget konfiguriert und durch ein benutzerdefiniertes Feld zusammengefasst oder gezählt wurden. Mit diesem Update wurde dieses Problem behoben, und jetzt können Sie benutzerdefinierte Arbeitselementtypen im Burndownwidget sehen.

---

Feedback

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

---

Seitenanfang