Azure DevOps-Dienstupdates und Integrationsverbesserungen

Um sicherzustellen, dass Ihre Azure DevOps-Umgebung sicher bleibt, erstellen wir wichtige Dienstupdates. Dazu gehört, dass die Unterstützung für neue OAuth-App-Registrierungen ab April 2025 eingestellt wird, obwohl bestehende Apps bis zum vollständigen Ruhestand im Jahr 2026 weiterhin funktionieren. Darüber hinaus ist für alle HTTPS-Verbindungen ab dem 23. April 2025 die Servernamenanzeige (Server Name Indication, SNI) sowie Updates für TFVC-Check-In-Richtlinien in Azure Repos erforderlich.

Neben diesen Updates freuen wir uns, die neuesten Verbesserungen unserer Azure Boards + GitHub-Integration bekannt zu geben, die das Verknüpfen von Zweigen, Pull Requests und Commits mit Arbeitselementen vereinfachen. Darüber hinaus bietet Pipelines jetzt mehr Transparenz in YAML-Phasenabhängigkeiten, wodurch Teams komplexere Workflows mit verbesserter Effizienz verwalten können.

Weitere Informationen finden Sie in den Versionshinweisen.

Allgemein

• Keine neuen Azure DevOps OAuth-Apps ab April 2025
• Server name Indication (SNI) jetzt obligatorisch für Azure DevOps Services

Azure Boards:

• GitHub-Integration: Verbesserungen bei der Verknüpfung mit Commits, Branches und Pull Requests
• GitHub-Integration: Buildstatus für YAML-Pipelines anzeigen
• Grenzwert für Übermittlungspläne erhöht

Azure Repos

• TFVC-Check-In-Richtlinienänderungen
• Erweiterung der GetRepository-API
• Verbesserung der Pull-Request-Abfrage-API

Azure-Pipelines

• Verbesserte Sichtbarkeit von YaML-Pipelinephasenabhängigkeiten
• Neues Agent-CDN
• Node 16 wird aus Pipelines-* Pipeline-Agent-Paketen entfernt

Azure-Testpläne:

• Deaktivieren der Aktionsprotokollierung und Wechseln zur Bildschirmaufzeichnung
• Manuelle Testausführung automatisch anhalten

Allgemein

Keine neuen Azure DevOps OAuth-Apps ab April 2025

Ab April 2025 unterstützen wir keine neuen Registrierungen von Azure DevOps OAuth-Apps mehr. Dies ist ein erster Schritt auf dem Weg zu unserer langfristigen Vision, die Azure DevOps OAuth-Plattform außer Betrieb zu nehmen. Es wird empfohlen, dass alle Entwickler, die Anwendungen über Azure DevOps-REST-APIs erstellen, die Microsoft Identity Platform erkunden und stattdessen eine neue Entra-Anwendung registrieren.

Alle vorhandenen Azure DevOps OAuth-Apps werden bis zum offiziellen Ruhestand der Plattform im Jahr 2026 weiterarbeiten. Erfahren Sie mehr in unserem Blogbeitrag hier.

Server name Indication (SNI) jetzt obligatorisch für Azure DevOps Services

Ab dem 23. April 2025 benötigen wir servername indication (SNI) für alle eingehenden HTTPS-Verbindungen mit Azure DevOps Services.

SNI ist eine Erweiterung des TLS-Protokolls, mit der Clients den Hostnamen angeben können, mit dem sie eine Verbindung herstellen. Alle modernen Browser und Clientsoftware unterstützen SNI und verwenden sie standardmäßig, um einen nahtlosen Übergang für die meisten Benutzer sicherzustellen. Tatsächlich sind mehr als 99,995 % des Kundendatenverkehrs, der unsere Server erreicht, „SNI-bereit“.

Einige Clientsoftware kann jedoch aufgrund verschiedener Faktoren, z. B. veraltete, falsch konfigurierte Netzwerkbibliotheken, Laufzeiten oder Betriebssysteme, mit SNI nicht kompatibel sein. Probleme können auch aus Proxys oder NGFW-Firewalls auftreten. Die folgenden Tools, die mit Azure DevOps verwendet werden, können von SNI-Problemen betroffen sein:

• Git-Clients
• IDE-Plug-Ins und Erweiterungen (Team Explorer Everywhere)
• Software, die auf älteren Java-Versionen ausgeführt wird, die SNI (Java 6 und früher) nicht unterstützen oder SNI standardmäßig nicht aktiviert haben (einige Versionen von Java 7 und 8)
• Alte Browserversionen (siehe https://caniuse.com/sni)

SNI-Probleme manifestieren sich in der Regel durch Verbindungsfehler, z. B.:

• ERR_SSL_PROTOCOL_ERROR , ERR_CERT_COMMON_NAME_INVALID
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• Es konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal eingerichtet werden

Sie können die SNI-Kompatibilität Ihres Systems überprüfen, indem Sie den Statusendpunkt von Azure DevOps aufrufen, den wir für SNI konfiguriert haben. Wenn dieser Aufruf erfolgreich ist, gibt er an, dass der Host, einschließlich seines Betriebssystems und seiner Netzwerkumgebung, SNI-kompatibel ist. Ausführliche Anweisungen zum Testen finden Sie in unserem Blogbeitrag.

Azure Boards

GitHub-Integration: Verbesserungen bei der Verknüpfung mit Commits, Branches und Pull Requests

Wir verbessern kontinuierlich die Boards + GitHub-Integration, um Benutzerfreundlichkeitslücken zu schließen und die Erfahrung, mit der Sie in Azure Repos vertraut sind, auszurichten.

Mit diesem Update haben wir mehrere Verbesserungen eingeführt, um die Verknüpfung von Branches, Pull Requests und Commits mit Arbeitselementen zu optimieren:

• Wenn eine GitHub-Verzweigung mit einer Arbeitsaufgabe verknüpft ist, werden nun alle zugeordneten Pullanforderungen automatisch verknüpft. Es ist nicht erforderlich, AB# manuell zu verwenden.

• Sobald eine Pullanforderung zusammengeführt wurde, wird der Zusammenführungs-Commit automatisch mit der Arbeitsaufgabe verknüpft.

• Wenn der Branch gelöscht wird, nachdem der Pull Request zusammengeführt wurde, wird der Branch-Link automatisch aus dem Arbeitselement entfernt.

Diese Verbesserungen machen es einfacher, Ihren Entwicklungsfortschritt zu verfolgen und saubere, aktuelle Arbeitselement-Zuordnungen zu pflegen.

GitHub-Integration: Buildstatus für YAML-Pipelines anzeigen

Wir sind bestrebt, die Featureparität zwischen YAML und klassischen Pipelines zu erreichen. Ein zentrales fehlendes Feature war die Möglichkeit, einen Link "integriert im Build" bereitzustellen, wenn Ihr Repository auf GitHub gehostet wird. Mit unserer neuesten Version haben wir diese Lücke behoben, indem wir Ihnen eine Option in den YAML-Pipelineeinstellungen hinzufügen, um Folgendes zu überprüfen:

Sobald der Build abgeschlossen ist, erscheint der entsprechende Link automatisch auf den zugehörigen Work Items, wodurch die Rückverfolgbarkeit insgesamt verbessert wird.

Grenzwert für Lieferpläne erhöht

Bisher haben wir die Lieferpläne pro Projekt auf 1.000 beschränkt. Mit diesem Update haben wir die maximalen Lieferpläne pro Projekt auf 1.500 erhöht. Weitere Informationen zum Hinzufügen und Bearbeiten von Übermittlungsplänen finden Sie hier in der Dokumentation.

Azure Repos

TFVC-Check-In-Richtlinienänderungen

Neue Version (19.255.0-preview) des Microsoft.TeamFoundationServer.ExtendedClient NuGet-Pakets

Das NuGet-Paket Microsoft.TeamFoundationServer.ExtendedClient wurde mit neuen TFVC-Richtlinienklassen und -methoden aktualisiert.

Richtlinienänderungen

Wir nehmen Änderungen daran vor, wie TFVC-Check-In-Richtlinien in Azure DevOps gespeichert werden. Dies bedeutet auch Aktualisierungen darüber, wie der NuGet Microsoft.TeamFoundationServer.ExtendedClient mit dem Dienst kommuniziert.

Wenn Ihr TFVC-Projekt Check-In-Richtlinien verwendet, migrieren Sie diese Richtlinien in das neue Format. Sie können auf zwei Arten vorgehen:

1. Verwenden von Visual Studio.

Zum Erstellen neuer Richtlinien mithilfe des Visual Studio-Projektadministrators sollten Einstellungen -> Teamprojekt -> Quellcodeverwaltung -> Check-in-Richtlinie und Hinzufügen einer neuen Richtlinie (ohne "Veraltete" Markierung) mit denselben Parametern wie alt geöffnet werden:

2. Wenn Sie für die Kommunikation mit dem Server eine benutzerdefinierte Implementierung von Microsoft.TeamFoundationServer.ExtendedClient verwenden, befolgen Sie die im Migrationsleitfaden beschriebenen Schritte.

Die Migration ist erforderlich, um TFVC-Check-Ins mit den zukünftigen Azure DevOps-Versionen kompatibel zu halten. Vorerst bleiben alte (veraltete) und neue Richtlinien gültig und funktionsfähig. Informationen zu den zukünftigen Plänen finden Sie in unserem Blogbeitrag.

Erweiterung der GetRepository-API

Wir haben der Antwort der Repositories - Get Repository API die Eigenschaft creationDate hinzugefügt, die das Erstellungsdatum des Repositorys zurückgibt. Die Eigenschaft ist in den API-Versionen 7.2-preview und höher verfügbar.

Verbesserung der Pull-Request-Abfrage-API

Wir haben eine neue Label Eigenschaft in der Antwort von Pull Request Query - Get API eingeführt. Sie können jetzt angeben, ob Bezeichnungen (Tags) für verwandte Pullanforderungen in jede Abfrage eingeschlossen werden sollen. Eine neue Include-Eigenschaft ist verfügbar – wenn diese auf „Etiketten“ festgelegt ist, enthält die Antwort Etiketten für die angegebenen PRs. Wenn sie als null belassen werden, werden Beschriftungen nicht einbezogen. Um unbeabsichtigte Fehler zu vermeiden, stellen Sie sicher, dass NotSet nicht explizit zugewiesen wird, da dies zu Bad Request führt.

Anforderungsnutzlast (Beispiel):

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure-Pipelines

Verbesserte Sichtbarkeit von YaML-Pipelinephasenabhängigkeiten

YAML-Pipelines bieten Flexibilität beim Verwalten komplexer Workflows, aber die Visualisierung von Phasenabhängigkeiten war eine Herausforderung – insbesondere bei Bereitstellungen mit mehreren Regionen.

Es war nicht immer klar, wie Phasen verbunden sind. Beispielsweise hat das Ermitteln, ob CUS3 zusätzlich zu WUS2 und WUS3 auch von WUS1 abhängt, erfordert, das YAML direkt zu überprüfen.

Mit diesem Sprint werden jetzt Phasenabhängigkeiten angezeigt, wenn eine Phase erweitert wird und sofortige Einblicke in die Ausführungsreihenfolge und upstream-Anforderungen bietet.

Neues Agent-CDN

Da das Edgio-CDN eingestellt wird, wird auch die Domain-URL, die sich im Besitz von Edgio https://vstsagentpackage.azureedge.net befindet, eingestellt. Wir fügen eine neue Domänen-URL https://download.agent.dev.azure.com hinzu, die vom neuen CDN unterstützt wird. Achten Sie darauf, diese neue Domänen-URL zu Ihrer Firewall-Zulassungsliste hinzuzufügen. Downloads von Agent-Paketen für selbst gehostete Agenten sind fehlerhaft, sobald die alte Domain-URL entfernt wird. Weitere Informationen finden Sie im Beitrag .

Knoten 16 wird aus den Pipelines entfernt-* Pipeline Agent Pakete

Agentaufgaben können in PowerShell oder Node implementiert werden. Der Agent wird mit mehreren Versionen von Node ausgeliefert, auf die Aufgaben ausgerichtet werden können.

Wenn neue Node-Versionen veröffentlicht werden, werden Aufgaben aktualisiert, um neue Node-Versionen zu verwenden. Die Laufzeiten sind in dem Agenten enthalten.

Wenn die Node-Versionen das Upstream-Wartungsfenster verlassen, sind einige Pipelines-Aufgaben immer noch von ihnen abhängig. Azure DevOps aktualisiert unterstützte Aufgaben auf eine unterstützte Node-Version. Aufgaben von Drittanbietern benötigen möglicherweise noch ältere Node-Versionen, um ausgeführt zu werden.

Um dies zu berücksichtigen, haben wir zwei Arten von Pipeline-Agent-Paketen:

Wenn Sie eine Aufgabe ausführen möchten, die den Node 16-Ausführungshandler für einen Agent erfordert, der nicht mit Node 16 gebündelt ist, können Sie den Ausführungshandler installieren, indem Sie die NodeTaskRunnerInstaller@0 Aufgabe in Ihre Pipeline einfügen:

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

Azure Testpläne

Deaktivieren der Aktionsprotokollierung und Wechseln zur Bildschirmaufzeichnung

Unser Azure Test Runner Desktop-Client basiert auf dem Problem Steps Recorder (PSR), einem in Windows 7 eingeführten Tool, das jetzt in neueren Windows-Versionen nicht mehr unterstützt wird. Daher funktioniert die Funktionalität des Aktionsprotokolls in unserem Desktoptest-Runner möglicherweise nicht mehr in zukünftigen Updates.

Um eine unterbrechungsfreie Testüberwachung zu gewährleisten, empfehlen wir, auf Bildschirmaufzeichnung in unserem Web Runner umzusteigen, der Test & Feedback Erweiterung, die eine moderne und zuverlässige Möglichkeit zum Erfassen und Verwalten von Testschritten bietet. Wenn Sie Unterstützung bei der Umstellung auf die Test - Feedback-Erweiterung benötigen, wenden Sie sich bitte an unser Supportteam.

Manuelle Testausführung automatisch anhalten

Verlieren Sie nie Ihren Fortschritt bei Testläufen dank automatischem Pausieren von Testfallausführungen. Dieses neue Feature hält den Ablauf Ihres Testfalls automatisch an, wenn Ihre Arbeit unterbrochen wird, und stellt sicher, dass der teilweise Fortschritt gespeichert wird, ohne dass eine manuelle Pause erforderlich ist. Ganz gleich, ob Sie die Sitzung verlassen oder schließen, Sie können Ihren Testfall ganz einfach an der Stelle fortsetzen, an der Sie aufgehört haben, das Risiko eines Datenverlusts verringern und Ihren Workflow verbessern. Durch die Vereinfachung des Unterbrechungs- und Fortsetzungsprozesses hilft Ihnen die automatische Pause dabei, sich auf Tests zu konzentrieren, ohne sich Gedanken über den Verlust Ihres Fortschritts machen zu müssen. Probieren Sie es aus, und teilen Sie uns über E-Mail, was Sie denken!

Nächste Schritte

Gehen Sie zu Azure DevOps und schauen Sie sich an.

So geben Sie Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Danke

Silviu Andrica